Replicating a 'custom' 6800 in FPGA

[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