I did want this next update to be about the rare Sega game Charles is current dumping the FD1094 key for, to complete a trilogy of ‘3D’ sprite based games, but as it turns out the ROMs aren’t fully dumped yet (although the key has been, fingers crossed it’s still good!)

Anyway, while the rest of that gets done I’ll spend a bit of time talking about something else, it’s a gambling game, so might not be of interest to everybody, but from a hardware perspective it’s quite interesting.

The game in question is Seta’s Jockey Club II. Jockey Club II seems to have been one of the more popular Seta titles, to the point where it came out on several different hardware revisions (we’ve got dumps from 2, but there is apparently at least a 3rd) It also ended up being bootlegged rather heavily.

Currently the only version of the game that works in the ‘Dark Horse’ bootleg (although the actual driver in MAME has been broken for a while now, but doing a quick fix on it was what got me to take another peek at this)

Now, the bootleg is quite crazy, as Luca observed when emulating it they’re parsing all the video ram and converting data from the format expected by Seta customs into plain tilemaps + basic sprites for use with their cheaper hardware. It’s a novel approach, and can only really work if you have CPU power to spare, and the game doesn’t make extensive use of the more advanced features of the chip, but in this case Seta were pretty much just using it for some basic virtual tilemaps and sprites anyway.

Seta had a lot of custom chips, especially video ones, the hallmark features were usually floating sprite ’tilemaps’ plus many levels of hierarchy, indirection, inherited attributed etc. The later ones also integrated sound hardware, and a tile/data blitter + RLE decoder. I’m pretty sure the CPS3 video chips are an evolution of the Seta chips because they share a lot in common with the later ones such as the SSV sprites and the ST-0026 (NiLe) used on Super Real Mahjong 6.

Now, for whatever reason Seta seemed to put some of their more interesting chips to the most mundane of uses, as already mentioned, the ST-0026, which features full RLE decoder and alpha blended sprites was only used on a single Mahjong game!

The Jockey Club II hardware revisions we know about are no exception to this, I guess they could afford to be lavish knowing that casinos and the like would pay good money for these things, but considering the hardware use it seems a bit of a waste.

So the two hardware revisions and their Seta Customs

‘PCB E79-001 rev 01a’ (newer hardware)
SETA ST-0032, SETA ST-0013, SETA ST-0017

‘E06-00409 + E06-00407’ (older hardware)
SETA ST-0020, SETA ST-0016, SETA ST-0013, SETA ST-0017

both revisions are driven by a 68020, and use the same basic code, so let’s discuss the customs.
SETA ST-0013, SETA ST-0017 are also common to both, the 0013 features on Super Real Mahjong 6, I’d guess it’s some kind of input multiplexer, the ST-0017 is unique to this PCB and I have no idea of it’s function, but it’s probably another support chip of some sort.

The real beef of the hardware is in the ST-0032 (newer) or ST-0020 and ST-0016 combo (older) with the ST-0032 and ST-0020 both being large heatsinked chips.

Starting with the older hardware, because we recognize both the chips. The ST-0020 is a sprite chip, it does large zooming sprites, works with 512kb of RAM for the sprite lists, 4MB of RAM for the actual graphics, has a blitter to copy data from ROM to the video RAM and is all driven by a ~100mhz crystal. We know it because it was found on the Gundam Final Shooting SSV board, to boost the capabilities of the basic SSV board (zooming support etc.) Luca had emulated it there previously, or at least emulated it to the degree the limited use of gdfs allows for, it’s possible it can do more.

ST-0016 we also know, it’s an all in 1 Z80 + video + sound chip used for some complete games (Neratte Chu being a personal favourite) as well as a support chip on other games to do basic text layers and such (Super Eagle Shot) We’ve also seen it employed simply to provide audio, ignoring the video capabilities completely (Super Real Mahjong 5) which seems like a waste, but also appears to be what it’s used for here because the ROM for it contains no graphics.

The newer hardware uses the ST-0032, which is an unknown quantity, but after some basic studying it seems to operate in a very similar way to the ST-0020, at least in terms of the video support, some data structures are in a different order, and there are no doubt some other differences. Given the lack of an ST-0016 on these boards, and dedicated sample ROM I’d hazard a guess it also has integrated sound support.

There are a couple of other differences with the bootleg too, the bootleg has dedicated sprite ROMs, the originals seem to contain the sprite data compressed in the program ROMs somehow, it seems the 68k is responsible for decompressing it rather than any of the blitter functions of the ST-0020 / ST-0032 because the board doesn’t actually appear to have any dedicated graphic roms (or at least nothing we can identify as such) so unless the blitter can be tied to program space or do ram->ram operations it doesn’t actually have anything to work with.

Anyway, that’s a lot of text, and to be honest, I don’t have much progress to show for it. What I’ve done is separate the ST-0020 emulation code from ssv.c, and converted it to be a nice modern C++ device in MAME, this allows for easier code reuse. The natural progression was to then hook it up into the Jockey Club II driver, and figure out how to get Jockey Club II (older hardware, with ST-0020) to display something, after that, and seeing how close the RAM content was I wanted to make the ST-0032 version show something too. What we have in the end are a bunch of error messages.

Jockey Club II (ST-0020 / ST-0016 hardware)

Jockey Club II (ST-0032 hardware)

Not thrilling, but better than the black screen the games have been showing for several years now, and it shows that the bits of the chip are hooked up in the right place, it’s good grounds for further progress. Interestingly, the games *require* a valid Eeprom (which may have to be faked in the case of the two original sets) because it contains the machine ID, which appears to be a serial number of sorts, which I don’t think the games can reprogram on their own (Naomi has similar) If you look at how the Dark Horse bootleg has been broken in MAME for a while now you’ll see the same message as the newer hardware set above.

Dark Horse (bootleg hardware) (with broken eeprom handling, MT report)

That message is simply complaining about the eeprom hookup / default eeprom, which is what had broken in the bootleg driver. It’s fixed now, but at least knowing that points us in the right direction as far as what at least one of the original sets is currently complaining about.

As you can see, all 3 screens are slightly different, which might indicate the bootleg is based off a copy running on different hardware revision to the originals we have, although like most gambling games it seems to have a large number of revisions anyway, the board even has a socket which appears to be for upgrading the program rom without having to replace the entire larger rom but instead just patching over the code section.

So overall not much progress, but some, and maybe enough to get the driver looked at a bit more :-)

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.