The Emulation64 Network reports that beta 4 of 64th Note v1.1 is now available. 64th Note is a USF (Nintendo64 music file format) plug-in for Winamp. Below are the changes in this version.

 

In a lot of situations the Fade Type dropdown list didn't appear, this has been fixed. Also, "no fade" has been added as an option, for those who would like an abrupt ending (or want to let their output plugin handle it).

You can learn more about the USF format and obtain 64th Note here, at the official homepage.

PDRoms reports that the Japanese Sony Playstation Portable browser: 2ch Browser, has been updated. This update is the fifth test version of version 0.30. You can find out more information here, at the official homepage (Japanese).

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