Catalogue of Arcade Emulation Software - the Absolute Reference

Valid XHTML 1.0! Valid CSS!



Large CAESAR Logo


0.77 [Aaron Giles]


- Carnevil: Lets you set the flash brightness; need to emulate that


- 0.113u2: Zsolt Vasvari updated Voodoo-based games to use the new video timing code and newer MAME timers.

- 0.102u3: Changed visible area to 640x480 and fixed dipswitches.

- 0.101u2: Aaron Giles added MMU support to the non-drc MIPS3 emulator. Converted the Killer Instinct, Seattle, Vegas, and Hyper Neo-Geo 64 drivers to a proper physical memory layout. Disabled the drc MIPS3 core until MMU support is added there as well.

- 0.91u1: Aaron Giles fixed bug in memory system introduced in 0.91, this was breaking at least Killer Instinct, the Seattle driver and Where's Wally.

- 7th January 2005: Aaron Giles - I've quoted 10GHz as what you would need to run the Seattle games full speed, and that may be a little on the low side. People have asked for multiprocessor support in MAME, but the way MAME is architected, there isn't too much that can realistically be offloaded to a second processor. For most games that are currently slow in MAME, there is one big bottleneck that can't really be split. For Seattle, it's the R5000 emulation, which even by itself won't run full speed on less than 5GHz. Now, with some work, the Voodoo emulation could be made to run on a second processor, which would get you closer to full speed on a dual core machine, but it's still not going to get you all the way there. In MAME's general architecture, there's not much room for splitting things up. The only obvious place is on the video side. The code that renders tilemaps, sprites, and polygons into the frame buffer could potentially be made to run on a second processor; however, that code by necessity accesses buffers which would need to be copied so that they aren't modified while the first processor continues the CPU emulation during the rendering phase. If these buffers are large, then you're not buying yourself time because the copying eats the cache and slows down first processor. Once the data is in the frame buffer, the code which draws it to the screen could be made to run on a second processor without much ado; however, apart from demanding artwork compositing, that's not going to save you a whole lot of time in the grand scheme of things. Sound emulation these days isn't a large percentage of games' time. Even the discrete sound system, which is demanding, isn't too bad because the games which use it tend to run on fairly ancient hardware. Finally, everyone likes to think that multi-CPU games could obviously make use of multiple processors, but this isn't the case. In theory you could run each CPU on a separate processor, but then you have thrown all synchronization between the processors to hell. It's rather difficult to explain why unless you have actually written multithreaded code and understand how timing and interrupts work in MAME, but it's definitely not possible in a completely generalized system. You might be able to make it work for certain games with a lot of synchronization, but you're really asking for trouble. And then, because every OS schedules threads and processors differently, you will have a host of bugs which only happen on certain systems or under certain conditions which are not globally reproducible. It's just not worth it. So, in short, I expect there will eventually be an interest in adding some multiprocessor support to MAME, but it will not be the pill to end all your performance woes.

- 0.84: Aaron Giles added some newly discovered PIC IDs to the Seattle driver.

- 0.82u2: Aaron Giles added more extensive documentation on the various boardsets, constants for the GT64010 and all interrupts and ethernet device interrupt support. Made the IDE controller visible on the PCI bus, formalized support for the "widget" board used in vaportrx & calspeed, hooked up CMOS protection bit, corrected sfrushrk audio CRCs and hooked up hard disk and marked sfrush and vaportrx as working.

- 0.81u6: Aaron Giles added a diagram of interrupt sourcing, fixed incorrect checksums on SF Rush: The Rock audio ROMs, added support for DCS HLE downloading via FIFO (used by Vegas games) and fixed incorrect sound pitch in Blitz 99/2k.

- 0.81u5: Aaron Giles improved VBLANK interrupt handling, cleaned up handling of DMA operations, DMA operations now properly pause if they can't write to the voodoo, now returning proper PCI IDs for the bridge device, mapped more inputs and dipswitches for Biofreaks, fixed clock speed for Wayne Gretzky's 3D Hockey, cleaned up memory maps, added Vapor TRX to the supported games and added entries for Hyperdrive and SF Rush: The Rock (no hard disks ATM).

- 10th April 2004: Aaron Giles added some HLE to the sample upload commands in the DCS2 system, speeding up the Seattle games somewhat.

- 9th April 2004: Aaron Giles fixed the slow booting in the Seattle driver by recent IDE change.

- 0.79u2: Changed Custom sound to DMA-driven_DAC.

- 0.78: Aaron Giles added support for Biofreaks, fixed remaining issues in California Speed, verified California Speed HDD dump (works in self test, not in boot ROM test), fixed timer change that broke Blitz 2000 and added proper PIC IDs for Wayne Gretzky and Mace. Midway IC: Added sound auto acknowledgement option, added new PIC mapping for Gauntlet: Dark Legacy and fixed initial sound IRQ state. DCS: Fixed reporting of input full/output empty states.

- 0.77u3: Changed visible area to 512x400 in all games. Aaron Giles included several dipswitch fixes from Brian Troha and made sure the IDE controller waits a minimum amount of time before generating an interrupt. The IDE controller features buffer is now filled in completely. Also fixed code that reads the bus master status register from a word offset.

- 7th December 2003: Aaron Giles added the ADSP2104 variant to the ADSP2100 CPU core, fixed several minor bugs in the Seattle driver that affected Biofreaks and California Speed (but they're still not fully working), added speedups to NFL Blitz and NFL Blitz 2000 and did various other bug fixes and cleanups in the Seattle driver.

- 0.77u1: Roman Scherzer updated a couple of drivers with new Hard Drive SHA1s (cojag.c, djmain.c and seattle.c).

- 5th November 2003: Aaron Giles finally submitted the Seattle driver last night. Not everything's 100%, but 4 games are playable. Well, playable being a relative term for how much you can stand playing games at 20-30% of full speed on a 3GHz machine. Also, I did manage to improve Offroad Challenge... the terrain is correct, but there is still a bug that clips out the cars. CAGE is coming along, but sounds horrible at the moment. But at least San Francisco Rush has some music, if you define music as a random sequence of notes coming out of your speaker at various times.

- 2nd November 2003: Aaron Giles turns out that San Francisco Rush uses the CAGE audio system (shared by Primal Rage and T-Mek), guess he will try to get that working again as well. He's thinking there is a bug in the TMS32C031 core, and he's hoping he can find it so that Offroad Challenge might fall into the playable category as a side-effect. He also continue working on the 3dfx emulation.

- 31st October 2003: Aaron Giles submitted several of the Seattle games. He managed to play all the way through CarnEvil (~50-60% full speed on my 3GHz machine and that's the fastest Seattle game I have). Also got another Seattle game just up and running.