I spent the past week at my parents' place and decided to tackle a project that I've wanted to do for years: run my own code on a Model 3 PCB. I've had a VF3 PCB lying around here for a good 10-12 years. The previous owner put it in a nice case with fans and even included an ATX PSU wired up to be used with it. Originally, I was unable to obtain a monitor compatible with the Model 3's medium frequency timing, and so it collected dust until last year, when I discovered that an Acer LCD monitor my parents had worked great with it.
A few weeks before coming out here, I built a Windows-hosted powerpc-603e-eabi cross compiler (gcc 5.1.0) and set about writing a simple test program and all the required startup code. I added support to Supermodel for loading arbitrary ROM images and, with the aid of the excellent debugger Nik wrote, managed to write a simple program that could print text to the screen using the tile generator. Getting that far was more work than I expected! I then went on an eBay shopping spree and purchased a cheap device programmer (which I am very pleased with), EPROM eraser, IC extraction tool, a few sets of M27C4002 EPROMs, and an assortment of components I thought I might need.
With everything seemingly ready to test out my super-simple "hello, world" program, I carefully connected my VF3 board to its power supply, removed the four VF3 EPROMs, inserted my replacements, held my breath as I flipped the power strip switch on and ... nothing! A black screen! How was I going to debug this? There is quite a lot of setup involved in bringing up a PowerPC system that Supermodel cannot emulate (such as the MMU), so the problem could have been anywhere. Fortunately, I was able to flash patterns on the board LEDs to determine that my code was indeed running. The problem lay with the tile generator. Now it so happens that Model 3 uses the System 24 tile generator, so I fired off an email to Charles MacDonald who pointed out a few things to me. I began debugging by using Supermodel to capture everything Virtua Fighter 3 writes to the tile generator and system registers up until the region warning screen shows up, creating a sort of "save state" I could test on the actual hardware. This worked -- I was able to duplicate VF3's warning screen -- and a quick process of elimination led me to what I was missing: the JTAG interface.
I always assumed the JTAG port was only used for verifying ASIC ID codes and performing some tests. But JTAG is much more versatile and on Model 3, it evidently provides access to hardware registers not mapped to the address space. VF3 writes a lot of data to the JTAG port, some of it obviously for testing purposes. Rather than trying to painstakingly figure out which precise command enabled video output, I simply execute them all. Applied to my test program, I got this:
Hmm... Not quite what I wanted. And why are there colored pixels when I only wrote monochrome to the palette? After wasting a whole day trying to figure out what I was doing wrong, I decided to try something radically different. I replaced the 4-bit character set I was using with VF3's 8-bit font. Then, crucially, I used Supermodel to comb through VF3's VRAM state with a fine-toothed comb and duplicated it carefully. There were some bits in tables I didn't understand the purpose of which apparently did the trick because it now worked! Voila!
And for the true nerds among us, I've even uploaded a brief video of the board LEDs cycling through a pattern I programmed.
What was learned from this exercise? Of practical use to Supermodel and MAME: not much. I've confirmed the location of the board LED register (but had already guessed it) and discovered that the refresh rate is somewhere near ~57.5 Hz (rather than 60), but the latter could more accurately be determined with an o-scope. However, I now have a foundation on which to build and hopefully conduct more useful experiments in the future.
Unfortunately, vacation is over and I don't think I'll be shipping this rather fragile board (which I may even have damaged a bit with the constant, forceful re-insertion of EPROMs) to New York. Further experimentation will have to wait until next time I'm back home. In the mean time, I'm contemplating picking up a Step 2.x game, because those should be a little friendlier to work with. I'm also curious whether any games (Lost World?) have an accessible serial port interface that could be used to upload code, because EPROMs take f-o-r-e-v-e-r and the force required to seat them properly makes me nervous.
For anyone interested in viewing the code, it's on github: https://github.com/trzy/model3/
If there's any interest, I could also upload my MinGW-based cross-compiler.