The main reason is just due to me knowing my own limitations. SRAM is really simple to interface with and i've not yet tried to write a DRAM controller since its much more complex. Putting SRAM on the board made me more confident about the project. I did have it in mind that I could try to use the DRAM in place of the SRAM at a later stage (as you suggest) as a good way to focus on learning how to use it.

Really cool, I figured that was the case and I'd be in the same boat.

I have an ice40UP5k board but I quickly ran out of block ram and LUTS whenever trying to use it for anything substantial, but seeing this project has me itching to start something around one of these icesugar pro boards. yosys & nextpnr support made things really damn easy when I was working with the ice40.

Thats an oversight on my part, I should put a license on it. I would love for anyone to be able to build one or tinker with the code as they want to. After all I was only able to make this because others shared their projects that I could learn from.

I would suggest CC-BY-SA

You can do this by doing as little as making a single file named LICENSE in the top level directory, with a single line:

    This work is licensed under CC BY-SA 4.0. To view a copy of this license, visit https://creativecommons.org/licenses/by-sa/4.0

That's it.

It is the hardware/artwork spritual equivalent of GPL2. It means the user must not remove your name, must make source/plans available, and commercial activity is ok.

Just a suggestion if you don't know where to begin or what to do, hadn't really thought about it or read up on all the infinite options etc.

Thanks for the suggestion, I've added this license to the project.

This license is, AIUI, OSH compliant.

Awesome. Thank you for releasing your work as open hardware.

Thank you so much for this. The sheer amount of work, skills and knowledge you put into getting this to boot and operate is fantastic. And I think everyone here agrees that you did this in the best way: by using a real CPU. Really appreciate you sharing this with us.

The bus controller was fairly straight forward. I found the timing diagrams in the V20 datasheet to be pretty easy to follow. The clock for the CPU is generated by the FPGA which I derived from a clock running at twice the speed, that made it easy to pick which clock edges I wanted to sample from or assert data for the CPU on. I did have a bug or two in there early on which meant that memory writes would not store the data I was expecting as I sampled the data bus at the wrong time. That was a tricky one as the bug would only become visible when that location was loaded from again. The CPU i'm using is rated for 16Mhz, but i've only tried to push it up to 10Mhz so far so I have a bit of margin. Some more issues might pop up if I push the speed higher I suspect. Its very stable as it is now and i've not seen any issues I could attribute to the bus handling.

>I derived from a clock running at twice the speed

aah, so CFG_ENABLE_20MHZ runs cpu at 10. I was surprised you could run the bus at 20MHz with this FPGA devboard, 10 makes more sense.

As I touched on that in HaD comment this is not a good devboard :( It has terrible pinout https://github.com/wuxx/icesugar-pro/tree/master/schematic all 100 signals huddling together in the middle with only 9 ground pins among them. Very bad for signal integrity. Whats worse someone in China actually decided to sell it commercially :( Luckily you made it work.

a busy loop waiting for an interrupt to fire?

This is reasonable, but for the sake of your power budget I hope you use a wait-for-interrupt instruction instead rather than just spinning :)

You mention that you have traced out every transistor from die photos, and I was wondering how much work there would be to make a netlist for the 8086 like that which was used to produce the visual 6502 simulator?

It that feasable or is there lots of work to do to get to that stage?

I'm loving your series on the 8086 btw :)

I'm working on a simulator :-)

Oh fantastic! this makes me super happy to hear :) I'd love to play with it.

(That sounds brilliant!)

Using an HDL like Verilog or VHDL? Something else?

I'm planning on a visual6502-style simulator in a browser.

What I'm curious about is how this has been done. I don't think that the source for UT99 has been released, so does icculus have access to the source and has then ported it to emscripten, or has it been decompiled from x86 and then recompiled for WASM, or is it running on an x86 emulation layer programmed in WASM? I presume it was from source, given that everything else is prohibitively hard just for a demo like this.

Some members of the UT99 community have access to the sources

This is great, I've been wanting an ISA card with an FPGA on it for a long time so that I can experiment. I've ordered a few of these PCBs to build some myself. Its very kind of the author to give the design away for free. I also really like the Lattice FPGAs for their FOSS tool-chain, which is a breeze to work with.

I've honestly never seen .C used in the wild. I imagine anyone whose written a bit of portable code would immediately realize this is a bad idea.

Haven't really seen it in the wild, but I see it every day in a very large proprietary codebase I work in.

I only know it as an extension for "interpreted C++ scripts" as used by CERN's ROOT. It is considered good practice to make them compilable but the interpreter used to be very lenient (before they integrated it with clang) so that usually didn't happen.

Anyway I would never rely on the C compiler invoking the C++ compiler; I always write g++ or $CXX. I wonder if there is a downside to that.

Just for an example, the OpenFOAM codebase has 'em.

Its still blows my mind that he fit this in ~1k LUTs. I'm new to FPGA but the closest I got was about 4.5K LUTs for a comparable core.

I wish there were more easy to access material about timing and size optimization for FPGA.

see also https://github.com/olofk/serv for small core!