The first new Model 3 program in 17 years?

[Bart]

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.

Dumping my VF3 EPROMs using the MiniPro!

photo.JPG (46.34 KiB) Viewed 15090 times

Backstage at Supermodel HQ.

workspace.jpg (115.53 KiB) Viewed 15090 times

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:

Signs of life.

test_not_working.jpg (85.11 KiB) Viewed 15090 times

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!

Success! The first Model 3 program in 17 years?

test_working.jpg (68.44 KiB) Viewed 15090 times

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.

[Joaquim Gonçalves]

I'm very proud about your encoragement working on this to makes us happy.
I hope sincerely this will give us the right way to get the perfect emulation, with everything operational fine.
2016 must be the year you can able to finish everything and after that you can enjoy even more your future vacations.
This board running after 17 years, nothing is impossible everything can be fixed even if the PCB boards get a few dust and change colour.
This is the first step to get back SEGA's jewel running up again.

See you later, after the next SVN Version.

[tabajaralabs]

Greetings from Brazil, newcomer here

I was talking in private to Bert, about the feasibility of using an eprom emulator on model 3 board. He said me it would have to emulate 4 ROMs at the same time, since this board uses a 64 bit data path. I think I can design a simple eprom emulator to plug in place of the 4 eproms, but I brought the discussion to the table because maybe someone has a better solution. Maybe a set of 4 non-volatile RAMs (BQ4017Y comes to mind, more info in http://www.ti.com/product/BQ4017Y ) with a small bootloader allowing the same model3 board to upload code via a serial port.

I haven't found any hardware info (nor schematics) about the model3 board, unfortunately. Hope I can help in something.

[obcd]

Newbie here as well. Greetings from Belgium.

Maybe a short piece of flatcable going to a small pcb with a ZIF socket could help against damage due to frequently insertion and removal of the proms.
If the cable is kept short, such an approach might work. Maybe the zif socket will fit directly in the original eprom socket.
If there exist flash chips that are pin compatible, using such could already elimenate the uv erase cycle that is needed before you can reprogram an eprom.
A sort of bootloader would indeed be a good approach. If I understand things a little, the system now copies it's eprom code to ram and executes it from there. (ram access is faster than eprom access).
I don't think you will find schematics of the model 3 hardware. For a bootloader, you will indeed need a serial port or another communication method.
Maybe a combination of a bootloader with an eprom emulator is an option. The emulator could be loaded with the code, and the bootloader could copy it
to ram and execute it from there. In such case, only emulating one eprom device might work. The bootloader could simply ignore the bytes from the other eproms. Still however, a "debug" connection like a serial port would improve design speed.
It all depends if Bart still has time &| interest to work on the project and if he thinks something usefull could be done with code running on the real hardware.

[Bart]

These are some good ideas. I think a ZIF socket will damage the original EPROM sockets but it's worth a try. Perhaps an adapter of some sort can be built. Unfortunately, it is not sufficient to emulate only one EPROM device because the EPROMs are interleaved. Each provides 16 data lines but the PowerPC has a 64-bit bus, thus requiring 4 EPROMs.

Charles MacDonald pointed out that a bit-banging could be used for communication between a PC and the Model 3 board, although it would be relatively slow. Bi-directional signalling is required and could be achieved by soldering some lines to the output LEDs. Needless to say, it's a rather invasive and complex operation. But building an EPROM emulator is no simpler.

A ZIF socket adapter of some sort is not a bad idea to begin with.

[tabajaralabs]

These are some good ideas. I think a ZIF socket will damage the original EPROM sockets but it's worth a try. Perhaps an adapter of some sort can be built. Unfortunately, it is not sufficient to emulate only one EPROM device because the EPROMs are interleaved. Each provides 16 data lines but the PowerPC has a 64-bit bus, thus requiring 4 EPROMs.
Charles MacDonald pointed out that a bit-banging could be used for communication between a PC and the Model 3 board, although it would be relatively slow. Bi-directional signalling is required and could be achieved by soldering some lines to the output LEDs. Needless to say, it's a rather invasive and complex operation. But building an EPROM emulator is no simpler.
A ZIF socket adapter of some sort is not a bad idea to begin with.

A zif socket can be easily fitted, but not without some soldering. The pin profile of most sockets is flat, but 90 degrees rotated from what a common stamped socket is designed.

DIP pin profile: |
ZIF socket profile: --

The best alternative I could think about is firstly, changing the original stamped sockets to turned pin sockets, and soldering (!) another turned pin socket on bottom of the ZIF socket. So you can pull the ZIF socket out, and insert normal EPROMs on its place. This is the approach I use when I have to do this kind of "gambiarra" (it is a portuguese word for something "jury rigged" or like).

About using flash: It is real easy to do. $10 in boards and you can build a TSOP48 to DIP42 adapter, where you can solder surplus 29LV160 (or else) chips and program it without need to UV Erase. Even if you build a Xenon Flash Eraser (which erases EPROMs in 2-3 seconds, have you seen it?) it is easier, faster and safer to use simple surplus Flash ROMs. The problem is to find something which is 5V tolerant. I can create the boards to be sent to OSH Park or Dirty Cheap PCBs if you like.

The EPROM emulator isn't "hard" to make. It is troublesome. Each EPROM emulated would need some 3 TTLs, 1 to 4 RAM chips (if you can afford the BQ4017 non-volatile chips from TI, you can use just one ram chip) and a microcontroller (and a pc program) to upload code to each "emulated EPROM". BTW, talking about that now I remember - AFAIK, the BQ4017 chip is pin-compatible with the 27C160 memory, so you can just pull it, program (sram!) and put it in its place. You just need to pull /WE pin and tie it thru a 10K resistor to VCC.

Lots of options Hope I can help!

[krom]

Wow nice I only just saw this, amazing stuff =D

If there's any interest, I could also upload my MinGW-based cross-compiler.

I would love this MinGW-based cross-compiler, I have always wanted to dev on the Sega Model 3 HW.

What is the GPU triangle setup like? Would be amazing to make a simple OpenGL style lib to display 3D graphics...
I could make blender exporters for 3D/2D content etc, would be pretty ace to get more homebrew on this system.

Anyway thanks for doing this demo, & releasing the source.

[Bart]

I've uploaded it to: http://www.trzy.org/files/model3/mingw64-ppc-gcc-5.1.0.zip

Let me know if you can get my test project to build. Supermodel will load crom.bin directly. Keep in mind that I did not get as far as testing 3D graphics on the actual system. The real hardware is very finicky! I'm not sure if the CPU has access to the Real3D address space or whether the DMA devices must be used (as the games all do). You also have to make sure that the MMU is set up correctly (the BAT address registers, which are printed by my test program). We are not sure how to correctly trigger and then detect completion of a Real3D frame but there is some speculation about this in Supermodel's RunMainboardFrame() function (Model3.cpp) and in Real3D.cpp. Lastly, EPROM itself is quite limited in space.

Still, this should be enough for you to begin working with. If you write your code such that the hardware details are well encapsulated, it should be possible to get it running on the real thing later on. You'll have to write your own SCSI or Step 2.0 DMA code (depending on which board you are targeting). If targeting Step 1.0 (which is all I have access to), be mindful that the actual amount of RAM available is only 2MB, not 8MB. The scene graph nodes are also only 8 words rather than 10, as Step 1.5+. All of this is documented in Supermodel's source code, of course.

Polygon set up is not too difficult. If you have any questions, just ask here. I'd be happy to tell you what we've observed the games do (i.e., where they upload textures and polygon RAM to). The biggest difference between the Real3D and consumer-grade 3D chipsets is that the latter can be sent transformed triangles and draw commands whereas Real3D operates on a high-level scene graph consisting of a chain of viewports each pointing to a tree of nodes. These nodes apply matrix transformations and their leaf nodes point to lists of polygons in polygon RAM or VROM. You could get some pretty sophisticated demos up and running with relatively little effort if you take the time to understand and take advantage of this built-in high-level representation. Don't even think about trying to write an OpenGL-like API You'll be swimming upstream the whole time.

[krom]

Hi Bart,

Thanks so much for uploading that mingw64-ppc-gcc, I'll give it a go with your source example, & try todo some stuff =D
I might make CPU tests like I did for the N64, to pass with known results using Supermodel emu, then when you get the chance, you can see if all these tests pass on HW, if not might help fix any PPC cpu bugs.

I have a bit of experience doing bare-metal GPU triange setup on the N64 RDP & the R-Pi GPU, so I'd love to try out some stuff on Real3D, thanks for the info about that it looks very interesting!!
Are there any docs or detailed info you can give me (other than the emu code) with regards to Real3D? That would really help me out with getting a triangle on screen.
I'd love to make tests that can help get the Supermodel Real3D emulation more accurate too =D

[Bart]

Hi Bart,

Thanks so much for uploading that mingw64-ppc-gcc, I'll give it a go with your source example, & try todo some stuff =D
I might make CPU tests like I did for the N64, to pass with known results using Supermodel emu, then when you get the chance, you can see if all these tests pass on HW, if not might help fix any PPC cpu bugs.

Not a bad idea but it would be easier to do this on a PPC eval board or even an old Mac. Also, the tests would have to be carefully designed. There is a PowerPC stress test out there somewhere that was used once to test our PPC emulation (at least for arithmetic flags).

I have a bit of experience doing bare-metal GPU triange setup on the N64 RDP & the R-Pi GPU, so I'd love to try out some stuff on Real3D, thanks for the info about that it looks very interesting!!

I didn't know that the Raspberry Pi GPU was documented. I thought a driver was needed to access it.

Are there any docs or detailed info you can give me (other than the emu code) with regards to Real3D? That would really help me out with getting a triangle on screen.
I'd love to make tests that can help get the Supermodel Real3D emulation more accurate too =D

No real docs but I could send you the SDK and API manual. It won't be all that helpful in actually writing code, though. The best place to look is really Supermodel's code. It's not as daunting as it seems. I would look at Ian's engine. He has the polygon header wrapped up in a class with friendly accessors for each field. Polygons are basically just 7 header words plus the vertices. Each vertex is 4 words: x, y, z, uv. Vertex normals are in the lower 8 bits of the coordinate words, except in fixed shading mode, where only the x normal component is reinterpreted as a shading intensity.

I think the function both of our engines use to start rendering is called DrawViewport() and you can follow it from there. Basically, there is a linked list of viewports (you would need to just set up a single one initially), and each viewport has a pointer to a culling node. There is also a table of matrices and each node can apply a matrix. They are processed as a matrix stack, just like OpenGL.

Of course, any questions you have, I can answer them here or via email.