Bernhard "HotKey" SlawikI had the feeling that I was going around in circles: Adjusting some assembly code, compiling, burning an EEPROM, inserting it, bootstrapping the RAM cartridge for CP/M, switching from ROM to RAM, booting CP/M, loading a .COM-file over serial, running it, ... and crashing.
This became very tiresome quickly, as you can imagine.
"Emulation to the rescue!", I thought. So I took a deep dive into the MAME source code and patched the PC2000 emulator: I changed the memory banks to be write enabled to simulate the RAM-switching hardware mod needed for running CP/M. I also added a debug port that allows sending and receiving data to/from MAME via stdin/stdout.
That worked like a breeze. Now it's only one click to compile and pack the CP/M ROM, fire up MAME, load CP/M and open a data channel between the emulated CP/M machine and a python "host" script. This really speeds up the process of loading and altering code for debugging. I also added a TRAP function to BDOS, which allows stopping the program flow at a desired address, dumping registers+stack, and continuing with the execution.
Having these tools at hand, I quickly identified a bank-switching bug and an error when reading records from files.
I crossed my fingers, uploaded "ZORK1" to the emulated CP/M and gave it a try...
...it opened the "ZORK1.DAT" file...
...read some records...
...then some more...
...and even more...
...and more...
...until finally:
Yeeeeha! I've never felt better, standing in an open field on a cold night like this :-D
Don't get too excited, yet, because I immediately ran into the next 2-3 bugs with the keyboard handler. So it is not really playable at the moment. But this has been a really big milestone.
Update: It's usable!
A little fix in memory layout here, a change in keyboard layout there and...
Christmas may come! :-)
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
When I "upgrade" to a Z80 then that will be fine (I am currently using an 8085).
Now the 0x0038 and 0x003c vectors (RST7 and RST7.5) were not trashed by the one program I examined. So what you say seems consistent.
Regards AlanX
Are you sure? yes | no
I have been though the same process. The pins fell off my ROM!
I am using an 8085, I made the mistake of using software serial. The problem I found with using RST6.5 for the software serial interrupt is that many programs trash the RST vector area. I need to do further research which RST interrupt vectors are not regularly trashed. At the moment RST7.5 looks okay.
AlanX
Are you sure? yes | no
I can give you a hint: Start your code with the two instructions "DI" and "IM 1". The latter switches the Z80 into "single-interrupt mode": It then only has one single interrupt handler (vector at 0x0038) which gets called about 50 times a second. As long as your own interrupt handler returns with "RETI", you should be fine.
Are you sure? yes | no