This is a story from the time before time, when I was in high school in Italy. My high school was a technical high school that had both programming and “systems” classes — “systems” being a shorthand for “Information processing and communication systems”, which encompassed a bit of state machine theory, networking, low level computing, and… well, turns out that it matched fairly well with Feynman Lectures On Computation, which is the book I’m reading now during the quarantine. It also included a bit of “basic computer literacy”, given that the first laboratory tasks was re-typing some math textbook pages in Microsoft Word (and not even requiring to use Equation Editor!)
I think it was on our fourth year of high school (second year of systems), that the classroom topics geared towards CPU, memory access, and so on, while laboratory became both interesting and annoying at the same time: we started learning about assembly language, but also we started that by manually assembling binaries: we were first given, then required to write, simple assembly programs, then using a paper reference tables of instructions-to-opcodes asked to write the COM file for it.
This didn’t go at all into explaining how opcodes work, things like operand selections, or even explaining why accessing the AL/AX registers is so much faster. It was just a manual translation table that a certain operation would then become a fixed set of bytes. This is why I found most of those lessons annoying at first.
Eventually, we graduated to using MASM. Which was also a bit annoying for me because at home I only had access to NASM, but it was at least a bit more interesting at the same time. Unfortunately around that time we also were introduced to how we would be testing some more features of low-level program writing: I/O and peripheral control were going to be explained and exercised through a complicated Rube Goldberg machine that consisted of:
- Create the COM/binary file on one of our lab machines, either through the aforementioned manual translation, or MASM.
- Load the binary file onto a floppy disk.
- Get the floppy disk onto the single 486 machine for the lab that has an EPROM programmer attached to it. One machine, for the whole 20 people class.
- Flash the binary onto an EPROM (nope, not EEPROM!).
- Put the EPROM back onto an 8086 motherboard, which had been jury-rigged to act as effectively an embedded micro, with a few LEDs, buttons, and step motors attached to it.
You can imagine that this was quite a waste of time overall, and also had one of the worst iteration speeds. Having always thought that the best way to learn something is to try doing it differently all the time, it was a frustrating experience, but one that I wanted to get something good out of.
So, without consulting any teacher, I sat down at my home computer, with a copy of Borland C++ Builder, a complete edition given away for free by an Italian magazine at the time, and started looking at how to simulate the 8086 CPU with a C++ program.
At that point I had barely any idea of what I was doing — I had used Borland C++ Builder already to make simple clicky-button programs for myself, but not only I had not shared them with anyone at all, but also they were pretty much horrible quality. I had also no idea how the CPU actually worked. The explanations in class had been extremely high-level and handwavey, and the registers have been always sorted as AX, BX, CX, DX.
What I did end up doing was ordering a copy of Intel’s Architecture Manuals (back when Intel still mailed them to you in print copy!) and poured hours and hours on them. Still with not much of a clue of what I was doing, but I did manage at the end to implementa janky, but usable simulator for the 8086. I originally planned to implement the I/O states so that I could simulate the step motor, but I never went down that route — instead it just executed the given program, and printed out at the end the state of all registers, and of memory.
I didn’t know about segmented memory, so I had a very naive implementation of the segment registers, but it turned out to be good enough for preparing the exercises at home, and not having to go “back to the centre” (where the motherboard contraption was) more than once per exercise.
I’m afraid I don’t know if I still have the sources anywhere. If I ever will find them again, I’ll probably publish them, despite me looking very silly. It was an usable tool for me, but not just for me — my teacher was impressed and, for the following few years, he used it himself, although I’m not sure if he did that to design the exercises or grade them. I know that a couple of years after I left school they eventually dismissed the Rube Goldberg machine in favour of PIC, but I honestly have no idea if they ended up just giving every station a programmer, or if they still required to take turns.
Some of the things that I learned while trying to implement this are still clearly stuck in my head. For instance this was the first time I tried using function pointers, and figured out that function pointers for C++ methods are not a great idea.
I have actually had this in mind when I was looking at hacking my laptop’s keyboard. Since I couldn’t find enough 8051 tools at the time, I was considering writing my own disassembler and simulator. I might even still do that, despite me not having that laptop anymore, since I’m going to be using 8051 for my art project. But in this case, I would probably just do it in Python, speed is definitely not the issue at hand here.
