V-Tech Genius Leader / PreComputer Hacking

During the last weeks I tried porting the Sierra Adventure Game Interpreter (AGI) to the VTech platform! At first it seemed impossible, since each displayed screen consists of two bitmaps of 160x168 pixels, which by itself would be more than the 32KB RAM we have on board the GL6006SL/GL7007SL.

But after some brainstorming, I came up with a two-step approach: First, render one bitmap in full res at 4bit (which fits into 16 KB), then convert it down to 160x100 which fits into the remaining 8KB page. Then, do the same for the other bitmap (and overwrite parts of the 16KB region in the process)

Well, that worked! 🥰

…and "Space Quest II" looked so cute on the LCD using a bit of dithering, that I tried to port the rest of the engine as well...

Thanks to the previous work of ScummVM and GBAGI, I ported module by module to VGLDK, alsways keeping a close watch on RAM and ROM usage.

But finally, after some twiddling (splitting the 64KB engine into two 32KB segments and bank-switching back and forth), it was possible to have the engine residing in lower system ROM, while the game files (~700KB) are put into a big external cartridge ROM.

The result: Hello, VAGI!

Okay, I must admit, there are a lot of shortcuts and little bugs remaining, and the performance is really bad at times. But you CAN indeed play SQ1 / SQ2 / KQ1 and KQ2 for a few minutes and it's fun! There's still a little bug that doesn't let you enter the castle in "King's Quest I", but that seems fixable.

You can find the code in the VGLDK Github repo inside the "examples/agi" directory, but I might fork a separate project.

During the summer break I have completely re-written CP/M for VTech Genius Leader computers!

The procedure is now simpler (better documentation, better Python based build system, better emulation options) and compatibility is much improved (ZORK1-3 and BBCBASIC work perfectly)

So check it out at my VGLDK Github at https://github.com/hotkeymuc/vgldk/tree/master/examples/cpm

A great next step now would be to create a combined ROM+RAM cartridge for a low entry barrier for any enthusiastic VTech fan. Or... maybe even a Tindie campaign for a complete self-contained "VTech CP/M Cartridge"...? What do you think?

While skimming through the local business register I stumbled upon the entry "ZiLOG International Ltd."...

ZiLOG —the Californian company that created the Z80 processor used in all the VTechs— is now part of Littelfuse and IXYS which in turn is c/o AVNET (big electronics distributor) which is literally around the corner of my house!

But so far I seem to be the only Z80 nerd around here (that I know of).

🌈 *The more you know!* 🌠

well... sort of... ;-)

...and if you don't have a graphical LCD:

There is also no game logic whatsoever, tho. Just a proof of concept.

Check it out at https://github.com/hotkeymuc/vgldk/tree/master/examples/raycast

I've been using the past months to get a new focus for the project.

Hardware hacking is fine and dandy, but the practical use for the "average Joe/Jane" is quite limited. After all, manufacturing PCBs, sourcing 74-series logic and debugging everything is not for the faint of heart.

So I came up with a new goal: Lowering the entry bar for anyone trying to run own code on an old V-Tech computer. That means: allowing unmodified C programs to just work on the VTech without hassle. Just "make" to compile, "make emu" to simulate and "make burn" to burn a finished EEPROM.

There is no easy way of sticking your own EEPROM into the computer, yet. For now you have to "sacrifice" a working cartridge and properly attach your own EEPROM to it. But it's very doable.

After having done this, you should be able to simply compile, test, burn and run your code on a 2000, 4000 or 6000 series V-Tech computer. This is already working fine using the latest version of the VGLDK.

So far, so good. But then what?

It would be soooo nice to have just a little bit more periphery to play with, like "real files", network, LEDs etc.

Following the same direction as my older "BusFicker" cartridge, I thought of the simplest way to extend the periphery by using just an Arduino. This time, instead of doctoring around with the Z80 bus, I re-visited my "Software Serial" code, completely re-wrote it in C and optimized the crap out of it. Not only is the new "Software UART" smaller than its assembly predecessor (C optimization ftw), it can even handle serial speeds of up to 19200 baud now!

Throw in an Arduino, an SD card and some wires and —voilá— say hello to the Parallel Buddy!

What can it do? Well, I'm glad you asked☺In theory it can do whatever an Arduino can do. But to keep things neat and extendable, I opted to create the concept of file systems and mounts inside the VGLDK. So with the usual "fopen()" syntax, you can now access files baked into your ROM as well as accessing any remote file system mounted on the ParallelBuddy Arduino (the Arduino sketch actually uses the same source code for its own local file system).

So: Connect the Arduino, fire up the "monitor" ROM, "cd" into the ParallelBuddy mount, and from there into the SD card or anything else you decide to put in. Your monitor can simply "cat" or "run" files directly from there! "fopen()" doesn't know the difference! ☺

I also added a rudimentary Ethernet file system through the use of a standard Ethernet shield. Just fopen("/pb/eth/google.com") and you're golden!

Be warned that the ParallelBuddy code is quite big, so you'll have to disable some other functionality to make the monitor program fit a standard 8KB / 64 Kb EEPROM. The makefile will warn you if you run out of space.

Oh, uploading files from a computer to the monitor still works as before: After power-up the ParallelBuddy Arduino sketch will stay in "bootloader mode" for some seconds, simply passing all data between the VTech and your computer, before switching over to "ParallelBuddy mode". So you can also use the Arduino as a USB-serial converter.

So: Head over to the VGLDK GitHub and give it a try! You'll find the Arduino sketch "VTechParallelBuddy.zip" inside the "tools" folder.

Cheeeeeers!

The other day, I decided to do something "completely different" for a change. So I went to my wall of VTech Genius Notebooks and grabbed a random one from the pile that had the same cartridge port as the 4000, but a larger screen.

My pick: the Genius Leader 6000SL aka. Genius PreComputer Prestige.

This time around I wanted to cheat a bit, since I didn't want to spend another 2 years analyzing it (as I did with the 1000/2000/4000 series). Instead of building a debugging cartridge and finding all the memory and port mappings myself, I just searched for some emulation source. And I found a driver in the trusty old MAME repository (src/mame/drivers/prestige.cpp). It is missing some functions (printer port, sound), but the basic stuff is there.

First thing that sparked my interest: The machine seemed to use a DMA based LCD (240x100, graphical), so there is no need for weird LCD initialization code and software frame buffer stuff. It's as simple as poking bitmap data into memory at 0xE000-0xEBB8 and it gets drawn on the screen automagically!

The keyboard is also pretty straight forward (matrix at ports 0x40, 0x41, 0x42) and didn't take much effort to get working. And even the mouse (yes, it has an external mouse!) is directly mapped to ports 0x04 and 0x05 for the X and Y positions. Nice!

I must say, I am quite impressed about how much easier it is to work with the 6000 compared to the 1000/2000 and 4000 series. It took just one day to write my first "Hello World" from scratch (including custom font rendering). I would call that an "instant gratification" :-)

The bank switching / memory mapping in the Prestige is also quite nice: It allows for the cartridge to be mapped to lower memory at address 0x0000. This means that a CP/M style system could run on that machine without any hardware modifications (i.e. no "Chip Select hack" needed)!

So maybe I'll just give it a try and create a Plug & Play CP/M cartridge for that machine!

Stay healthy!

Update: I have updated the VGLDK Github repository to allow compilation against the new "gl6000sl" target. Cheers!

Just a little status update:

With CP/M working as a proof-of-concept, an important personal milestone has been reached.

While doing so, a lot of new interesting ideas came up. That's why I am now spending a little time incorporating all the development so far into a VTech Genius LEADER Development Kit - the VGLDK.

Even though I would very much appreciate it, if the VGL support for the Z88DK would improve, I feel like it is a little bit too over-engineered and complicated for the rather "simple things" I try to accomplish. Those being: Enabling everyone to develop software for the system quickly and hassle free.

So I created a Github repo at https://github.com/hotkeymuc/vgldk and started filling it with some initial content. My current focus lies on smooth portability between the 1000, 2000 and 4000 series. (Series 3000, 5000, 6000, 7000 and 8000 may follow eventually.) Additionally, the build process must allow compiling programs for use in a cartridge ROM, as system replacement ROMs, and also for runtime-linking (e.g. when using CP/M or some sort of DOS). I might also migrate the VGL CP/M project right into the VGLDK.

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:

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! :-)

Yesterday night I pulled out my oscilloscope and tweaked the timings used by the software serial implementation. I noticed some bits getting lost and tracked it down to the "edge delay" used to sync up with the start bit.

Now data transmission is much more reliable than before. Nonetheless, it is recommended to employ a protocol with checksums and re-transmit to ensure binary proof data transmission.

So, what should we do with it?

Maybe... allow the CP/M BDOS to load files via serial from a computer?

>python bdos_companion.py /dev/ttyUSB0 ZORK1.COM
Ready.

...and then on the Genius Leader 4000: 

32K VGL CP/M 0.0.4
2019-11-14 by HotKey

>SERIALLOAD
LOADING...
OK

>RUN

Oooooooohhhhh!

I think we're on-track to playing ZORK during the holidays! :-)

This is worth another project log...

Since I got "boot from RAM" working yesterday, I eagerly started implementing the basic BIOS/BDOS functions of CP/M 2.2. No disk access, yet, but just the standard console input/output and housekeeping functions.

Fortunately, CP/M is well documented and there aren't actually that many functions that need to be implemented for a basic system.

So, I fixed my broken LCD DDRAM mapping and optimized the keyboard handler a little and added the most important CP/M BDOS functions.

Then I took a small .COM file (SYSGEN), placed it into RAM and jumped to it...

I was greeted by the program banner! It works!

That was really unexpectedly simple! The next 1-2 weeks will be used to implement a simple file system and all the necessary open/close/read/write functions, so we all can play ZORK before the year is over! :-)

Stay tuned!