A couple days ago Esot.eric dumped the two EPROMS on the board, U9 and U32. I spent a little time with those images, and Esot.eric suggested I share my findings thus far (there is much more to go, but that will take several days work).
U9 is the character generator ROM, and U34 is the 'boot' ROM. Why the quotes? Well, we're pretty sure it is more than just the boot ROM. For starters, a boot ROM would not need to be 8K -- 2K would be more than sufficient to init the system and load the second stage loader off disk (and indeed earlier Kaypros did have a 2K boot ROM), so the current thinking is that it contains other subroutines that are of use at runtime.
The Kaypro is a CP/M machine, and those familiar with CP/M will know that one of it's quirks is that it requires RAM at the bottom of memory. Yet 0000h is the reset vector for 8080 and Z80 (for which CP/M was created), so you've got to have ROM there at least during boot up, and that generally implies some sort of bank switching to get it out once you've gotten past boot. So far, so conventional. Also interesting is that the ROM does not reference any RAM locations below 8000h (even though this one is only 2000h long), so it seems that Kaypro had plans to possibly expand this ROM-based subroutine approach in future models, and set up their codebase accordingly.
I'll cover the disassembly findings in a subsequent post in more detail (i.e., when I have details to post!), but some interesting things have come out already with a cursory scan:
- there are some peculiar register addressings related to video
The video is mostly controlled by the then-popular MC6845 (or clones). This chip has 18 registers, and is interfaced through two physical addresses: the first is the address register selecting which of the 18 internal registers is being operated upon, and the second is the data register that is mapped to the selected register. So far so straightforward, but I noticed in the code many times accessing of a register 1Fh, which does not exist on the chip. Blargh! My mind is boggled.
- to add confusion to befuddlement, there is a physical port 1fh that is routinely accessed in the (ostensibly) video driver code. But this one I think I have more of a handle on:
The video memory on this unit is composed of two 6116 static RAMs, 2K each. Hmm, this device has an 80x25 display, which is 2000 characters, so why do we need a total of 4K? Hypothesis: attributes. 8 bits for character data, and some more bits for things like high-intensity, inverse video, etc. Some of Esot.eric's screen shots show that these capabilities are there, so we know we need the extra bits. Also, the 6845 is essentially a fancy address generator -- you still have to implement circuitry to shift out pixels and blend in sync pulses and whatnot. So, the video memory is typically being addressed and controlled by the 6845 on a continual basis, and not mapped into the CPU's direct address space. But something's gotta let us write data into video memory!
There is a gate array in this machine (actually two). Since it is a custom chip, it is a black box from the standpoint of analysis, and could be doing anything. So, my hypothesis in this case is that the port 1fh is decoded by the gate array, and is used to access the video memory to write characters into it. And probably the attribute bits as well. Much more work will be done in this area.
- As was common on many machine designs, the address decoding may take shortcuts by not decoding some bits and thus creating aliases in the address space. This was typically done simply to save on parts count ($) but was Hell on 3rd party expandability. This was done here as well, and A6 does not contribute to the decoding of port addresses, and so there are IO aliases of the first 64 ports into the 40h-7fh space. Fortunately for the rest of the world, they did decode A7, leaving the upper 128 ports for others, which brings me to my point: I have noticed in the ROM I/O accesses to ports 81h-87h, which are not standard Kaypro 2x ports. Hmm. Ain't that something? It's so obvious now, but it wasn't until I woke up this morning that I realized that the boot ROM is also custom to the Omni4 (over the Kaypro 2x), and that these ports must be part of the logic analyzer daughterboard. Also, because there is customization of the boot ROM, it further suggests that Omni either had a close business relationship with Kaypro to have access to the source code to modify, or they were hackers that reverse-engineered it. My guess is the former, but the latter was not at all uncommon in those days (for fun, search "Michael Geary Adobe Type Manager" to learn about an (in)famous case, and the wrath of the software pusblisher whose code was reverse-engineered). Anyway, my suspicion is that ports 80h-87h (at least) operate the Omni4 daughterboard, and it is very good indeed that we have the ROM dump, because disassembling the code on the floppy would be insufficient. Thanks Esot.eric!
Since it is going to take me several days to analyze and comment this ROM dump, for fun in the meantime I decided to code up a little program to transform the character generator dump into something meaningful to the human eye. Attached herewith in the files section is OMNI4U9.txt containing that result. I didn't think that much of it at first, but Esot.eric believes that some of the graphics characters are non-standard, and are used by the Omni4 software to depict timing waveforms. So, once again, thanks for the dumps, because that will make disassembling the logic analyzer program make much more sense knowing what the special characters look like!
Next, I must weave time between real-world responsibilities and code archaeology, so it may be a week or so before I have the ROM disassembly completed. Or sooner if my burning desires overcome my sense of responsibility -- this has happened before, alas....