Fixed a bug in the FPGA-Elf

My friend Ken pointed out that unlike a real Elf, my FPGA-Elf didn’t display the contents of memory if you repeatedly press the input button while in load mode with memory protect enabled.  At first I couldn’t figure out how the real Elf did that, but careful study of the schematic and the 1802 manual revealed the secret.  In load mode, the 1802 continuously reads and ignores the contents of memory.  However, it reads from the address one less than the contents of R0.  The Elf hardware latches the displays during this read, and NOT during the memory write cycle when you press the input button.  Thus the Elf always displays the contents of the address prior to the next address available for writing.  This also means that when you first enter load mode, it displays the contents of address FFFF (hexadecimal).  On a minimal Elf, the high byte of the address is ignored, so it displays the contents of address 00FF.

I’ve updated my 1802 core and Elf VHDL files to match this behavior.

This entry was posted in FPGA, RetroChallenge. Bookmark the permalink.

3 Responses to Fixed a bug in the FPGA-Elf

  1. juergen_uk says:

    Hi How could I get hold of the ELF for FPGA?

  2. Dave S says:

    Are the VHDL files and any other supporting documentation available for download? I would love to be able to try this at home on my own FPGA demo board. I’m wondering if this is cycle-accurate to the original 1802? Could it be used in conjunction with an 1861, or is a VHDL version of the 1861 available???

    My Spartan FPGA board has a VGA output connector on it, what would it take to make things work with an emulated 1861 going to a VGA monitor?

  3. Eric says:

    I haven’t released it as open-source yet, mostly because I haven’t gotten around to testing the full instruction set and interrupts. I hope to finish that in January.

    The core is cycle-accurate at the machine cycle level, but not at the clock cycle level. The CDP1802 uses eight clock cycles per machine cycle, while my core uses only one clock cycle per machine cycle. This means that the bus interface is not at all similar to the CDP1802. It’s more like a 6502 or 6800 bus.

    It should be possible to write a wrapper that interfaces the core to a real CDP1802 bus. Such a wrapper would have have a counter to divide by 8 to get the core clock, generate the TPA and TPB strobes, etc. I haven’t done that yet.

    To make the 1802 core work with a VGA monitor, you would need an 1861 core, which I have not completed, and a simple scan-converter to take the 1861 core output, buffer it, and drive the VGA output at normal VGA scan and pixel rates.

Leave a Reply