October 8, 2014
Currently rewriting the Sega Model 3 video code. Here's Magical Truck Adventure.
August 14, 2013
July 1, 2013
December 22, 2012
December 14, 2012
November 26, 2012
September 15, 2012
I got the analog controls working in Hang Pilot.
September 8, 2012
As suspected, the speed issue in Thrill Drive was caused by the network board emulation. A simple one-line fix and the game seems to be fully playable :)
September 2, 2012
I went ahead and emulated the NWK-TR LAN controller well enough that Thrill Drive no longer dies when you try to
start the game.
For some reason the game is running on hyperspeed though.
September 1, 2012
I've been working on several things lately.
First of all, I've been trying to figure out what is causing Racing Jam to crash.
Turns out a display list function on the SHARC ends up overwriting the display list and wreaking havoc.
I'm still not quite sure why this happens, as the Racing Jam DSP microcode is very similar to Gradius 4, which works just fine.
I managed to hack things a little bit to get past those problems, and the game eventually boots up, but quickly dies to a network error.
Pretty much as expected.
I also managed to figure out the "-11N" error in Racing Jam 2, which turned out to be a LAN board EEPROM (or serial number chip) test.
RJ2 has identical SHARC problems as RJ.
I've also been poking around with Cobra's sound capabilities. The RF5C400 sample data is still nowhere to be found,
but I noticed that the music in Fighting Bujutsu is actually streamed from the hard disk to a DAC with PowerPC DMA.
The streaming code used the DMA chaining feature of PPC403, which was not implemented yet. It turned out to be
a bit tricky to implement, but eventually I got it right and the music plays just fine.
Here's a sample from Fighting Bujutsu attract mode.
August 26, 2012
Fighting Bujutsu is starting to look quite good. Now to figure out why it hangs during the attract mode...
UPDATE: The attract mode is now glitch-free. Apparently I was using a too small vertex buffer. D'oh.
UPDATE 2: The US-version title screen.
August 25, 2012
August 24, 2012
August 23, 2012
I have finally joined the 21st century and opened my own YouTube channel :)
Here's a video of severely broken attract mode from Fighting Bujutsu.
August 13, 2012
Bujutsu is now sending the first game textures.
August 07, 2012
Konami Cobra has a GFX selftest that calculates the CRC of the framebuffers to verify the rendering results. Oh joy.
March 10, 2012
pwrshovl0000.png
pwrshovl0001.png
pwrshovl0002.png
pwrshovl0004.png
March 05, 2012
I found the 3D display list from the main RAM, even though the game doesn't attempt to parse it at the moment. I quickly deciphered the basics of the data layout and the result is quite close to actual footage. Geometry and textures seem correct at least. I've included a vidcap from the actual game for reference.
Hopefully I'll have some 3D displaying soon in MAME too :)
UPDATE: Found vertex normals.
March 03, 2012
Research on Type Zero 3D hardware has been going forward steadily. I've now managed to decode the textures, and that has revealed some more insights on the inner workings of the hardware. All textures are stored as pairs of 64x64 ARGB1555. One of the textures is the "traditional" color texture and the other is either a alpha mask, environment, or what looks to be a normal map. Normal maps are quite exotic for a hardware this old, so I'm guessing they're actually UVL textures for EMBM-style bump-mapping.
I also found some interesting patterns in the RAM marked as "screen RAM". I then fed this data into my little DirectX-powered 3D visualization program (coincidentally the same I used during Supermodel development :P) Not really surprisingly the data turned out to be polygons. Pictured below is the body of a Toyota Celica from Battle Gear. The textures used are the "alternate" set that is the environment map for the body and normal maps for some details.
Next step is to get the games to send over the display list data, matrices, etc. to actually render this data in MAME.
EDIT: On second thought, I think the normal maps are just used for DOT3 bump-mapping and Taito were a bit ahead of their time (GeForce 256 had the feature by October 1999.)
February 22, 2012
Battle Gear flat out refused run with the v1.52 BIOS. I managed to swap in v1.11a from the game disk and now it runs happily.
February 19, 2012
UPDATE 2: Battle Gear 2 also started running. Graphics emulation really needs some work now.
batlgr2_1.png
batlgr2_2.png
batlgr2_3.png
batlgr2_4.png
UPDATE: Attract mode
landhigh3.png
landhigh4.png
landhigh5.png
Landing High Japan boots from hard disk.
landhigh0001.png
landhigh0002.png
February 17, 2012
February 11, 2012
I did a major rewrite on the video/gticlub.c 3D renderer. This fixes pretty much all the remaining missing polygons and texture errors. I also identified and implemented many of the missing features, such as gouraud shading, lighting and fog.
Solar Assault looks pretty sweet now (even more so in motion) :)
slrasslt_before.png
slrasslt_after.png
June 04, 2011
I have been implementing a lot more features of the Viper hardware. More specifically;
the I2C interface and global timers on the MPC8240 and the DS2430 EEPROM.
Surprisingly enough, Tsurugi starts
to show its attract mode, although eventually crashing after the scroll screen.
EDIT: More pretty pics from Boxing Mania.
tsurugi1.png
tsurugi2.png
tsurugi3.png
tsurugi4.png
boxingm2.png
boxingm3.png
May 29, 2011
Last time I looked at the Konami Viper driver, it was stuck on unemulated Voodoo 3 functionality (User Interrupt Command). Now that I have implemented that and hacked in some additional Voodoo 3 support (mainly 2D host-to-screen blitting), we get some pretty POST screens from Police 911, Boxing Mania and Mocap Boxing :P
p911.png
boxingm.png
mocapb.png
March 12, 2011
Some Taito Type-Zero games were dumped last year, and MAME already has a skeleton driver for it. Out of curiosity, I decided to have a look at the system. I spent a couple of hours trying to figure out the format for character tile data, only to realize that it's simply stored as a 512-pixel wide two-dimensional array (duh).
MAME already has a TLCS900-core for emulating the IO-processor, but I don't know if it's sufficiently
emulated for use in this system. I guess we'll find out soon enough.
Ultimately I would like to see this game running in MAME :)
March 06, 2011
Daytona USA 2
The 64MBit roms of this game were finally dumped a couple months ago. I hooked it up in Supermodel, and yes, it does work :P
It does some interesting things, like feeding texture DMA from specially mapped CROMs (0xc3000000).
February 27, 2011
Magical Truck Adventure
This was one of the Model 3 games that I really wanted to see running in Supermodel or MAME. Seeing that it was dumped a while ago, I decided to have a look. While it does rely on some tilemap interrupts and stuff that isn't properly emulated yet, I managed to get it to run the attract mode.
There are also major issues with the 3D graphics, and I had to disable lighting to get even parts of the background objects visible. Also, as further bad news, the game seems to employ the tilemap encryption/compression used in Virtual-On 2 and Dirt Devils.
P.S. Looks like they loaned T-Rex from The Lost World... :D
March 12, 2010
- drivers/viper.c is back to working order.
- Some changes to idectrl.c broke CF card soft reset -> made sure the sector and cylinder regs are set to expected values on soft reset.
- Fleshed out MPC8240 emulation.
- MPC8240 EPIC now successfully processes IRQ0 requests.
- viper.c doesn't like the auto-endian-conversion of the device system...
- Viper wants Voodoo3 to have 16Mbit SGRAMs... Changed dramInit0 to comply.
- Voodoo3 hits an unemulated function, User Interrupt Command. IRQ4 handler seems to expect this.
July 31, 2008
Unfinished business
One of the things I worked on about half a year ago, was a driver for Konami Cobra system.
Cobra is a very complex system, comprising of 3 boards with a PowerPC CPU on each one. The first board with PPC603, can be considered as the "main" board as it runs the main game program. The second board has a PPC403, and does all the I/O handling, hard disk access and sound. The last board is a graphics board, with a PPC604 running a series of custom graphics chips (possibly designed by IBM...)
Cobra doesn't seem to have 2D graphics capabilities at all, so getting something on screen wasn't exactly easy ;-) The screenshot below shows some hex numbers that are a debugging feature built in to Cobra software. Each number represents the "debug state" of the software running on each of the three boards. The numbers themselves are rendered as textured quads, and the whole process is done entirely on the graphics board. This of course required the emulation of the graphics board FIFOs, command buffers and texture uploading... ;-)
