With the chunking of the files discovered and the executable file origin known, I was able to make a start on disassembling pieces of the PVTEST_ self-test code with Ghidra. Messages shown by the test code to the user were useful, as looking at references in the code to them I was able to located PVTEST_ code that writes text to the screen. Eventually, I found that the screen buffer is at 0x600000. It turns out, I could have also found this from the (probably non-working) MAME code for related units that I later found.
Finding an easy to use assembler took a bit, and I finally settled on EASy68K. It produces Motorola S-Records, and I wrote a python script that copied the binary data from the S-Record file to the beginning of the PVTEST_ code. I could then put the modified code into a .LIF file, and then convert that to an .HFE file for the Gotek Then I could just launch my code by going to the self-test in the oscilloscope's I/O menu, and switching disks in my Gotek drive. It was awkward, and there were a lot of reboots.
Writing to the screen turned out to be more confusing than I expected. Writing zero bits did nothing. Writing one bits did different things at different times. It turned out from the Ghidra disassembly (I could also have learned this from the MAME code) that there were different writing modes controlled by a write-only hardware register at 0x0200100. For instance, if it's in mode 0xFE00, then writing 1's produces white pixels, while in mode 0xFF00, writing 1's produces black pixels. Discovering the intricacies of the screen i/o would still be for the future, but at least I was able to do basic output--put text on screen, and draw pixels.
Next was input. I eventually found a ROM get key routine that the code called (0xEB38). With input and output I was in theory able to do a lot.
I wrote various small bits of assembly test code, including a lot of code to dump memory locations to the screen. (The latest version is here. You can specify which address to go to, and press RUN to toggle whether the display is static or dynamic.) I was able to learn where in RAM the ROM code stored the current key and various information about the spinner state. (See my ever-evolving "messy notes".)
Alexander R Pruss
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.