While other parts of the renovation are calmly cooking, I thought I’d spend some time on actual coding.
I dumped the original EPROM’s, analyzed its contents (even tried to disassemble), but they are hopelessly corrupt. No real problem, code is available so I can build new ones.
I had two avenue’s to choose from. In the code base, compiled hexfiles were included, from which I could extract the EPROM part. The documentation has clearly described how the memory is organised, on which addresss space lives what, so that was pretty forthcoming.
But how much fun would it be to compile itself and build a file?
The original code was compiled and build using Microtec ASM68K and LOD68K linker. Interestingly enough, a somewhat later version of that package is available online, so I grabbed it along with a manual. The linker now has a new name but it should work. And indeed, it compiles the assembly code without a hitch. One assembly file and one include and it coughs up an object file. I linked it without any options just to see what happens and presto, another hex file. Now comes the fun part.
They are slightly different. This may have been because of the way I linked the compiled object file. Analysis shows that my compiled file does not contain the Exception Vector Table, even though it’s defined in the code.
Next weekend, I’ll play around with it some more. I can at least burn new EPROM’s from the hex code I have. Interestingly enough though, the board had 2 EPROMs installed. The compiled code only fills a fraction of a single EPROM, so what was the second doing there? It’s at moments like this I wish I could get access to the Other Direct machine and read the EPROMs in there 🙂 It could be that the other EPROM contained some routines and data that wasn’t going to change anyway. Right now it doesn’t really matter, I’ll revisit later.
Another thing I’ve been doing is writing new code that will help me tell if everything on the mainboard is healthy. The machine’s architecture isn’t that complex. One Motorola CPU, some memory and 5 DUARTS for I/O.
So I created 2 diangostics roms. The first one is really simple. It will boot the machine, and sound a beep. In order to do that, I have to initialize DUART number 3 (on which the Buzzer lives), and generate a single beep.
If I install that EPROM and boot the machine (mind you, after all other hardware issues are resolved), and it beeps, then I know that at least the CPU and DUART 3 works.
I also created another diagnostics ROM that goes a bit further:.
– It boots the CPU
– Tests all 5 DUARTS. If one fails it stops with one long beep.
– It performs a ram validation check, if that one fails, it stops with two long beeps if it can..
– If it passes, it plays 3×3 beeps and outputs ‘Hi!’ on the dot matrix display.
I have a ton of 27C512 EPROMS, an eraser and burner, so I can go to town on this. Matter of fact, I wonder…..if I can run the complete compiled code from EPROM to begin with….