PDRoms reports that the first version of Magic Maze has been released. This game is a conversation of a "Ravensburger" board game called "Labyrinth". This is the programmer's first game, so it's rather sketchy. As of now, you must play with 4 human players and the game has no end. You can find out more here.

December 04, 2005

DMA Woes

So I thought I had everything figured out. I found a nice depth buffer bug that fixes numerous problems in the Voodoo games (and which happened to be there in the old implementation as well). I figured out the weird alpha blending problem. And the only thing that was left was understanding why Carnevil was no longer rendering its polygons correctly relative to the background movie. I looked everywhere for the problem, and it turned out to be much more subtle than I realized.

 

It turns out that a number of the games use the DMA functionality of the Galileo GT64010A chipset to send data to the Voodoo. This actually makes a lot of sense. The Voodoo has a limited size FIFO where the data goes in, and when that is full, whoever is sending the data has to stall until the Voodoo has had a chance to finish whatever it was backed up doing. Far better to let the DMA system stall than letting the main CPU stall when it could be doing real work.

 

In the old implementation, I made all commands to the Vooodoo complete instantly. This meant that any DMA transfer, no matter how long, finished instantaneously, even if it was rendering tons and tons of polygons or clearing the screen. In the new implementation, I changed the code to actually approximate the amount of time each polygon and screen clear takes. The problem with this is that DMAs no longer complete instantly, and this has revealed a subtle problem.

 

Many of the games kick off a nice long DMA to the Voodoo and let it complete asynchronously while the main CPU is off busy doing other things. The problem is, there is code in most of the games that also directly accesses the Voodoo without checking to see if there is still a DMA in progress. When this happens, new commands were being inserted into the rendering queue at the wrong spot. The most obvious side effect was in Carnevil, where they would write a command in the middle of a DMA that turns off depth buffering, meaning that all subsequent triangles were rendered without doing any depth comparisons.

 

The trick is figuring out what the behavior should be. I've tried hacking it so that if the CPU writes to the Voodoo while the DMA is in progress, then the CPU stalls until the DMA completes, and only then does the write go through. This works but introduces other glitches in the system. So now I have to come up with another theory.

 

On the plus side, I finally found a nice PDF of the GT64010A datasheet over at http://www.datasheetarchive.com. I'd been working off of a Google HTML document that was auto-converted from a PDF, and it just never came out quite right!

 

Posted by Aaron

>> Information courtesy of Aaron Giles

AdvanceMAME Version 0.102.0 2005/12

* Fixed some bugs for the 64 bits platforms. It works now.

* Fixed a problem mapping the video memory in the Linux FrameBuffer driver.

* Fixed the conditional compilation of the advv and advcfg utilities.

* Updated zlib to version 1.2.3.

* Fixed some keyboard input issues with the text mode utilities in Windows.

* Added leds support at the `raw' and `event' keyboard linux drivers.

* Fixed the `uninstall' make target.

* Increased the max number of joystick buttons to 64.

>> Get them HERE

PDRoms reports that efegea has released his port of SMS Plus SDL to the GP2x. There is no ROM selector for this yet, so you have to name the ROM you'd like to play: rom.sms. The source code for SMS Plus 2X is also available. Click here for more information.