David Haywood's Homepage
MAME work and other stuff

Cops & Monsters

October 1, 2012 Haze Categories: General News. 43 Comments on Cops & Monsters

I haven’t got much to report here, post 147 continued the massive ‘change all files again’ refactoring efforts in MAME which kinda derailed progress for a few days, although things appear to have settled down again now. I don’t think I would have made much progress anyway, I haven’t really been in a MAME mood, so in reality the timing of the changes probably wasn’t that bad, even if the first part of them (which crept into 147) are largely responsible for the ‘Mortal Kombat is broken!! bug which I must have seen posted on at least 30 forums (surprising really because regressions in other drivers can go unreported for the best part of a year but I guess the MK games are unfathomably popular) Breakage aside, I still need to write about some of the other cool bits in 147 however, again the lack of a MAME mood hasn’t really helped there.

Probably the most interesting piece of progress lately is Kale’s work on the Seibu COP protection. It’s no secret that a fair number of the remaining unemulated 90s games are serious tough cookies when it comes to figure them out, for many systems it’s like the final boss run with every battle suffering from SNK Boss Syndrome.

I’ve mentioned the COP here before, it handles all sorts of game operations, movement, collisions, DMA, BCD maths, indirect ways to access memory and is even semi-programmable through a series of short ‘Macro’ commands which get uploaded to a table on startup etc. It also manages to blur the lines well between what are operations actually performed by the COP and what are external operations. The programmable Macros also only seem to be half the story for some of the functions they provide, the collision ones for example appear to be incredibly simple, too simple, with barely enough operations to grab the values from the doubly indirected table they use and perform calculations on them, so it’s likely the actual macros only perform half the work for several operations allowing for game specific customization of how more complex commands hardcoded in the silicon are fed their data etc.

Kale has been doing most of the work on this, as mentioned, I’ve been trying to understand bits of it, the collisions, hitbox checking etc. which is less straightforward than it should be for the more complex cases of Legionnaire and Zero Team. I think I’ve figured out how it determines the basic size of the hitboxes, we have X co-ordinates, Y co-ordinates, origin and size, which works much better than what we have now in the “SD Gundam Sangokushi Rainbow Tairiku Senki” case (you no longer fall through the elevators etc.) but actually ends up worse for Legionnaire, which has 2 extra 8-bit parameters and additional flags checked based on those. Logically you’d expect them to be Z, but you have no pointer to any RAM containing a base virtual ‘Z’ co-ordinate (assuming it isn’t just after the X or Y one, I should check) Also in terms of the resulting flags, for X and Y you get the distance between the parts returned in registers, you get no such thing for a possible Z value which would make Z checks meaningless because you’d only have the hardcoded ‘Z’ values from the doubly indirected ROM table.

Further confusing things is that Legionnaire, with the ‘correct’ basic hitbox sizes only checks collisions to your right, if you’re facing left, it sends the same hitbox as if you were attacking right, and there doesn’t seem to be a parameter to flip it, so you still end up attacking enemies to your right instead of left. This makes me think the extra parameters might just exist to extend the hitbox, or another command is failing and the software is requesting the wrong hitbox from ROM because some of the game code still thinks you’re facing right (there is other odd logic like having to double the X speed value another command returns if you’re moving left which might suggest the same, the half speed might be a backwards walk speed for enemies)

To make things even more annoying the ROM tables are inconsistent. Every game calls the same set of commands, which fill in the same values. Legionnaire’s second table is 4 words (xxxx yyyy ???? 0000) with the first table containing pointers to every 4 words. Zero Team has data in the format (xxxx yyyy ???? 0000 0000 0000) and pointers in the first table to every 3 words, meaning every 2nd pointer is basically useless because it points to blank data. Then you have the games which don’t have any ‘depth / z / ????’ value which just have the tables in (xxxx yyyy xxxx yyyy xxxx yyyy etc.) formats and point to every 2 words. I assume this means that the calculations are independent of each others because if the commands get processed the same then they’re going to end up with invalid ‘x’ data from the next entry for the ‘depth / z / ????’ parameter in the cases which pack the table without the ???? values. Kale’s testing would appear to back this up because he was getting an unpredictable value he couldn’t understand at all in one of the result registers.

So you can see the challenge, and that’s only dealing with a tiny, tiny piece of the puzzle. For these games to work perfectly every single piece needs to be understood properly, implemented properly, and full verified / tested against real hardware results. It’s possible the chip has alternate ways of doing things too, if for example the ‘Macros’ executed for the collision simple substitute some kind of regular memory access it’s entirely possible there are manual ways of doing the same thing (and I actually wonder if this isn’t what Raiden 2 does, it accesses registers nothing else does for some bullet / sprite processing, although they could be specific to the sprite chip on that game because it uploads the encryption params to the same area, which is what I mean about the lines between COP functionality and other hardware being blurred)

I could speculate endlessly on this because right now there are so many unknowns, so many little surprises, odd choices etc. that you’re left wondering what’s around the next corner and really questioning how everything fits into place.

What Kale is doing is cool, but I think everybody needs to keep their expectations realistic, there is simply so much game logic tied to the device in all these games that getting to a point where it can be considered trusted is going to be a long slog and between now and then I fully expect things to both improve and regress multiple times as new findings are made and previous ones invalidated.

In some sense we’re lucky, we’ve got a large number of games making different use of the protection device, but it means coming up with a generic implementation to keep everything happy is important, as opposed to coming up with per game hacks just to provide the logic the game wants, which is what the Seibu Cup Soccer bootleg appears to do, albeit still mostly in hardware with additional hardcoded tables, making it no easier to emulate than the original! The good thing about having a large number of games is it gives us a variety of test cases, and a good slap if we’re doing things wrong, or not fully implementing something, as the collision stuff proves.

As stated before, to the best of our knowledge the COP protection isn’t provided by an MCU, but fixed function logic programmed inside one of the customs, ie it’s not something you could decap with really meaningful “well let’s just emulate the CPU then” results, so an accurate simulation is essential.

If none of this makes any sense to you, that’s fine, an awful lot of it still doesn’t make sense to anybody else who has looked at this thing either, unlike a number of other systems which are relatively simply and just suffer from a lack of interest this one has slain every other developer who dared come close.

Go to article.. »

UME 0.147

September 17, 2012 Haze Categories: General News. 42 Comments on UME 0.147

UME (logo by JackC)

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 the official MAME 0.147 source release found on mamedev.org with no modifications. The binaries on offer here were compiled with ‘make all TARGET=ume’

The package contains both the 32-bit and 64-bit binaries, I’ve not included the source because it’s identical to the mamedev.org distribution.

The 0.147 release can be downloaded here.

Note: as of 0.147 the sysinfo.dat is no longer distributed with MESS, it can be found in the ‘Extra Files’ section at ProjectMESS
furthermore the external artwork files, needed by some chess computers are also not included by default. They can be found at AntoPisa’s site.

Changes from MAME 0.147 can be read about here
Changes from MESS 0.147 can be read about here

General Release Commentary

First a word of warning, there is a core issue with redefining controls for some MESS systems, including the Genesis and AES. It seems that to redefine the directions you must either redefine the inputs globally, or make sure you redefine inputs to be the same on all the selectable controller types. I’m not sure when this crept in (quite possibly a while back) but you should be aware of it. The MAME/MESS 0.147 release has the same issue, it is not UME specific.

Moving swiftly onto the release, it’s been a long time coming, u5 was released on the 20th August, almost a full month ago, so as you’d expect there’s a substantial amount in here. The ‘new working’ section is the first one most people look at and there are some notable titles in there. Ville’s continued work on Konami 3D systems means GTI Club, Solar Assault and Thrill Drive now run to a level which can be considered playable (as long as you have a beefy recent system) Hang Pilot too, although with it’s dual voodoos etc. the emulation performance isn’t great, and I can’t imagine even a top end system running it especially well. There are a number of more conventional 2D titles now ‘working’ as well. Little Robin, Magicball Fighting, and F1 Super Lap all of which have featured in updates here are promoted to playable, as is Brick Zone, an Arkanoid clone which like most SunA games is actually surprisingly good for a Korean arcade game fusing an awful lot of ideas into one little game, think Block Block or Riddle of Pythagoras if you’ve played either of those. The lesser known title on the ‘new working’ list is Ganbare Jajamaru Hop Step & Jump, although the reality of it is that it’s just some very basic and not especially interesting rock paper scissors type game from Jaleco.

The MESS ‘new supported’ section looks rather anemic by comparison, but don’t be fooled, improvements to systems like the Virtual Boy bring them much closer to playable even if they haven’t been tagged as such yet, that’s one of the things with MESS, drivers can see huge improvements but often not be tagged as working due to erring on the side of caution due either a large number of known non-working cases, or a significant and mostly untested software library. PC emulation has also seen some incremental changes, improvements to the SoundBlaster emulation, but be warned other aspects of the PC emulation are broken as various bits of code (such as the floppy support) undergo significant (currently unfinished) reworking.

Another interesting new addition is the Ghosts and Goblins prototype. While unfortunately one ROM wasn’t dumped from the PCB (and I believe it was then sold!) likely causing the incorrect colours on the text layer, it remains an interesting snapshot of the in-development game, complete with early development glitches, enemy placement, overall balance and many other things (I didn’t notice any weapon drops for example)

Go to article.. »

Magic 8-Ball Says….

September 16, 2012 Haze Categories: General News. 14 Comments on Magic 8-Ball Says….

With 0.147 due out tomorrow* it should just about be possible to squeeze the progress shown here in before the cut-off

What is the progress? Semicom’s Magicball Fighting, the first in the series of 4 Korean arcade baseball games and the only one which hadn’t been dumped and emulated up until this point (Wonder League Star, Wonder League ’96 and MuHanSeungBu are all already supported)

As with the other games in the series this was really only intended for Korean markets and thus makes use of Korean text for most of the game displays.

The protection was the usual Semicom type, a bunch of code put in RAM by the MCU and used for the interrupt routine

You can read more about Semicom over at Hardcore Gaming 101

Here is a quick video in which I manage to rack up a magnificent total of 0 runs, proving I’m just as bad at baseball as I am at F1 ;-)


Content not available.
Please allow cookies by clicking Accept on the banner

* yes, 0.147 should be out tomorrow, even if all the sweeping core changes going in at the last minute are against conventional wisdom and there hasn’t been any real public testing period for them. Fingers crossed we’re still as stable as the previous u release which was probably one of the most stable points we’ve had for a while.

Some screenshots if you don’t want to / can’t watch the video


Magicball Fighting Magicball Fighting

Magicball Fighting Magicball Fighting

Magicball Fighting Magicball Fighting

Go to article.. »

A Super Lap of Dishonour (or why I don’t play racing games…)

September 3, 2012 Haze Categories: General News. 42 Comments on A Super Lap of Dishonour (or why I don’t play racing games…)

F1 Super Lap, the sequel to Sega’s F1 Exhaust Note was sat in the ‘Not Playable’ pile for a long time. Modeler didn’t emulate it, and when the rest of the System 32 games in MAME received protection bypasses it was overlooked too, with the assumption that it needed 2 linked boards to function at all. It came to light 9 months ago when this original hardware YouTube video was posted that the came could actually function with just a single board, either expecting some kind of status from the network hardware to indicate there was no linked board, or possibly putting the blame on the protection (F1 Exhaust Note was instead unprotected)

Sega used a variety of protection chips on the System 32 boards, with several using evil looking battery-backed FD1149 MCUs, F1 Super Lap was one of these. What Sega didn’t do was protect any of the games especially well, and despite having these MCUs it looks like in most cases they’re used for very simple memory copy / clear operations, which would be a good protection if used effectively but it doesn’t appear they ever were.

It’s hard to say exactly what the protection is on F1 Super Lap, there is a byte in RAM which locks you in service mode, maybe it’s that? There’s also a value which gets placed in RAM for what looks like a network wait but seems to lack any mechanism to clear it, so it could likewise be that. The game also makes some odd reads during the attract demo, causing the V60 to attempt to set a bad addressing mode which I’m guessing would crash the real CPU. To be honest, I’m not sure which of these things are protection related, and which are related to improper simulation of the network board. The game also has some priority glitches during the attract demo, but those could easily be general problems with the System 32 video implementation, it isn’t perfect as several other games demonstrate.

Anyway, as you can probably guess I’ve got things going a bit further, actually quite a lot further. In current versions of MAME the game is simply stuck in service mode, I’ve fixed this problem, and even found a way to allow the game to be started and played, you might even consider it working although my driving is far too bad to do any extensive testing of it.


F1 Super Lap F1 Super Lap

F1 Super Lap F1 Super Lap

F1 Super Lap F1 Super Lap

F1 Super Lap F1 Super Lap

F1 Super Lap F1 Super Lap

F1 Super Lap F1 Super Lap

F1 Super Lap F1 Super Lap

F1 Super Lap F1 Super Lap

.. and just to back up my claims of being the worst player of racing games you’ve ever seen here’s a little video of it running in MAME


Content not available.
Please allow cookies by clicking Accept on the banner

*edit* Uncle Tom dumped his World region set from which the original YouTube video was made, so the new parent set in the next release will have English text / speech


F1 Super Lap F1 Super Lap

Go to article.. »

Little Robbin’ Hoodies, now with Happy Pills

September 2, 2012 Haze Categories: General News. 3 Comments on Little Robbin’ Hoodies, now with Happy Pills

This is the 3rd part in the Little Robin progress ‘video diary’

I’ve improved the layer selection logic a bit which means that the letters you collect to spell the word ‘ROBIN’ are now correctly displayed at the top of the screen. One of these letters will drop down in a bubble each time you kill one or more enemies as part of a chain, collecting them all will give you a bonus stage after the current level.

I’ve also added the clipping logic, this is used between stages to clip out the sprites, and also fixes how items are displayed as they drop into the playfield from above.

I haven’t worked out how the scrolling / smiley faces which should be drawn between scenes work yet, so those are missing, but overall this progress gives another nice improvement to the graphics and I can confirm that the game is fully playable from start to end.

There is something of a glitch on the 2nd form of the final boss, which I’m assuming is an emulation bug. When you defeat the first form of the boss it ends up being made into part of the background graphic so the game can display the 2nd form, but instead of just the dead boss becoming part of the background your old sprite, and any mini enemies the boss created also end up being stuck to the background. This can be seen on one of the screenshots below, these are all taken from later levels to add a bit of variety.


Little Robin Little Robin

Little Robin Little Robin

Little Robin Little Robin

Little Robin Little Robin

Little Robin Little Robin

As this is a ‘video diary’ here is a video of the first 30 or so levels of the game with the current emulation code, lots of credit-feeding tho!


Content not available.
Please allow cookies by clicking Accept on the banner

There’s still room for a lot of improvement in the code (a fair number of the current guesses are questionable) and of course the missing video features, refer to the previous update to see dox’s original hardware video.

Go to article.. »

I have a bag full of arrows, why am I throwing goo and shurikens?

August 31, 2012 Haze Categories: General News. 7 Comments on I have a bag full of arrows, why am I throwing goo and shurikens?

I’ve continued to work on Little Robin and started making some more sense of the displaylist structure, as well as fixing the screen resolution to 336×288. Layer clearing / scrolling is still incomplete / wrong but the HUD graphics now appear, as does the title screen, a mini-map when starting the game, the boss death animation, and the high score table.


Little Robin Little Robin

Little Robin Little Robin

Here is an updated video (in which I’m not trying to play the game properly) to show the new progress.


Content not available.
Please allow cookies by clicking Accept on the banner

Also, there is an old video Dox put on YouTube recorded from his original board, the lack of solid colour in the background is an artifact of it not really agreeing with his monitor tho. As you can see the smiley faces that come down between levels are missing in the emulation, as is the background to the mini-map. Fixing those is my next target.


Content not available.
Please allow cookies by clicking Accept on the banner

Also if you need a reminder of how things looked before the progress over the last 24 hours, you can check the old video here

I don’t usually do multiple video updates, but I figure people might like to see the various steps involved in making progress from time to time.

Go to article.. »

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close