CAESAR Logo

Catalogue of Arcade Emulation Software - the Absolute Reference

Valid XHTML 1.0! Valid CSS!

X-Arcade

X-Arcade

Large CAESAR Logo

gaelco3d.c

0.79u2 [Aaron Giles]


TODO:

- EEPROM interface not right


WIP:

- 0.113u3: Couriersud added save state support to the gaelco3d driver.

- 0.113u2: Aaron Giles changed Gaelco 3D driver to use osd_work_items for rendering, allowing multi-CPU systems to shift most of the rendering burden to a second CPU.

- 0.86u1: Aaron Giles added sound to the Gaelco 3d driver. Added 4th DMA-driven_DAC.

- 2nd March 2004: Aaron Giles fixed a bug in the TMS32031 CPU core which caused bad geometry in Surf Planet, and he fixed other rendering bugs in the Gaelco 3D driver so that it works better.

- 2nd March 2004: Aaron Giles - After getting Radikal Bikers working well, I decided to figure out what was up with Surf Planet. Turns out they were relying on unspecified behavior of the TMS32031 by placing a CALL statement at the end of a repeat block. They tell you several times in the docs for the CPU never to do this, but hey, I guess if it works more power to them. With that fixed and some rendering tweaks, I'm currently getting about 30-50% of full speed on my 3GHz machine. If I turn off bilinear filtering and run at half resolution, both games are playable near 100%. Of course, I don't have the sound working yet, and that will kill the speed nicely (it's a DCS-like ADSP chip, sorry!).

- 1st March 2004: Aaron Giles turned on bilinear filtering by default in the Gaelco 3D driver.

- 28th February 2004: Aaron Giles - Z buffering and perspective correction are fixed (see http://www.flipcode.com/documents/texmap.txt).

- 24th February 2004: Aaron Giles - Fixed a subtle bug in the TMS32031 core that was causing problems with Radikal Bikers. Now at least all the geometry shows up okay. I'm still at a loss to explain alpha blending, Z buffering, or perspective correction. The incomplete driver should be in u2, so if you know some 3D math, feel free to have a look and see if you can't help me figure it out!

- 16th February 2004: Aaron Giles sent in a preliminary version of the Gaelco 3D driver (Surf Planet and Radikal Bikers) which works somewhat but graphics rendering is not perfect.

- 14th February 2004: Aaron Giles - Still stumped on the perspective correction, but I managed to figure out how the texture masking works so that text no longer has big blocks on the outside. Turns out some of the ROMs provide a 1bpp mask for certain textures. Also, I managed to get Surf Planet up and running. It's on the same hardware, but with a 68000 instead of a 68EC020. If you know MAME, you'll know that it's kind of a pain to do this because you can't just substitute a 68000 directly for a 68EC020 due to different data bus widths. Now if we can just dig up a Speed Up PCB and send it to Guru, I'll have all of the known Gaelco games on this hardware to play with.

- 13th February 2004: Aaron Giles - Well, as long as everything is drawn straight on, it looks great. Unfortunately, the 3D hardware apparently does support perspective correction, so right now everything kind of looks like this. I've spent several hours trying to wrap my poor brain around the parameters to get at the perspective correction, but I'm pretty close to stumped for the moment.

- 11th February 2004: Aaron Giles - Palettes and controls are hooked up, I can coin up and start a game. I figured out how the texture data is distributed across four ROMs in little 2x2 squares, which is pretty solid evidence that there was bilinear filtering in the original game. There are still some serious issues with understanding the texture coordinates, but I'm at least confident I'm pointing to the correct texture to start with, given that I can read the text in the service mode. I have a feeling progress will slow down now until I can wrap my head around the math.

- 10th February 2004: Aaron Giles - I'm startlingly pleased to see something like this after only a few days work. The 3D chip gets passed 13 values (10 floating point, 3 fixed point), plus 2 additional values per vertex. This is just some connect-the-dots on the vertexes being passed, but it's encouraging to see the pipeline working. I'm still trying to deduce most of the other parameters, which probably have to do with things like texture coordinates, Z buffering, and maybe even lighting (let's hope not!).