Archive for July, 2012

UME (Universal Machine Emulator) combines the features of MAME and MESS into a single multi-purpose emulator. The project represents a natural course of development for the emulators which already share large amounts of code and is part of an ongoing effort to unify development efforts and provide a single emulation platform for users and developers alike.

This is based on MESS SVN revision 15706 (GIT Mirror)

I’ve decided to stick with doing a single package containing source + both 32-bit and 64-bit binaries now, it’s a larger download but less confusing than requiring users to download separate resource packages etc.

The 0.146u4 release can be downloaded here.

The changes from MAME 0.146u4 can be read about here
The changes from MESS 0.146u4 can be read about here

General Release Commentary

The various fruit machine additions should not be listed in the ‘new working’ section of the whatsnew, this was a mistake when the whatsnew was compiled.

The 0.146u4 release brings the Poke Champ and Cyber Tank progress shown in my updates below to an official public release. The final Sky Destroyer progress missed the final cut by a few hours, so that’s missing. Cyber Tank, while still marked as not working is a lot more playable now than in any previous release, so if that interests you and you can look beyond the current glitches you might want to give it another spin.

A lot of the activity in recent weeks has come from Ville Linde, who finally got around to submitting his work on Taito Type Zero, and continued to make progress on said system, as well as Konami’s ‘Cobra’ system. Both are mid-generation 3D systems, and as of yet neither is really working, so don’t expect anything phenomenal in terms of functionality or performance out of them just yet but again it’s good to see progress being made on such systems where developer interest is generally rather low.

A significant amount of the MESS work has been on the VK100 ‘GIGI’ terminal emulation, which looks rather obscure, but interesting from a hardware point of view. For more game focused systems the Super Cassette Vision got a couple more fixes, as did the PC emulation for a couple of specific cases with CGA modes and sound in games like Arkanoid.

One thing I didn’t do an update here about is Wardner, which for quite a long time now has suffered from horrific slowdowns on later levels of the game for no obvious reason from an end users point of view. The MAME Memory system is flexible, but recent(ish) changes saw cases where memory handlers were being dynamically installed at runtime slowdown considerably, to the point where installing handlers anywhere outside of the initial system setup really isn’t recommended at all. Wardner has a fairly irreglar ROM banking scheme whereby when the first bank (0) is selected (which would otherwise act as a mirror of the lower part of ROM) you get the various sprite RAM and palette RAM mapped there instead. Due to this setup the MAME driver had been coded to install handlers for RAM when the RAM bank was switched in and install handlers for ROM when the ROM banks were switched in. Unfortunately because the game switches between the two with regular frequency (especially on the later levels where it needs data from the higher banks) the MAME core install handlers were being called far too often, resulting in 80-90% of CPU time on a 3Ghz system being spent just remapping memory! I’d been told by the most recent developers active on the memory system that it wasn’t going to get any faster, so to avoid this crippling slowdown I just reimplemented it using manual read/write handlers to do the mapping rather than going through the (slow) core functions. Probably not the greatest recommendation for MAME when what would seem to be such basic functionality is so slow, but I’m assured there is an awful lot of complex code under the hood to handle all sorts of edge cases.

I also worked with Kale a bit on the TC00091LVC emulation which is an all in one z80 + graphics chip which was used on the Fruit Dream and Last Bank video gamblers which have been promoted to working in the u4 release. The emulation was done as a modern device, and eventually the Taito L board games (Puzznic etc.) will be moved over to use it as well because they’re all based around the same chip; some driver modernization was done in preparation for that merge.

The other big thing in this release comes from Couriersud. Following on from the previous release we can see further work on Pong. The parent set of Pong now parses it’s list of components from an external file, allowing the machine definitions for these discrete games to be stored as roms would be. While for now this is a quite a bit slower than the hardcoded internal approach it’s also more flexible, and will hopefully evolve to a point where the files can also act as full schematics for the games, which is absolutely essential for such titles where everything about the games depends on the exact configuration of all the components.

Otherwise, lots of shuffling around of things, lots of cleanups, with some hints at what might be next in line to get a 2nd look or polish if you look over the SVN logs.

A bit of teamwork with Kale has seen some good progress made on Taito’s Sky Destroyer.

The Famicom version of the game is at least these days a fairly well known title as it’s featured on a good number of the NES pirate multi-carts, and TV game systems. The arcade version is a more obscure title, luckily a PCB showed up recently.

Like many Taito games of the era it’s protected, in this case by an 8741 MCU, much like “Cycle Mahbou” to which the hardware has several similarities. Taito’s Gladiator also uses similar protection, although in that case actually has 4 of the MCUs (the ROMs for those are dumped, but not hooked up because in that case I believe the chips didn’t have their security bits set, but the Sky Destroyer one is secured)

Anyway, the good news is that Taito typically used the 8741 MCUs as I/O devices to communicate between CPUs and with some of the other devices on the PCB. This type of MCU is easier to simulate with a reasonable degree of confidence, and that’s exactly what Kale has been doing for Sky Destroyer after he initially hooked up the basic sprite support etc. for it.

Now, so far, all Kale, which might lead you to wonder why I’m posting about this at all, but let’s start by looking at an original video of the game.

Smitdogg posted a video of the game running on original hardware, the observant of you will immediately notice the ‘gimmick’ of this game is the funky tilting background, which in 1985 was an unusual effect and the main difference between the arcade version and the Famicom one.

Now, clearly the effect isn’t a full ROZ (Rotate and Zoom) style thing like Data East attempted to pull off in Zero Target, but it is still an attractive looking effect. In the end emulation was actually relatively simple, the first two byte of each row definition in the tilemap RAM region store the vertical scroll values for 2 columns. Additionally there were values for the horizontal scroll, and a single register to control colour cycling stored nearby (keeping the CPU cost of producing the fancy background as low as possible on original hardware)

Anyway, while Kale took care of the system emulation, including simulation of the MCU I looked at the graphic side of things and hooked up the various bits described above as well as fixing a few minor issues with the sprite emulation. It’s worth noting that there is a bit of background / sprite desync in the emulation, but if you study the original hardware it happens there too, it’s especially noticeable when the island is coming up from the horizon as the game attempts to fake the background effect using sprites to give the impression of the island rising up by masking out the bottom part, and you can see where things aren’t quite perfectly synced.

Anyway, some screenshots

Currently the game lacks sound, this is because communication with the Sound CPU is also done through the MCU device, however because the device appears to be a ‘functional’ MCU acting as glue logic rather than providing game specific data I imagine Kale will be able to get the sound working in short order (actually he tells me it’s trickier than it looks) The game otherwise seems to be fully playable.

Current emulation video as of the time of writing

(the final improvements to this, namely the color cycling and sprite fixes didn’t make 0.146u4, so don’t be alarmed if you don’t get the same results as the video)

Cybertank is one of those big, and rather ugly games which failed it’s location test.

It’s a large two screen cabinet running a traditional sprite scaler game where one player drives (and shoots with automatically targeted cannons) while a second player can control an aimed machine gun. In that sense it’s a bit like Namco’s classic ‘Lucky and Wild’

Unless it’s an emulation issue, it seems to have an awful framerate (the game internally appears to update sprites at around 15fps) and it apparently failed location test for being ‘too hard’ and therefore not much fun. I have a feeling the framerate is largely responsible for that, it’s very hard to play a fast paced action game updating at even 30fps, 15fps is far too low.

The emulation is no easier either, it’s been sat in MAME as non-working for ages, references are few and far between (only really a blurry review photo) and the board, like many of these sprite scaler hardwares has heaps of proms & roms containing tables for unknown purposes and bits and pieces like that.

Anyway, Kale recently fixed the controls (turned out to be a very silly bug) which has elevated the priority of me looking into this. A quick pass last night has helped clear some things up.

I’ve found the correct palette bases for the road layer, identified a palette select bit in the road line table, together these allow for ‘bands’ to be drawn in the road, giving the impression of movement rather than just a static gradient. It also allows for colour variations, as used on the title screen.

In addition I’ve moved the tilemaps over to the tilemap system (it appears to use 3 layers using identical hardware for each layer) and added scrolling to those, so the background now scrolls left and right, as well as up and down on hills.

That also meant I had to add priority to the road, so I made a guess that some of the other bits in the road line table were priority, allowing the horizon to slide behind the road on hills etc. Anyway, that leaves us here:

Now, it’s definitely an improvement, but there’s still much to do.

Currently I don’t think the palette select bits are hooked up correctly on the tilemaps, this is kinda obvious from the backgrounds. Each tilemap seems to have a region of 0x40 possible palettes, but we only have enough bits to select 0x8 of those at the moment. The way certain palettes are doubled up makes me wonder if some of the tile number bits also end up acting as palette select, but so far I’ve had no luck on that.

*edit* As of this afternoon I think I’ve fixed the palette selection, it was pretty much as expected, tile number bits being doubled up as palette select. Below you can see screenshots with better colours, of note the HUD elements and backgrounds.*edit*

The second major issue is the sprites. Right now their placement is quite badly off (I suspect they can have an origin / zoom point specified) the end of list handling is wrong (hence trails on the cannons etc.) as well as various other issues. This is probably where a lot of the unknown ROMs come into play too, many of them look like tables, so I’m guessing they’re used for zooming (to specify which pixels get drawn, skipped etc.) That would account for at least 4 of the unknown roms IMHO. There are another two which are the same as each other, I’ve even less idea what to make of those, or any of the PROMs.

Either way, I’m going to look at this a bit more, and hopefully some more progress can be made.

A video of the current state can be seen below.

One thing which has always been of interest to me during my time working on MAME is how games often ended up being unofficially hacked apart and re-released as brand new games from completely different manufacturers. I’ve done articles on this before, showing how a large portion of Korean (and a fair number of European) titles aren’t using original code at all so to anybody who has been paying attention for the last couple of years this statement won’t be seen as any kind of revelation.

One game which falls into this category is ‘Poke Champ’ which is actually a hack of Data East’s Pocket Gal (a pool game, not a poker game as you might have guessed)

The nature of the game already fits well to the type of material the Korean arcade industry liked to produce, it was already a strip-pool game of sorts, and a popular one at that, so it’s hardly surprising it fell victim to a bit of hacking.

Poke Champ has been in MAME for a while, but not really worked properly, there were numerous issues with the graphics and sound due to the significant level of hardware changes made from the original game. Poke Champ has more background tiles, more sprites tiles, more colours (it uses palette ram instead of a PROM and the background tiles can use 256 colours, sprites 16) and like most Korean games utilizes looped samples instead of properly sequenced music.

The game code has changed quite a lot too to accommodate this, with extra (larger) graphics inserted when taking shots etc. Still, none of this makes it a better game, it plays just the same, and looks very rough around the edges.

One of the most annoying problems in the driver was the correct plane order for the 8bpp backgrounds. Usually graphics are easy to decode because they’re in logical orders and don’t take much effort, however when that isn’t the case you’re left with 40320 possible permutations of the 8 values, and need a more sensible way of figuring things out than just trying to brute force your way through all of them and this can take more time.

I’ve had fixing this on my ToDo list for years now, but never really got around to it until now, with previous attempts frustrating me. In the end I managed to pick some good reference points with which to study the data (the Korean flag, which required very obvious palette entries) and worked from there.

After fixing that I noticed there were also some issues with the sprites (unsurprising, the code hadn’t been adapted to handle the greater number of tiles) and of course the sound banking, both of which were fixed relatively quickly.

So, for the curious, here are some side-by-side shots of the Poke Champ hack, and the original Pocket Gal (which has been working in MAME for a long time) I’ve left the adult cutscenes out for obvious reasons ;-)

I know this isn’t going to be thrilling for everybody (nor is anything else I’ve been working on lately) but if you ask me, sometimes the most interesting thing about MAME is discovering how everything links together in terms of both history and code even if the games involved are unremarkable.

UME (Universal Machine Emulator) combines the features of MAME and MESS into a single multi-purpose emulator. The project represents a natural course of development for the emulators which already share large amounts of code and is part of an ongoing effort to unify development efforts and provide a single emulation platform for users and developers alike.

This is based on MESS SVN revision 15604 (GIT Mirror)

I’ve decided to stick with doing a single package containing source + both 32-bit and 64-bit binaries now, it’s a larger download but less confusing than requiring users to download separate resource packages etc.

The 0.146u3 release can be downloaded here.

As always QMC2 is the recommended front-end.

The changes from MAME 0.146u3 can be read about here
The changes from MESS 0.146u3 can be read about here

General Release Commentary

There is a validty check fail in the compis.xml software list, this is inherited from MESS 0.146u3

The u3 releases in general aren’t very exciting, although do contain some progress which may appeal to those with a curiosity for the technical ‘how things work’ side of things rather than playability.

There is however one absolutely critical fix I must mention which has been made to the PCE CD driver. The Mametesters entry for this bug is fairly easy to understand, games which attempted to play samples ended up with massive slowdowns (while still running at 100% speed) due to a regression in the code. This is important because the last version where it worked properly was a much older version before v5 CHD support, so if you converted your PCE CDs to V5 then you REALLY want to be running 0.146u3 or above now that the bug has been fixed. Having PCE-CDs as V5 makes sense because they have a large amount of audio and benefit greatly from the improved audio compression offered in V5. I plan on doing a discussion of CHDMAN again soon.

Briefly still on the CHDMAN topic, the code hasn’t changed since u2, and is considered safe to use for most cases, although the hanging issue when converting HDD images still exists, and definitely seems to be related to drives which have large amounts of blank data, there is a specific codepath to handle this in CHDMAN, so I’m guessing that’s still faulty. Having converted in excess of 1Tb of CDs without a single hang I can firmly conclude it only happens with HDDs and with 99% probability, only when there is blank data.

For the most part tho the u3 MAME release just contains a whole bunch of non-working skeletons for PC based games added; keep in mind that MESS is struggles to emulate a 25Mhz 486 based PC at full speed right now, and that these arcade games are often based on 1-2Ghz PCs with Geforce cards and you can imagine the likelihood of any of these working in MAME anytime soon. That’s not to say it’s not worthwhile documenting them, but don’t expect them to spring to life in MAME!

On a similar topic, one of the highlights of u3 which falls into the ‘for the technically curious’ bracket is that the Chihiro driver is starting to show something. Chihiro is an arcade platform based off the original X-Box (but with beefed up RAM, a GD-ROM drive etc.) While again this is effectively another x86 PC-like platform (733Mhz Pentium 3 era chip, Geforce 3 era graphics) it is interesting because MAME is (to my knowledge) the first emulator to show any boot screens from it, and the X-Box as a platform isn’t really well emulated. I can’t see MAME running them at any worthwhile speed (especially for development where it literally crawls) but having the basics needed to get things showing could potentially be a big boost for anybody else wanting to emulate the platform outside of MAME.

Drifting off-topic a bit now I’d also like to use this opportunity to highlight a fairly urgent appeal to help buy an incredibly rare Sega title from the 80s**. Usually with donation appeals money gets recycled, unfortunately this time anybody who helps would just be helping a MAME-friendly collector buy the board, but knowing the title of the game involved* I assure anybody reading that it is a worthwhile cause. As you may or may not know many Sega games from this period are protected by suicide batteries, whereby vital encryption keys as stored in a RAM module backed up by a battery. These batteries have limited life, and we’re talking about games which are coming up to 25 years old; the batteries simply were not designed for that length of time. The game in question is incredibly rare, has one of these suicide modules and this is likely the last chance to get it properly dumped. It is unknown if there are any other working copies of the game still in existence (it’s the first time it has shown up ever and is expected to sell for in excess of 1500$) While I don’t often post things like this I think getting such a rare piece of history into friendly hands is absolutely vital.

** The board was won, although I’m sure if you want to make a contribution to say thank you it would still be welcome

* the title simply isn’t being announced as we’d rather not end up with unwanted competition to buy it, but it is a proper game, not some dodgy mahjong garbage or anything like that ;-)

Other than that, yes, this is 2nd UME release post in a row, and no, I don’t really have any other progress to write about at the moment, I simply haven’t been doing a great deal of MAME / MESS related work but instead have been playing through a bunch of games, testing out some of the emulation, seeing how solid it is, and where it can be improved etc. This has to be done from time to time, especially with some of the MESS stuff where there is a large amount of software and it can be important to get a good view of the overall compatibility of some drivers etc.

UME (Universal Machine Emulator) combines the features of MAME and MESS into a single multi-purpose emulator. The project represents a natural course of development for the emulators which already share large amounts of code and is part of an ongoing effort to unify development efforts and provide a single emulation platform for users and developers alike.

This is based on MESS SVN revision 15525 (GIT Mirror)

JackC has refined the logo a bit based on the original idea, several alternatives were provided, see forums.

I’ve decided to stick with doing a single package containing source + both 32-bit and 64-bit binaries now, it’s a larger download but less confusing than requiring users to download separate resource packages etc.

The 0.146u2 release can be downloaded here.

As always QMC2 is the recommended front-end.

The changes from MAME 0.146u2 can be read about here
The changes from MESS 0.146u2 can be read about here

General Release Commentary

On the MESS front the last 3 weeks have been fairly quiet, low level rumblings, some important progress, but nothing major to write home about. I’m currently trying to rebuild my collection of Saturn images to match the software lists in order to look at fixing up some issues there if possible (I’ve asked a few people for help in finding a couple) Doing this will allow me to start refining the lists and replacing images with better quality ones, although for now etabeta has been doing some general cleanups of Developer / Publisher / Release Year information in said Saturn lists already (as well as many others)

There have been a couple of fixes made to the Super Cassette Vision (svc) emulation by Wilbert Pol which are of note, including a CPU core fix which corrects the timer in Boulderdash (you can observe the bug in this YouTube video) Rather topical, and as it happens, a version of Boulderdash I haven’t actually played.

The PCI slot code has seen some work from Micko, which should eventually help with the emulation of various PCs (and of course eventually be of use in MAME for emulating more PC based platforms) I imagine one of the early goals will be to allow the user to easily add a VooDoo card when running the MESS PC driver, using the VooDoo emulation from MAME although I do fear for performance, the only similar configuration in MAME (Pentium level x86 + Voodoo) is Funky Ball and that runs at a far less then desirable framerate. There is plenty of room for performance however, an x86 recompiler could work wonders.

A fair amount of the remaining progress in MESS is on systems I’ve never heard of, although be sure to check out the changelist and SVN logs because something might catch your eye.

MAME this time round has been more interesting, Angler Dangler has been on of the few remaining games in the bracket of ‘shown on Starcade, but not emulated in MAME’ but with the u2 release that situation has finally changed, although for now only the Japanese version with the highly imaginative title of ‘Fishing’ has been located and emulated. We’re seeing a steady flow of Data East Cassettes being dumped now, with the original Hamburger (from which the long emulated Cook Time bootleg was made!) appearing in the previous update.

u2 also sees a first pass at Q1000 sound emulation from Phil Bennett, this gives preliminary sound in a number of Eolith and Limenko games as well as Semicom’s Wyvern Wings, which is rather famous for using ripped Metallica midi tracks for music, and while the emulation still has some fairly serious issues with volume balance, and missing envelopes you can just about make out some bits and pieces. There was a last minute fix from me to improve the sound sync in some Eolith games as well, so if you’ve already tried an SVN build from when it was first added you might want to give it another look, Candy Puzzle actually sounds rather good. One word of caution, Phil hasn’t hooked the new code up to the See See Find Out or Eolith Ghost (Balloon & Balloon) drivers yet, so don’t expect sound in those just yet (Pang Pang Car might also be using the internal ROM, which isn’t dumped)

The System 16 version of Fantasy Zone 2 is also supported officially now, in an unmodified form, unlike the FZ-2006 multi-game hack/bootleg which had been supported for a while. The ROMs used are those which have been used on various bootleg conversions, but are almost certainly the same as used on the official boards. I posted the code needed to get this running with the PS2 data file a while back. The FZ-2006 bootleg is still kinda interesting tho it allows you to run the Time Attack mode for the original Fantasy Zone.

More regressions have been fixed from the previous code overhaul too, and we’re starting to look in pretty good shape again now, Cubo32 stuff works again for example, INP playback is fixed in a couple of drives where it broke etc. My only real remaining niggles are the crippling banking performance which has a severely negative effect on The New Zealand Story during transitions, and the likes of Wardner on random levels.

Amongst the various regression fixes was a fix I put in to allow the mahjong titles in the Pinkiri 8 driver to boot again, this is a driver I’d really like to get working, but the hardware appears to have been severely under utilized making some of the registers unclear. Sprite heights of all things are still proving to be very illusive, I suspect they’re grouped like the widths seem to be, but I can’t find an appropriate table! I could hardcode the heights and the games would work fine but I’m hoping Charles MacDonald can run some hardware tests at some point, he’s worked with the boards in the past to extract the internal roms.

The u2 CHD code should also be better, producing the same results across platforms now; previously there was an issue whereby the Huffman algorithm used ‘qsort’ which produced different results almost everywhere, luckily that only affected Laserdisc and HDD CHDs, CDs don’t use it by default.

Offroad Challenge works in u2 too, thanks to some TMS32031 CPU bugfixes from Daniel Filner. It’s a typical Midway racing game, same basic hardware as Crusin’ USA.

A couple of the hardware upgrade kits for various boards are now supported too, things like the Space Invaders Multigame and Super ABC Pacman kits were sold commercially, and it has been decided that they’re eligible for support in MAME.

Luca also figured out what was needed to make a couple more Mahjong games work, the original version of classic racer TX-1 is now functional, and a bunch more Midway hard disks revisions are now recognized for games such as War Gods.

So all in all the u2 release has been a productive one and unusually MAME has seen the greater amount of activity, be sure to check out some of the improvements for yourself, either in these UME builds, or the individual projects.