Unearthing my 1996 windowed OS in machine code for Am29000 homebrew computer

Developing a windowed OS for a homebrew Am29000 computer by Oscar Toledo G. Jul/30/2026 Once upon a time in the mysterious lands of Mexico, starting in Fall 1996 and through Spring 1997, I coded a windowed operating system in 32-bit machine code, fit it into a floppy, and jumped in excitement as it boot up. Of course, I knew it was a great thing because you couldn't boot Windows 3.1 or GEM from a floppy disk, but I was very far from knowing how so cool it was. Unfortunately, not a thing I could give away for everyone to see, as it was written for a homebrew computer based on the Am29000 processor. Let’s go back to my memories, some notes, and the ride of discovering again what I forgotten. The world's fastest processor If you've been following my series of articles on transputer, I was feeling very satisfied with my operating system, and I had reached the limits of the system. My father on the other side was busy developing a new computer system based on a new 32-bit processor. Well, in 1994 it was only new for us. The AMD Am29000 processor came out in 1987, also announced as the world's fastest processor (do you see a meme here?) and it could process one instruction every cycle, so indeed it was fast. The Am29000 processor and its successor the Am29050, were used in several Postscript language add-ons for printers, video NuBus cards for Quadra Macs, arcade games like F-15 Strike Eagle and Battle of the Solar System (both by Microprose), and I read in the Wikipedia it is also inside avionics in dual-processor boards for redundancy. This speed was based on a ton of assumptions, like having speedy enough RAM or ROM, or having very high-speed TTL chips. And all three were still very expensive in the early 1990s. Besides some bus design decisions for the Am29k family like a separate data and instruction bus made it really cumbersome to interface it. At the end, doing anything useful with the Am29k required DRAM memory, and it was slow, and then all the advantage was lost. However, my father was confident in static RAM memory and he sourced dozens of 128KB static RAM chips with 8-bit bus. Surface mount started to making an appearance and several of these were built with four 32K RAM chips mounted in nice miniature green boards. So the first Am29000 computer made by my father ran at 6 mhz, and it had the whooping memory capacity of 512 KB of RAM, along 128 KB of EPROM (using two 16-bit chips). It had ISA connectors, and the video was a Cirrus Logic GD5429 card, along a standard parallel/serial/floppy-disk controller card (multiport card), and reused the keyboard chip from an old PC to interface AT keyboards. This computer was called G11. It was a team work, he did some initial programming to start the processor, I translated my Z280 code for initializing the Cirrus Logic VGA, made the keyboard decoder, and the disk routines. Once this was stable, I went ahead to work in the monitor program for listing the memory, saving data, and as the instruction set was complicated enough, I also integrated a micro-disassembler and a micro-assembler. This means we could code with real mnemonics, although no labels could be used, also moving code was a complete pain. We needed to return to the Z280 machine to program the EPROMs, but everything was going really well. I stumbled in the dark reality that I needed to port everything from the Z280 machine to this machine, it was like 200 programs between applications, utilities, and games. Besides the Z280 programs were basically outdated, I couldn't replicate the same. I wanted a G11V1 picture, but there were no digital cameras before 1999 and I don't know where is the machine. So this is a picture of a G11V2 computer, you can see four 512KBx8 memories and it has already PCI bus (not present in the G11V1). Intermission As the G11 computer was finished, my father took over it and started to investigate how every processor special register worked or why it had certain values, and writing documentation about it. I was somewhat startled, because I believed the processor was already documented in its databook, and I wasn't interested in undocumented behavior, but anyway, I ended typing all his notes and printing them. I could concentrate on the transputer now that it was available for my use, and I switched ocasionally to the G11 computer when it was free in order to enhance the floppy disk operating system, I started coding some games, a text editor that handled our new Canon BJC-600 bubblejet printer, and even a MSX emulator. This was the first time I could see Gradius running, I was hooked. I was recreating my Z280 programs, and I felt like I was going backwards when I had already an advanced operating system in the transputer. In the meanwhile, Windows 3.1 looked more useful with all its icons in shrill colors, a product of the palette inherited all the way from CGA. I was interested in discovering how to do a windows system, but I couldn't get my hands on a programming book for Windows 3.1. Local libraries were still filled with tons of Turbo-C, Turbo-Pascal, Quick-BASIC, and QBasic books. Finally, I got a discount book about OS/2 programming, and I started to read it. The author did an excellent work introducing OS/2, and it was easy: open a window, draw in the window, close the window. The real discovery was... badum-tss the message pipeline. Every process with windows has a message pipeline, and when you create a window you should assign it a kind of interface handler (the window class), and this handler reads the messages and it does operations according to the user’s interactions. The user’s interactions are simple for starters, a message indicating a click from the mouse, a message for moving the mouse over the window, and then things start to get complicated with double-click messages. You can create windows inside windows, but these are controls like buttons, slide bars, icons, indicators, status bars, etc. And these controls can send messages back. The beauty of this is that you could develop user interfaces very fast, and every single program looks great (well, in the 90s we weren't really too exigent, as Digital Research’s GEM can testify) While researching for this article, I discovered I still had a box where AMD shipped two databooks. Someone dropped it at post office in June 7, 1990. The windows system First, I needed multitasking. I found this daunting and complicated, and I ended learning how to do cooperative multitasking. It saved the current state, loaded the new state, and jumped to the new place. Sorry, operating system designers, I didn't think about it. I just wanted it to work. Second, I needed windows. I scratched my head really hard thinking how to overlay things one over another. Then while I was reading file after file of a new CD-ROM bought by my father, I discovered X11R5. In case you didn't know, X11 is a networked windowing system designed to work with almost any graphic terminal, and as universities had a lot of different hardware, it should work on all of them. Of course, this means it was extremely clumsy for handling color or games. The important thing here is that the CD had the complete source code for X11R5. Of course, I couldn't find use for it as my computer didn't had a network, nor a C compiler, but instead a single source code file was enlightening: XRegion.c. The algorithm's basic concept is that every single window has a rectangle display list. If a window isn't overlapped then the rectangle covers the whole window. If a window is overlapped, cut the overlapped rectangle, and continue cutting every overlap. This means that if a rectangle is cut in the middle, it creates four rectangles, and for displaying information, you should try drawing in the four rectangles. So a heavily clipped window is slowly drawn. By the way, Apple has a trick for this, it uses a clipping bitmap, but it is a patented technique. Third, I created an extremely simplified API specification in my notebook based on what I learned from the OS/2 book, and this made coding a lot easier. While OS/2 (and Windows 3.1) use a graphical context for drawing with pen types and fill patterns, I considered this too cumbersome, and you draw directly in the window in pixel units. Specifications of the first few functions of my windowing system. User interface design for the debugger (Depurador) With these three pieces I started coding my windowing system in machine code starting in Fall 1996 thru Spring 1997, I was age 18, and I really never thought that my micro-assembler worked against me. It was easy to use, and I could code routines very fast, and then my micro-disassembler showed me exactly the same I wrote. I just needed to write some pointers in paper, but unfortunately this wasn't exactly source code. This article is possible because I have two disks with the early machine code version from 1997. I know I had something good, even if primitive, as no other windowed operating system boot up from a floppy disk, but it is impossible someone else could experience it without an Am29000 computer. So let’s code an emulator! The 1997 disks The main directory of the bootable disk looks like this: The directory of the bootable disk. The ESPEJO.IMG is the dump, and the folders have the date of the restore. Two floppy disks of 1.44mb capacity with my windowed operating system and programs. My first task was writing an Am29000 emulator. I have the user's manual somewhere, but instead of losing time searching for it, I lost time searching for it in Google, and nothing available. I was surprised, because it was available a few years ago, anyway, I went to archive.org and I got it pretty easily after typing the chip number. I consider the relational-assert instructions the biggest waste of silicon space in the Am29k series of processors. I suppose the designers had a use case because the military required the Ada language, but I'm just speculating. Another curious idea is the result valu