Replicating a 'custom' 6800 in FPGA

[metertech58761]

So, I have this project that I built just to say I built it - a copy of an obscure bit of test equipment from the mid '80s.

Thing is, it uses a CPU that is an industrial 6800 variant (more precisely, it has the 6801 instruction set, yet the pinout is similar to a stock 6800).

It seems the chip I salvaged turned out to be dead... and the only place that even has any left quoted me a price over $50 apiece.

So, I'm curious if anyone has made an FPGA adapter for a 6800-class MPU?

[rstofer]

I haven't counted the pins but maybe the Digilent CMOD S6 or A7 can do the job.  I suspect there will need to be a carrier board between the project board and the CMOD to straighten out some signal pinouts.

https://digilent.com/shop/boards-and-components/system-boards/cmods/

There's a MC6803/6801 core at OpenCores.org if you need one.

[joeqsmith]

Do you have the project documented somewhere (schematics, source, layout...)?       

[james_s]

There is a 6800 core that I've used in some projects, although it is not cycle accurate, I don't know if that matters to you or not. It is certainly possible to use a FPGA soft core interfaced to original hardware but I don't know if there is a ready to go core that will do exactly what you want.

[rstofer]

Voltage levels may be a problem.

[BrianHG]

You would need to edit the core to drive the 'OE' and 'DIR' of a bunch of on-circuit 3.3v powered 74LVC245 to support 5v TTL safely.

[langwadt]

You would need to edit the core to drive the 'OE' and 'DIR' of a bunch of on-circuit 3.3v powered 74LVC245 to support 5v TTL safely.

Voh of 3.3V is well within the minimum Vih of 5V TTL

[BrianHG]

You would need to edit the core to drive the 'OE' and 'DIR' of a bunch of on-circuit 3.3v powered 74LVC245 to support 5v TTL safely.

Voh of 3.3V is well within the minimum Vih of 5V TTL

On Nockieboy's 8bit GPU thread, we had no problem using the 74LVC245 interfacing with a Z80 bus which contained the Z80 plus numerous additional 5v TTL peripherals.  I guess if you wanted additional margin, you could power the 245s with 3.8v hitting the maximum a 3.3v FPGA inputs can safely tolerate gaining an additional .5v on your high outputs.

[langwadt]

You would need to edit the core to drive the 'OE' and 'DIR' of a bunch of on-circuit 3.3v powered 74LVC245 to support 5v TTL safely.

Voh of 3.3V is well within the minimum Vih of 5V TTL

On Nockieboy's 8bit GPU thread, we had no problem using the 74LVC245 interfacing with a Z80 bus which contained the Z80 plus numerous additional 5v TTL peripherals.  I guess if you wanted additional margin, you could power the 245s with 3.8v hitting the maximum a 3.3v FPGA inputs can safely tolerate gaining an additional .5v on your high outputs.

Vih for TTL is only 2.4V, so 3.3V CMOS will easily drive that, so that is safe

Voh for standard TTL is quite wimpy, hence the low threshold, but relying on that not overdriving a 3.3V input is sketchy at best

[metertech58761]

Oh my. Didn't expect to see so many replies this quickly.

Going through the replies:

I did see the 6801 / 6803 listing at OpenCores...

I was figuring that I'd likely need to work out a carrier board to be able to drop the FPGA into the circuit.

I do have schematics of what I started with - can make a PDF of the whole thing and attach it a bit later on.

As long as whatever core is used works with a 1MHz clock and the NMI handling works well, I'll be happy.

Good to know that level-shifting will be needed - are ALL FPGAs 3.3V only, or are there any that are 5V-tolerant?

[james_s]

To my knowledge there are no modern FPGAs that are 5V tolerant although older ones certainly exist and you may still be able to source one. Whether it's worth trying to use an old part (and the old software required to work with it) vs just using level shifters is something you'll have to decide.

[woofy]

I've discovered the ice40 HX8k appears to be 5v tolerant, at your own risk though. Lattice says 3.3v.
https://www.eevblog.com/forum/fpga/ice40-hx-a-5v-tolerant-fpga/msg3580451/#msg3580451
I have a project running feeding 5v PS2 keyboard signals into and HX8k.

[SiliconWizard]

While it's not the prettiest approach, for such "low" frequencies (1 MHz), just using (even relatively large) series resistors for inputs is likely to be enough, rather than adding level shifters. As for outputs, the logic levels of a 3.3V IO should be alright for 5V TTL inputs. Just my 2 cents.

[james_s]

I've done that before and it worked fine for me, don't think I'd do it in a commercial product but it's probably good enough at least as a test.

[brucehoult]

As long as whatever core is used works with a 1MHz clock and the NMI handling works well, I'll be happy.

I don't think I've seen any FPGA soft cores that won't do at least 20 or 30 MHz in a modernish FPGA, and many will do 100+.

I believe that -- unlike many of those 1970s NMOS microprocessors -- you should also be able to run any FPGA soft core with an arbitrarily slow or stopped clock. There were CMOS versions of z80 and 6502 with that capability, but I don't know about 6800.

[james_s]

What happens if you run the older CPUs with a clock that is too slow or stopped? I've never tried that.

I can confirm that the soft cores (that I've tried) can run at arbitrary speeds from single step all the way up to ludicrous speeds relative to the original CPU. I played with one that ran a Z80 at I think 80 MHz.

[chickenHeadKnob]

What happens if you run the older CPUs with a clock that is too slow or stopped? I've never tried that.

registers are DRAM and their bits bleed away without refresh.

[Kleinstein]

If this about a different pinout for a 6801, than the obvious choice would be an adapter board to use a more normal 6801/6803 than an adater board with level shifters for an FPGA.

[Kleinstein]

What happens if you run the older CPUs with a clock that is too slow or stopped? I've never tried that.

registers are DRAM and their bits bleed away without refresh.

It really depends on the CPU. Some type need a minimum speed - though I somewhat doubt it would be really internal DRAM for the registers. There are logic parts like counters that can be implemented easier with capacitors.

Some or the older 8 bit µCs run OK even at 50000 mHz. 

[chickenHeadKnob]

It really depends on the CPU. Some type need a minimum speed - though I somewhat doubt it would be really internal DRAM for the registers. There are logic parts like counters that can be implemented easier with capacitors.

Some or the older 8 bit µCs run OK even at 50000 mHz. 

Yes the parts that had static implementation - typically CMOS versions like 65c02 could be single stepped. Try that with NMOS 6502 and it looses its marbles. There is an area reduction with DRAM cells for registers.

[brucehoult]

What happens if you run the older CPUs with a clock that is too slow or stopped? I've never tried that.

registers are DRAM and their bits bleed away without refresh.

I believe there could also be so on-chip capacitor-based voltage conversion.

[chickenHeadKnob]

What happens if you run the older CPUs with a clock that is too slow or stopped? I've never tried that.

registers are DRAM and their bits bleed away without refresh.

I believe there could also be so on-chip capacitor-based voltage conversion.

Could be, but I thought all the early chips had linear regulators. These days a company like ST makes a marketing point of mentioning if a cpu has switching buck   conversion for power efficiency and supplying limited current for external parts. Example: most of the STM32H7xx parts have onboard smps  along with the standard LDO except for the STM32H750.

[Kleinstein]

The early chips has not on chip regulator at all. The requires supply is provided externally. With the very old ones this could have been multiply voltages (e.g. -5 V, +5 V and maybe +9 V) .  On chip regulator to run the core at a lower voltage is a relatively new thing, maybe starting with MIPS / ARM µCs.

Some flash based µC chips have internal voltage doublers for a higher write votlage for the flash. Just an CPU with no internal flash memory does not need a higher voltage. Some of the early flash chips also needed an external high voltage. Newer ones often include internal clock.

[chickenHeadKnob]

I have just been doing some historical reading. Turns out both 6502 and 6800 had voltage doublers to get 5V operation, so now I don't know. I always had the idea that the first processors were hand optimized and needed minimum area thus dram cells instead of static flip-flops to get the yields high and costs low.

 Original poster probably irritated with me for derailing this thread.

[james_s]

I remember some of the old stuff used weird voltages, some early DRAM chips required at least two different voltages. By the time I started playing with this stuff it was pretty much all 5V though.

[dmendesf]

Not only register memories... Sometimes dynamic logic was also used as a mean to use less area:

https://en.m.wikipedia.org/wiki/Dynamic_logic_(digital_electronics)

[SiliconWizard]

Not only register memories... Sometimes dynamic logic was also used as a mean to use less area:

https://en.m.wikipedia.org/wiki/Dynamic_logic_(digital_electronics)

Yes, I was going to answer this just before I saw your post!
Jeri had a video about this:

[TK]

NMOS 6502 can do single stepping while the clock runs at full speed. Woz published a circuit to make it possible by using SYNC and RDY signals, and a couple of FFs and switches

[brucehoult]

https://www.reddit.com/r/beneater/comments/foezld/wozs_circuit_to_singlestep_nmos_6502/

[metertech58761]

Just stopping in to drop off a copy of the schematic of my project as it stands now.

Sorry if the sections are a bit too modularized. That was a byproduct of having to change many subsections to address safety and general availability of parts.

Hopefully the comments I added to show what's what helps.

[joeqsmith]

Do you have the source code, or planning to copy the PROMs from a working system?

[BrianHG]

Just stopping in to drop off a copy of the schematic of my project as it stands now.

Sorry if the sections are a bit too modularized. That was a byproduct of having to change many subsections to address safety and general availability of parts.

Hopefully the comments I added to show what's what helps.

Just out of curiosity, are you trying to make a board which always demands a 6800 variant.
90% of your logic can be directly replaced directly inside the FPGA.
Almost everything else will run directly from 3.3v unless you need a level translator to 5v to drive an IO port.
You may still use external roms if you truly need to and their modern counterpart roms already support 3.3v.
Without the roms, your IO count shrinks to just the peripheral IOs.
8Kb of rom +  4kb ram can all fit inside fairly small FPGAs today.

I understand if you do not want to venture into HDL.

In fact, a 6800 is so simple, 100% of you circuit can be simulated with your 6800 rom code is you were to implement all the logic of your design in HDL.  Modelsim which comes with every vendor's FPGA tools can handle this with ease and give you a scope waveform and text readout of your 6800 code driving the IOs while you feed it inputs before you build anything at all.

[metertech58761]

I would love to see how much of the logic I can implement in FPGA, especially since the RAM requirement is well under 256 bytes (including memory mapped I/O).

The code I have (I have a disassembly dump that I am in the process of adding comments to what parts I currently understand) pretty much requires a 68xx processor, because of the interrupt code.

Heck, I'm sure with some proper setup, I'm sure a 68HC11 would work just as well.

I know a core exists for the 6821, and there seems to be one for the 6840 as well (but I don't know how much I'd have to pay for that one).

I'll start a thread under the projects subheading so I can have a few eyes looking over my design as well as explaining the different parts - maybe I have a glitch in my design and the chip may be good.

[BrianHG]

Everything except the opamp and transistors/transformer can be done in the FPGA.

We are talking the peripherals IO & timer & button mux/demux, including rom and ram.

In your simulation testbench, you can run/stop code and even decode your 7 segment display into ASCII text to be seen on the waveform scope as well as add simulated button toggles to the input ports via code, or an ASCII source test scrip.

All scope outputs can also be saved to an ASCII file or spreadsheet.

If you have no HDL experience, I would recommend SystemVerilog as a lot can look like C programming.  However, remember it is not, it's just a lot of the if, loop, and some declarations of functions are really close.

Modelsim which is what you use before feeding your chosen vendor's FPGA compiler your source code during development can handle all this with compile times and simulations within a second.  It will allow you to inspect every register and memory register's value as you step or run code at any time.


Note that Modelsim comes with the latest Lattice Diamond, as well as Altera/Intel Quartus and Xilinx.

[james_s]

I find that the fact Verilog resembles C to be a hurdle rather than an asset, it's a bit like those "false friend" foreign words that sound a lot like something in one's native language but mean something entirely different. I don't want to start a holy war in this thread but if you do want to venture into HDL I'd suggest trying a simple project in both VHDL and Verilog and see which one feels more comfortable. Personally I've stuck with VHDL, I tried to like Verilog but it still looks like abbreviated gibberish to me. I don't do this stuff every day so I appreciate the verbosity of VHDL when I go back to work on something I haven't messed with in a while. I can type much faster than I can think anyway so the extra typing doesn't bother me. Anything that can be implemented in one language can be implemented in another though so it's really a matter of preference.

[joeqsmith]

I would love to see how much of the logic I can implement in FPGA, especially since the RAM requirement is well under 256 bytes (including memory mapped I/O).

The code I have (I have a disassembly dump that I am in the process of adding comments to what parts I currently understand) pretty much requires a 68xx processor, because of the interrupt code.
...

I assume then you're attempting to replicate something still supported and there's risk to posting the firmware to a public forum.   

Seems like there may be little interest in the vintage aspect.  Once fully reverse engineered I would design a new system from the ground up.  May as well use modern parts and tools to support it.

[metertech58761]

One of the things I want to do is get away from the vintage 8279 LED / display driver, and that portion I HAVE fully reverse engineered and understand how it works.

I'd prefer using a generic 4x4 matrix keyboard (the one on the original is a bespoke unit), and I'd prefer to use an LCD as the output (have figured out how I want it laid out even).

As for the support status of the original; few units of the original were made and that specific platform was officially superseded almost 30 years ago.

[AaronLee]

Without spending a lot of time to read and digest everything in this thread, my first thought is have you considered using an ARM (or similar) CPU running a 6800 emulator, rather than trying to emulate it more precisely via an FPGA? I've had good success with reverse engineering old systems and emulating the old CPU/MCU on an ARM CPU, along with various other external devices, combined with new modern interfaces. For example, old systems that use lots of data/address lines to interfaces can be replaced with SPI/I2C. It generally requires disassembly of the hex file into assembly code, and then further analysis, either automated or manual, to generate some C or other higher level code, in order to fully understand everything, and then modify the code as necessary to utilize the modern interfaces. Not a trivial task at all, but for me so very rewarding when I totally reverse engineer a system like that.

Trying to do the same via an FPGA is doable, but to me seems much more complicated, though that might depend to a huge extent on the exact nature of the system you're dealing with.

[metertech58761]

How accurate is that 6800 emulator?

Most of the coding isn't that critical, but I have a feeling that the one interrupt-driven routine is (it's even tied to the NMI line).

[james_s]

You might be interested in my Heathkit ET-3400 FPGA replica, it's a minimal 6800 based system that might get you started.

https://github.com/james10952001/Heathkit-ET-3400. It's targeted to a rather old and cheap FPGA platform, it doesn't take much in the way of resources.

[BrianHG]

Instead of going through all this work, why not just use a simple modern 5$ MCU and replicate your PCB's function.  Modern programming languages would make reading and timing an IO while controlling a display a breeze.

In fact, a 5$ 32bit MCU like a DSPIC doing 80mips with anything you can write in 'C' would probably be able to software emulate a 6800's opcode at 4-8x speed just via a look-up-table for decoding the opcode & run the function as well as all your peripherals being coded in a similar fashion.  Not to mention you will have access to something like 64 or 128 kilobytes of instruction memory plus 16kb of ram.

[metertech58761]

Brian: At this point, it comes down to getting an understanding just how the interrupt routine works.

The main executable merely places a message sequence in one block of RAM, sets a few flags, waits, then reads back the results. The interrupt routine does all the heavy lifting.

I may end up putting up a dump of the interrupt routine (~840 bytes) in the programming section.

[SiliconWizard]

If this about a different pinout for a 6801, than the obvious choice would be an adapter board to use a more normal 6801/6803 than an adater board with level shifters for an FPGA.

Yeah, but finding 6801 CPUs these days is not easy either. A (admittedly quick) search yielded approximately nothing.

[brucehoult]

If this about a different pinout for a 6801, than the obvious choice would be an adapter board to use a more normal 6801/6803 than an adater board with level shifters for an FPGA.

Yeah, but finding 6801 CPUs these days is not easy either. A (admittedly quick) search yielded approximately nothing.

Yeah, I just trawled through digikey.

CMOS z80 and 6502 are readily available for under $10, including in DIP if you want that.

8051 and 68000 and 8088 and various PowerPC are all available but seem to start at $50 minimum.

I couldn't find any trace of 8080 or 6800 or even 6809.


You might or might not be able to easily translate your 6800 code to 6502. The instruction sets are similar but there's a mismatch in register sets.

It would be easier to write a simple 6800 emulator for ARM or RISC-V or maybe even AVR.

[james_s]

Translating a 6800 design to use a 6502 would be an interesting academic exercise but it certainly sounds like a roundabout way to make a working project.

[brucehoult]

Translating a 6800 design to use a 6502 would be an interesting academic exercise but it certainly sounds like a roundabout way to make a working project.

We are told the main part of the code (the interrupt routine) is 840 bytes, so probably around 400 instructions.

The hardest thing is that the 6800 has two accumulators while the 6502 only has one. However in 6800 programs the B accumulator is often used for little more than increment, decrement, compare all of which can be handled by the 6502's extra "index" register. The 6800 data8,X addressing mode can be handled by using a zero-page pair XX to represent the 6800 X register and then "LDY #data8; FOO (XX),Y". That seems like more code, but 6800 programs often do a *lot* of loading different pointers into X in turn (and maybe incrementing and storing them), while on 6502 you can just use the pointers right from their home in ZP, so the code is often smaller (and faster).

It's probably no more than a day's work to convert an 840 byte interrupt routine to 6502.  Or to AVR or ARM or RISC-V for that matter.

[Kleinstein]

For translating the code one kind of needs to know the function and what are the intendend parts are and what are side effects that later have no further effect. A more local translation may work with rather similar CPUs with a similar status register, but would fail with different ones (e.g. AVR or Z80).
depending on what the code does the execution speed may matter and faster is not always right.

With an understanding on what the code actually does one could as well translate the code to C and than use a faster CPU to make up for the speed.

[metertech58761]

Unfortunately, there are a few 6800-specific instructions / modes used that would make a 6502 rewrite a challenge (and yes, I did take a look at that).

In particular - use of the D register (and not just to write into consecutive RAM locations), and three instructions in particular: MUL, ASR, and NEG (the latter are all in the interrupt section).

There are a few other 6800-style instructions involved (mostly in the 7K of main code), but those are easier to work around, and redoing that part into 6502 or C++ would only be time-consuming.

What's the best way to share code? I actually have this in an Excel spreadsheet (easier to sort and find instances of code etc.)

[brucehoult]

Oh! The D register and MUL instruction are 6801/6803 not 6800.

If you need MUL with decent performance then that's a big problem.

The other things you can do with D are easy to fake up: load / store / add / sub / lsl / lsr

[SiliconWizard]

Given the relatively small code size and the simple instruction set, if you can't get ahold of a true 6801, the most sensible thing to do IMHO would just be to disassemble the code, figure it out and then rewrite it in whatever language for whatever target fits the requirements and you are comfortable with.

Trying to implement/or reuse a software emulator for 6801 or a HDL code on a FPGA, especially if you have no prior experience with those, is likely more work and more headaches. Just my 2 cents.
You can take a look at this for instance: https://github.com/Arakula/f9dasm

[bingo600]

Wouldn't this guy solve it ??

https://www.ebay.com/itm/133559825921

https://www.scribd.com/document/311751238/HLN062-Microcomputer-Data-Book

Or the HD6803
https://www.ebay.com/itm/361788716735
https://www.ebay.com/itm/363345251235

The MC6801 was a single-chip microcomputer (that today would also be called a microcontroller) incorporating a 6802 CPU with 128 bytes of RAM, a 2 KB ROM, a 16-bit timer, 31 programmable parallel I/O lines, and a serial port. (The MC6803 was the same except without the ROM and with fewer different bus configurations.) It could also use the I/O lines as data and address buses to connect to standard M6800 peripherals. The 6801 would execute 6800 code, but it had ten additional instructions, and the execution time of key instructions was reduced. The two 8-bit accumulators could act as a single 16-bit accumulator for double precision addition, subtraction and multiplication.[77][78] It was initially designed for automotive use, with General Motors as the lead customer. The first application was a trip computer for the 1978 Cadillac Seville.[79] This 35,000 transistor chip was too expensive for wide-scale adoption in automobiles, so a reduced function MC6805 single-chip microcomputer was designed.

The MC6801 was one of the first microprocessors with a multiply instruction.[78]: 4–45 

The Hitachi HD6303 (not to be confused with the Hitachi 6309) is a second-source reimplementation of the Motorola MC6803, with a few additional instructions, and a slightly faster implementation of the 8x8 multiply instruction. The Hitachi HD6303 is used in the first PDA, the 1984 Psion Organiser.[80][81] The Hitachi HD6303 was also used in the 1983 "Pocket Telex".[82]

Or scrap this board , and get 6821's too
https://www.ebay.com/itm/194361823959

Edit:
This guy made a (i think cycle accurate 6801) in a BeagleBone Black
http://www.jks.com/5370/5370.html
https://github.com/jks-prv/5370_proc

I have one in my HP5370B   


/Bingo

[brucehoult]

Wow, "new old" stock.

And there's someone in Australia selling 6809s!

https://www.ebay.com/itm/202326008513

I think I want one. I don't know why. Other than I helped build a wire-wrapped 6809 designed with a couple of my fellow students in 1983. And it's the ultimate CISCy 8 bit. But an AVR will kick its butt.

[SiliconWizard]

To be fair, the ultimate would be the 6309 then. https://en.wikipedia.org/wiki/Hitachi_6309
It's relatively easy to find on eBay, in particular the 63C09E variant.

[james_s]

Translating a 6800 design to use a 6502 would be an interesting academic exercise but it certainly sounds like a roundabout way to make a working project.

We are told the main part of the code (the interrupt routine) is 840 bytes, so probably around 400 instructions.

The hardest thing is that the 6800 has two accumulators while the 6502 only has one. However in 6800 programs the B accumulator is often used for little more than increment, decrement, compare all of which can be handled by the 6502's extra "index" register. The 6800 data8,X addressing mode can be handled by using a zero-page pair XX to represent the 6800 X register and then "LDY #data8; FOO (XX),Y". That seems like more code, but 6800 programs often do a *lot* of loading different pointers into X in turn (and maybe incrementing and storing them), while on 6502 you can just use the pointers right from their home in ZP, so the code is often smaller (and faster).

It's probably no more than a day's work to convert an 840 byte interrupt routine to 6502.  Or to AVR or ARM or RISC-V for that matter.

As much as I think it's fun to play with vintage CPUs, I really can't think of a good reason to use one for this instead of a modern (AVR or whatever) microcontroller, unless the goal is nostalgia, education or just one of those "because it's there" challenges.

[metertech58761]

The 'original recipe' 6800 is a no-go because of no D register and missing opcodes.

The 6809 is a no go, because the opcodes are different.

The 6801 / 6803 stock version would probably work, but I would need to know how to configure the ports to be address / data pins.

I saw a mention of a 68xx emulator for ARM, and that would be of interest...

Hopefully I can have the ROM dump cleaned up and a list made of addresses and their functions so I can post a PDF of both within a couple days.

[brucehoult]

The 6809 is a no go, because the opcodes are different.

But it's probably an easy disassemble-reassemble job, if you can disassemble.

[metertech58761]

Bruce: I did go through all the opcodes, and I remember now the complete lack of the ASL D / LSR D opcodes was the deal killer.

I did double-check the 68HC11, and I realize that one IS an option after all, since it does have every. single. opcode. that I need from the 6801 opcode set.

I would not need to make any coding changes or allowances for it to be able to run on the HC11 (but I do see a bunch of stuff that could / should be optimized or made consistent in the code).

Instead of trying to scrape up another of the unobtainium SC44125 CPU or even a 6801, maybe I need to lower the bar an inch or two and start looking for a 68HC11 (preferably the memory-less version?).


Also, firmware dump and memory map are attached.

[AaronLee]

Translating a 6800 design to use a 6502 would be an interesting academic exercise but it certainly sounds like a roundabout way to make a working project.

We are told the main part of the code (the interrupt routine) is 840 bytes, so probably around 400 instructions.

The hardest thing is that the 6800 has two accumulators while the 6502 only has one. However in 6800 programs the B accumulator is often used for little more than increment, decrement, compare all of which can be handled by the 6502's extra "index" register. The 6800 data8,X addressing mode can be handled by using a zero-page pair XX to represent the 6800 X register and then "LDY #data8; FOO (XX),Y". That seems like more code, but 6800 programs often do a *lot* of loading different pointers into X in turn (and maybe incrementing and storing them), while on 6502 you can just use the pointers right from their home in ZP, so the code is often smaller (and faster).

It's probably no more than a day's work to convert an 840 byte interrupt routine to 6502.  Or to AVR or ARM or RISC-V for that matter.

As much as I think it's fun to play with vintage CPUs, I really can't think of a good reason to use one for this instead of a modern (AVR or whatever) microcontroller, unless the goal is nostalgia, education or just one of those "because it's there" challenges.

I agree. If you just want to copy an old board, then, by all means, just get the original components and make a copy of it. If you're not making a copy / repair, go with a modern MCU, and study the code of the original and learn a lot in the process. There's a lot to learn / challenges either way (using a different chip be it modern or vintage), but if you port the old design to a modern design, there's a good chance that you can reuse some of it at a later point for a different project, and even if not, at least knowledge on a modern chip that's always useful when making new projects.

[brucehoult]

Bruce: I did go through all the opcodes, and I remember now the complete lack of the ASL D / LSR D opcodes was the deal killer.

But ASL D is exactly the same as ASL B;ASL A isn't it?

[metertech58761]

I guess I have been at it a while, haven't I?
It's mostly been in brief bursts, however - not continuously.

Here's the original dump.
There is one change I made when I started analyzing the firmware, however.
In the original dump the display RAM range will be at 0x0C69-0x0C78, whereas my analysis moved it up to 0x0C30-0x0C3F.
(better allocation of available RAM and makes it easier to understand the display RAM at a glance)

[bingo600]

Just had a quick glance at your Schematic
https://www.eevblog.com/forum/fpga/replicating-a-custom-6800-in-fpga/?action=dlattach;attach=1271020

 MemoryMap & the ROM code


I noticed 2 things

1:
There's no "External IRQ2" on a MC6801/MC6803  , in fact i haven't seen more than 2  IRQ's  - NMI + IRQ1 on the 6800/01/02/03 series ... except the additional FIRQ for the 09'.
Your schematic has a IRQ2 pin.

2:
The 6801 internal registers ($00 - $1F) will overlap the MC6840 Timer and the MC6821 PIA in ALL modes , even 03.
If you want to use the 6801 , and can live with "One IRQ" , i suggest you use mode 3 , and move the 6840 & 6821 to another address range



According to your ROM , you are only having 2 active "Vector routines"  RST and NMI (IRQ_EXT)  , seems like NMI & IRQ1 use the same handler

Code: [Select]

        FDB     M0000                   ; FFF0: 00 00          '..'
        FDB     M0000                   ; FFF2: 00 00          '..'
        FDB     M0000                   ; FFF4: 00 00          '..'
        FDB     M0000                   ; FFF6: 00 00          '..'
        FDB     vec_IRQ_EXT             ; FFF8: F5 8F          '..'
        FDB     vec_RST                 ; FFFA: E0 03          '..'
        FDB     vec_IRQ_EXT             ; FFFC: F5 8F          '..'
        FDB     vec_RST                 ; FFFE: E0 03          '..'

I see IRQ2 is used by the PIA , and NMI used by the Timer  , what is using IRQ1 ? 
Is that the 8279 ?

Edit: IRQ1 Seems to be the Max706 watchdog in lower right of schem. ... correct ?
https://datasheets.maximintegrated.com/en/ds/MAX705-MAX813L.pdf
But Pin4 on that is a Max706 input , what am i missing ??


The schematic is "small" my pdf reader won't zoom enough in , to make things easy readable

 
You could maybe "OR" the Timer & the watchdog to NMI , i would expect you could query if the timer generated  the NMI , ... Else it must have been the "Dog"




/Bingo

[bingo600]

Back in ancient time my first real MCU system was a 6809 FLEX system.

And it just hit me ....  From
https://www.cpu-world.com/CPUs/6809/index.html
 
Motorola 6809 (MC6809) is an enhanced version of the 6800 microprocessor. The 6809 is not object-code compatible with the 6800, but it is source-code compatible.
You might just assemble the disassembled 68xx source code for the 6809 , and use a MC6809.

There could be electrical/pinout incompabilities , and there was also something with an "E Clock" on one of the MC6809's   - ISTR the one ending in 6809E

But the 09' has no internal stuff in the $00-$1F range , and you wouldn't have to move the Timer & PIA.
Maybe worth a try.

I'm not en EE , so the electrical pinout , has to bee looked into.
But you would have to make an adapter print even if you chose the FPGA way.
Btw: I'm not sure the 6809 has a multiplexed addr/data bus.

And maybe the E-Clock has to be looked into.
I think the 6809E or was it 68B09E could run 2MHz , and needed that E-Clock, for running pheripal 1MHZ devices w. the 2MHz MCU clock.
I would avoid an E' MCU , unless you already have the E-Clock on your board, you said you needed 1MHz.


/Bingo

[metertech58761]

Regarding the IRQ / IRQ2 lines, I’m not entirely convinced they are needed at all, as there is NO IRQ handler in this code, only the NMI line.

The pulse train that drives the NMI line is derived from the 6840 PTM’s IRQ line.

Perhaps the IRQ / IRQ2 lines could be tied off completely, and the MAX706 would only be needed to give a reset pulse on power-up.
I just adapted the circuit from the originals that I reverse-engineered; I did recently find those schematics again and could post if needed.

I wasn’t aware of the fact the standard 68xx MPUs reserved those specific locations; the SC44125 likely had those hard-wired internally to free up those addresses for external use.

I want to tweak the address decoding anyway so I can combine the two separate blocks of RAM into a single chip.

As for the odd doubling of vector addresses at the end of the ROM, I did notice that as well, and  I think only the last two really matter anyway.

[bingo600]

I wasn’t aware of the fact the standard 68xx MPUs reserved those specific locations; the SC44125 likely had those hard-wired internally to free up those addresses for external use.

It's not all of them that has Internal stuff at $00-$1F , but the 6801 & 6803 does

/Bingo

[bingo600]

I just toyed a bit more 


Build 6801 Disassembler - My choice was dasmfw (Seems to be a newer version of f9dasm)
https://github.com/Arakula/dasmfw


Disassembling the provided ROM Binary , using dasmfw
-
#Convenience macros off , and comment = '*'  * makes as01 happy

Code: [Select]

./dasmfw -dasm 6801 -noaddr -nohex -noasc -cchar '*' -conv off -cref on -info S00060G.nfo -out S00060G.asm -offset E000 S00060G.bin

Now code is in : S00060G.asm

Fixup a few disassembly quirks ... I have no idea why the below 4 Labels are referred to ,  but not created.

Add the below labels somewhere in the S00060G.asm , i chose just before "Program's Code areas"

It will look like this when you are done

Code: [Select]

MAABA   EQU     $AABA
*
* Disassembler Missing labels to add to the source before assembling
*
MF0FF   EQU     $F0FF
MF61D   EQU     $F61D
MFB1E   EQU     $FB1E
MFFFF   EQU     $FFFF
*
* Disassembler Missing labels end
*

*****************************************************
* Program's Code Areas
*****************************************************



Clean a lot of the FCB $00 lines , near the end of the program.
No worries , the aseembler will fill the area with $00's when creating the binary. And it is neded for a "MC6809 trick comming in a while"


Near the "Label MFD43" , you will see the last line that contains anything but $00 - The line containing : FCB     $02,$00,$0F,$00 .......

Delete all Lines , until the first line containing :         FDB     M0000

Just above the line containing :         FDB     M0000 
Insert an : ORG     $FFF0  - To put the vectors back in place


It will look like this when you are done

Code: [Select]

MFD43   FCB     $FF,$00,$00,$01
        FCC     ":"
        FCB     $00,$C0,$03,$C0,$03,$C0
        FCC     "D"
        FCB     $0F,$FF,$FF,$FF,$FF,$FF,$FF,$FF
        FCC     "A"
        FCB     $02,$00,$0F,$00,$00,$00,$00,$00,$00,$00,$00,$00,$00

* Delete a "kazilion" FCB $00 lines here

        ORG     $FFF0

        FDB     M0000
        FDB     M0000
        FDB     M0000
        FDB     M0000
        FDB     vec_IRQ_EXT
        FDB     vec_RST
        FDB     vec_IRQ_EXT
        FDB     vec_RST


Now the soure should be ready for the assembler

I tried the below first , works fine for mc6801 & mc6809 , but can't generate mc6809 code from mc6801 source , the Aracula A09 can do that.
https://github.com/JimInCA/motorola-6800-assembler


Build the Arakula A09 68xx assembler
https://github.com/Arakula/A09

Copy your "modified" disassembler source code (S00060G.asm) to the Aracule "Binary dir"

Build both MC6801 & MC6809 binaries from the source

M6801

Code: [Select]

s:~/tmp/6802-bin/assemblers/a09/A09-master$ ./a09 -oM01 S00060G.asm -lS00060G-01.asm.lst -bS00060G-01.bin

M6809

Code: [Select]

s:~/tmp/6802-bin/assemblers/a09/A09-master$ ./a09 -oM09 S00060G.asm -lS00060G-09.asm.lst -bS00060G-09.bin


Verify that the MC6801 binary is equal to the original binary , diff in "-b" binary mode will only output something if the files are different

Code: [Select]

diff -b S00060G.bin S00060G-01.bin

Now you should have both a MC6801 bin and a MC6809 bin , built from an "Available source code"

For the MC6809 - You might want to correct the FIRQ Vector at the end , or make it Reset the beast...
Read up on FIRQ, if you ever use it. It won't save any registers for you , in IRQ entry or restore on exit.
That ought to be the only thing to observe on the MC6809.

The attached A09-Sources , is not A09 related (that's on github)
It is  the disassembled  source , and the listings + bins from the A09 assembler.

Edit: Added the missing disassembler "definition nfo file" - copy to the dasmfw dir

Edit2: I hope you use linux 

/Bingo

[bingo600]

Btw:
RE : https://www.eevblog.com/forum/fpga/replicating-a-custom-6800-in-fpga/msg3703185/#msg3703185

The disassembled ASRD is a "convenience mnemonic" , that can be replaced with the two instructions
ASRA
RORB

See :
https://github.com/Arakula/A09/blob/master/a09.c

   v1.48 2021-02-22 additional PEMT capabilities
                    ASLD,ASRD,CLRD,DECD,INCD,LSLD,LSRD convenience mnemonics added
                    to all 6800-based assemblers

  { "ASRD",    OPCAT_TWOBYTE,     0x4756 },  // ASRA RORB

I specifically disabled those macros , to make the source "more compatible" with the simple assemblers found.

conv on|off
noconv
Quite some assemblers know "convenience mnemonics"; these are evaluated to a combination of

#Convenience macros off
s:~/tmp/6802-bin/dasmfw-master$ ./dasmfw -dasm 6801 -noaddr -nohex -noasc -conv off -cref on -info S00060G.nfo -out S00060G.asm -offset E000 S00060G.bin

[brucehoult]

Now you should have both a MC6801 bin and a MC6809 bin , built from an "Available source code"

What's the size difference?

Performance difference would be interesting too, but that's harder to estimate.

[metertech58761]

You had me a bit confused when you mentioned the ASRD macro, but I just had a peek at the source code and do remember one of the test segments has multiple ASR A / ROR B instructions.

I don't have the assembly tools you have on hand yet (I have a Mac, and I made the unfortunate decision to 'upgrade' to the newest model with the M1 chipset, losing the use of my Windows VM in the process), so am not sure how I can validate these files at the moment.

Anyway, using a more manual process, I went through the code with a fine-tooth comb to try and make it a bit more clear and where possible, a bit more consistent / efficient (especially initialization, displaying the current test number, and especially the relay pass / fail evaluation code sections). See if the attached firmware checks out in the tools you have at hand.

[bingo600]

Now you should have both a MC6801 bin and a MC6809 bin , built from an "Available source code"

What's the size difference?

Performance difference would be interesting too, but that's harder to estimate.

Code: [Select]

MC6801-bin
MC6801-bin
-rw-rw-r-- 1 bingo bingo   8192 Sep 27 21:09 S00060G-01.bin
MC6809-bin
-rw-rw-r-- 1 bingo bingo   8282 Sep 28 02:06 S00060Gx-09.bin
Seems like the MC6809 code increases by 90 bytes  (and wraps , if we don't delete some of the FCB $00 lines)

Here the 09' list file , that shows the wraparound

Code: [Select]


 FFEE 00000000000000          FCB     $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$0
0,$00,$00
 FFF5 000000000000
 FFFB 00000000000000          FCB     $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$0
0,$00,$00
 0002 000000000000
 0008 00000000000000          FCB     $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$0
0,$00,$00
 000F 000000000000
 0015 00000000000000          FCB     $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$0
0,$00,$00
 001C 000000000000
 0022 00000000000000          FCB     $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$0
0,$00,$00
 0029 000000000000
 002F 00000000000000          FCB     $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$0
0,$00,$00
 0036 000000000000
 003C 00000000000000          FCB     $00,$00,$00,$00,$00,$00,$00,$00,$00,$00,$0
0,$00,$00
 0043 000000000000
 0049 00                      FCB     $00
 004A 0000                    FDB     M0000
 004C 0000                    FDB     M0000
 004E 0000                    FDB     M0000
 0050 0000                    FDB     M0000
 0052 F58C                    FDB     vec_IRQ_EXT
 0054 E002                    FDB     vec_RST
 0056 F58C                    FDB     vec_IRQ_EXT
 0058 E002                    FDB     vec_RST



/Bingo

[bingo600]

See if the attached firmware checks out in the tools you have at hand.

I'm not sure what you want me to do with that bin file ??
I have no way of doing much but to disassemble it , and why ... You apparently have the source.

/Bingo

[brucehoult]

I don't have the assembly tools you have on hand yet (I have a Mac, and I made the unfortunate decision to 'upgrade' to the newest model with the M1 chipset, losing the use of my Windows VM in the process), so am not sure how I can validate these files at the moment.

I'm not sure why you'd want to run Windows, that just seems like unnecessary pain.

I love my M1 Mac Mini. Great machine!

Most Linux'y stuff compiles and runs fine on either x86 Mac or ARM Linux so if no one has quite gotten around to tweaking it for ARM Mac then you have two options:

- type "arch -x86_64 bash" in a Terminal.app window to compile and use x86 software in Rosetta

- run ARM Linux in a VM. I've been doing that since November. e.g. see this which I last updated on Nov 23 2020 https://hoult.org/arm64_mini.html

[bingo600]

What's the point of even bringing up the 6809?  It's just as obsolete as the 6801 and derivatives, and I don't see that the extra features have any value here.  It would make a lot more sense to use some version of the HD6303, or maybe the 68HC11 as already mentioned.

I have no prefs. , and thought it was a "One off"
The HD6303 seems to fit the bill too (as a 6801/03) replacement , but still have periphs at $00..$1F , overlapping with the current Timer & PIA mapping.
The 6809 doesn't have those.

/Bingo

[metertech58761]

Definitely a one-off / hobby project.

Since the HC11 is far more available than the 6801/6803, that would be my preference, especially since it uses the exact same opcodes etc.

[bingo600]

I just assembled the source code with as11 , no issue at all.

https://github.com/JimInCA/motorola-6800-assembler

Code: [Select]

./as11 S00060G.asm -l >S00060G-11.lst


If you are "lucky" (HC11 ressources) you might be able to use the HC11 as Timer and PIA

Nice HC11 site
http://www.hc11.demon.nl/thrsim11/68hc11/

[metertech58761]

Really?! That version compiled with no hiccups?! Cool! (considering I did NOT use a standard assembler to make that version)

That would be awesome if I could combine the PIA and PTM into the HC11...
All three timers in the PTM are used (one is used as an internal programmable delay, the second drives the _NMI line, and the third is XOR'd with the outgoing data stream).

I know of a board that was part of this system that probably did just that, but I have not been able to track down the particulars of the HC11 that was used in that role.
I'm guessing it too was a custom variant (it was a 68-pin PLCC whereas pretty much all the remaining HC11s available are 52-pin PLCC).

Anyway, I want to see if I understand correctly how to connect the HC11 in 'expanded' mode - here's a schematic I worked out for an "adapter".

[bingo600]

Remember ... That it assembles the source , doesn't mean it will work w. the HC11 internal timers etc.
You would need to "decode" the timer & PIA usage , and replicate that w. HC11 "internals"
I even think it created a 100% equal .bin file  HC11 vs "Original bin"

This one might come in handy to understand the Timer ... The DS is a bit cryptic i think.
http://www.bitsavers.org/components/motorola/_dataSheets/MC6840UM.pdf

I'm not an EE , just a hobby'ist.
The electrical design should be reviwed by someone else.

Good info
https://mil.ufl.edu/3744/software_hc11.html


HW Inspiration
https://inworks.ucdenver.edu/jkb/legorobots/hardware.html


Mux'ed
https://www.kswichit.com/C11evb/C11evb.htm


https://hackaday.io/project/171451-68hc11-cpu-board-for-rc2014
https://cdn.hackaday.io/files/1714517335359584/68hc11.pdf

Non mux'ed
https://www.cs.uml.edu/~fredm/handyboard.com/oldhb/schemv12/hbsch12.pdf
https://mil.ufl.edu/3744/docs/11EVBU-SCH-D.pdf




Edit: You do know the HC573 is a 373 with a much nicer pin layout

/Bingo

[SiliconWizard]

Remember ... That it assembles the source , doesn't mean it will work w. the HC11 internal timers etc.

Quite right of course. And with that said, although the CPU the OP is trying to replace supports the 6801 instruction set, nothing tells us that it acts as one either - be it for cycle-accuracy, interrupts, and so on...

[bingo600]

If clocked by 1MHz as the 01' , and given that the Binaries were "equal" i'd expect the normal instructions to execute 1:1
IRQ could push a bit more or less , but that's prob. not an issue.


/Bingo

[metertech58761]

Regarding 'just because it compiles doesn't mean it will work', it turns out you are correct...

I had the opportunity to look through the source code I'm making and found one opcode I forgot to change.

Also, going back and taking a closer look at the main loop to better understand how it works actually revealed that one section of 15 bytes was accidentally repeated by whoever originally assembled this code (but, given the inefficiency of parts of the code I've since cleaned up, not terribly surprising).

Going back to post 76, I was hoping to verify that I understood how the R/W line is supposed to be derived when using the HC11, or if I am supposed to use the STRB/RW line directly.

[metertech58761]

Just a quick postscript before I start a couple new threads elsewhere.

In the end, I chose to use a 68HC11F1 (the 68-pin PLCC version).

For one, it has on-board RAM, which allows me to consolidate the two RAM ranges and eliminate the MC6810 and HM-6561 SRAMs once and for all.

The other is that it has the 6801 opcode set, so changes to the firmware should be limited to just relocating the upper RAM and I/O ranges.