When homebrewing a CPU, one has to deal with microcode. Microcode is the low-level nuts and bolts of how, precisely, a CPU executes instructions (like opcodes) and performs functions such as updating the cycle counter or handling interrupt requests. To make this task easier, [Bob Alexander] created a microcode compiler built in Google Sheets to help with his own homebrew work, but it’s flexible and configurable enough to be useful to others, as well.
A CPU’s microcode usually lives in read-only memory, and writing the microcode is only one step in the journey. [Bob]’s tool compiles his microcode into files that can be burned into memory (multiple EEPROM chips, in [Bob]’s case) or used as a Verilog program in the case of implementing the CPU in an FPGA. It’s configurable enough to be adapted for other homebrew CPU projects, though one would of course have to re-write the microcode portion.
A read-only version of the spreadsheet makes for some fun browsing, and if it piques your interest enough to get a copy of your own complete with the compiler script, you can do that here. It uses Google Sheets, and writes the output files into one’s Google Drive.
This kind of low-level project really highlights the finer points of just how the hard work of digital computing gets done. A good example is the Gigatron which implemented a RISC CPU using only microcode, memory, and logic gates in the late 70s. We’ve even seen custom microcode used to aid complex debugging.
it’s a fun use for a spreadsheet, for sure, but personally i cringe at it because i put all my projects in git. i like having the history, and i want the diffs to be meaningful human-readable summary of changes.
it just reminds me how badly i want a good text-file-based spreadsheet. it’s easy to imagine binding a key in nvi to run a program which re-computes the computed fields in a text file. but i haven’t come up with a syntax that hits the sweet spot for me. really i’d just be happy if some gnumeric sort of program had a decent output format that didn’t involve so much useless information that produces verbose diffs every time you move the cursor.
you are right, people that use this kind of binary stuff can burn.
Emacs org-mode table can do that, you can do formulas etc
Maybe a Spreadsheet program that saves things in a CSV? So it saves the formulas as is, without calculating and then for unit types it just uses like “$”
for money “‘”for raw text, “$” for a specific currency, d/DD/MM/YYYY for dates etc. This way the spreadsheet is text. (Although maybe you might want to use newlines or something instead of commas so that cells are on different lines?)
Maybe something like Microsoft’s SYLK/.slk file format, but updated for the modern age?
There are spreadsheet programs that store data, etc. as XML. Technically, it’s a text filev but must not be the “text file” you’re looking for.
Modern spreadsheets are all XML inside. But XML being the abomination it is, needs some very strict formatting to make it even minimally useful in git. And even then you are still dealing with hard to read diffs.
yeah i thought this would be awesome…but in practice, it isn’t.
in 2023 all my git commits for gnumeric spreadsheets have thousands of nothing-diffs. it has way too much information encoded in the XML file, most of which is of no human interest (formatting, last-modified-on timestamps, enumeration). i understand why they do it that way and haven’t come up with anything better myself but that’s the problem i want to solve. it’s simply not useful to look at diffs of a gnumeric xml file, generally.
and all my 2024 git commits for gnumeric spreadsheets are binary diffs. i assume it’s like a gzipped xml file but that’s kind of discouraging that it changed back to a binary format.
“sc” is a text-file based spreadsheet. Look on Wikipedia for “sc (spreadsheet calculator)” to learn more about it.
thanks! it has a lot of challenges too from my perspective but it’s good food for thought
I’ve never tried anything in that direction but I’ve thought about the same problem a few times.
One idea I came up with is storing one spreadsheet not in a single text file but in one text (csv-like?) file per layer:
– visible layer (content)
– formulas
– formatting (+ which cells are connected and so on)
– other meta data?
(+ a sync/meta file containing checksums of all single files so the editor can be sure they fit together?)
I assume git allows some kind of filtering where diffs only show one or a few of those file types.
“When homebrewing a CPU, one has to deal with microcode.” – no one has not, really. It’s a choice, and it can be a fun choice, but it is perfectly possible to create a CPU without any microcode.