Close

"You are standing in an open field..."

A project log for V-Tech Genius Leader / PreComputer Hacking

Turning a toy into a hardware tinkering platform

bernhard-hotkey-slawikBernhard "HotKey" Slawik 12/02/2019 at 22:223 Comments

I 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:

ZORK - on a VTech Genius Leader 4000 running CP/M inside MAME
ZORK - On a VTech Genius Leader 4000 running CP/M inside MAME

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...

ZORK on a toy computer, anyone?
ZORK on a toy computer, anyone?

Christmas may come! :-)

Discussions

agp.cooper wrote 12/04/2019 at 23:14 point

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

agp.cooper wrote 12/02/2019 at 23:09 point

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

Bernhard "HotKey" Slawik wrote 12/03/2019 at 00:56 point

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