Of course while you're doing the next version you should knock out a tiny tapeout version, it should easily fit in a single cell (maybe 2 if you want to push the 256 byte sram in as well)
To get both blinkenlights for registers and tri-state for bus driving, use two ’574 chips in parallel rather than a ’377 behind a ’245. Tie the clock and input lines together on both. Tie the output enable low on the one driving the blinkenlights. This way the chip that the rest of the CPU depends on doesn’t have the extra work of driving any load and you only have one chip’s worth of propagation delays.
Hi Will, absolutely amazing this, I love the 'money shot' up front, there are days my desk and yours could be swapped without either of us realizing right away what happened.
The Rigol deserves a blog post of its own, I've got one too and the better I get in using it the more I'm amazed at what it can do.
I've run into the same 'all you can get is SMD' which is fine for when you're finished but a lot harder while you're still figuring things out. This is where 'proper engineers' can go straight to the finish line and I always struggle.
You also develop some kind of sixth sense for when something is misbehaving. If you haven't read it yet, 'The Soul of a New Machine' might be to your liking.
> It’s a standalone tool that lives outside the computer. I put the EEPROM into the socket, and connect via serial to my laptop to upload the binary files.
Huh, I guess I never really thought about it, but how did they program the first CPUs? Like how did they overcome the chicken/egg situation?
Actual application code was hardwired, entered manually with switches and lights, or with punch cards. Later, when ICs were sufficiently advanced, mask-programmed ROMs/PLAs.
I'm going off memory (of a book, not that I was alive in the 40s, ha) so grain of salt etc but I believe the very earliest (edit: electronic, digital) computers were literally rewired every time they need to be re-programmed.
I always applaud homebrew cpu designs but after doing so many myself I would reaaaaly advice to stay away from dip chips/breadboards/wirewraps and any attempts to put it into real physical world. Taking a build out of a logisim/verilog to real world in chips sucks away all the fun about cpu design - suddenly you have to deal with invisible issues like timing, glitchy half-dead chip, bad wire connection, etc. these are not challenges, just mundane dull work.
The only exception to „stay in the sim“ rule is if you want to make an „art statement“, i.e. like BMOW (or my relay cpu https://github.com/artemonster/relay-cpu/blob/main/images/fr... /shamelessplug)
I'm totally with you personally, but sometimes doing the actually hard part is fun. Type 2 fun.
Long ago I took a CPU architecture class and we implemented designs in Verilog as a final project. Apparently people who took the class in the late 90s (before my time) could actually tape-out their designs and pay a few hundred dollars to get fabbed chips as part of a multiproject wafer. I was always curious if those chips actually worked, or just looked pretty.
My advice would be to consider the possibility, not necessarily to stay out of the physical world. For some, those physical details may be the fun part. Some hate verilog. Some want to put it on an FPGA, some don't. I, personally, moved away from FPGAs due to bad documentation (looking at you, Lattice).
An alternative to Verilog is RTl simulation in a higher-level Language, or even higher-level Simulation.
Just remember that you can't define what is "fun".
Of course while you're doing the next version you should knock out a tiny tapeout version, it should easily fit in a single cell (maybe 2 if you want to push the 256 byte sram in as well)
To get both blinkenlights for registers and tri-state for bus driving, use two ’574 chips in parallel rather than a ’377 behind a ’245. Tie the clock and input lines together on both. Tie the output enable low on the one driving the blinkenlights. This way the chip that the rest of the CPU depends on doesn’t have the extra work of driving any load and you only have one chip’s worth of propagation delays.
Hi Will, absolutely amazing this, I love the 'money shot' up front, there are days my desk and yours could be swapped without either of us realizing right away what happened.
The Rigol deserves a blog post of its own, I've got one too and the better I get in using it the more I'm amazed at what it can do.
I've run into the same 'all you can get is SMD' which is fine for when you're finished but a lot harder while you're still figuring things out. This is where 'proper engineers' can go straight to the finish line and I always struggle.
You also develop some kind of sixth sense for when something is misbehaving. If you haven't read it yet, 'The Soul of a New Machine' might be to your liking.
best of luck with your project!
Oh, and I did read all the way to the end.
> It’s a standalone tool that lives outside the computer. I put the EEPROM into the socket, and connect via serial to my laptop to upload the binary files.
Huh, I guess I never really thought about it, but how did they program the first CPUs? Like how did they overcome the chicken/egg situation?
Actual application code was hardwired, entered manually with switches and lights, or with punch cards. Later, when ICs were sufficiently advanced, mask-programmed ROMs/PLAs.
I'm going off memory (of a book, not that I was alive in the 40s, ha) so grain of salt etc but I believe the very earliest (edit: electronic, digital) computers were literally rewired every time they need to be re-programmed.
Yes, check out this https://computerhistory.org/blog/programming-the-eniac-an-ex...
Plugboards! Think telephone exchange but used as a ROM.
I always applaud homebrew cpu designs but after doing so many myself I would reaaaaly advice to stay away from dip chips/breadboards/wirewraps and any attempts to put it into real physical world. Taking a build out of a logisim/verilog to real world in chips sucks away all the fun about cpu design - suddenly you have to deal with invisible issues like timing, glitchy half-dead chip, bad wire connection, etc. these are not challenges, just mundane dull work. The only exception to „stay in the sim“ rule is if you want to make an „art statement“, i.e. like BMOW (or my relay cpu https://github.com/artemonster/relay-cpu/blob/main/images/fr... /shamelessplug)
I'm totally with you personally, but sometimes doing the actually hard part is fun. Type 2 fun.
Long ago I took a CPU architecture class and we implemented designs in Verilog as a final project. Apparently people who took the class in the late 90s (before my time) could actually tape-out their designs and pay a few hundred dollars to get fabbed chips as part of a multiproject wafer. I was always curious if those chips actually worked, or just looked pretty.
My advice would be to consider the possibility, not necessarily to stay out of the physical world. For some, those physical details may be the fun part. Some hate verilog. Some want to put it on an FPGA, some don't. I, personally, moved away from FPGAs due to bad documentation (looking at you, Lattice).
An alternative to Verilog is RTl simulation in a higher-level Language, or even higher-level Simulation.
Just remember that you can't define what is "fun".