Archive for March, 2013

There are two ways you can judge an emulator, either by what it can do, or what it can’t do. Personally I’ve always favored the first option, it’s a more positive outlook, and it’s a good one to take with MAME, and especially MESS, or the combined UME project (and it’s part of the whole philosophy behind it, UME allows you to do more than MAME)

It’s with that introduction I’ll mention some of the progress in 0.148u2 coming from the MESS side of things. It goes without saying that the Jaguar driver is a bit rubbish, in terms of what it *can’t* do you could fill a list covering most of the system library but I’m going to focus on what it can do here, and 0.148u2, thanks to some work from Ville, expands what it can do into the realm of being able to run Tempest 2000, the psychedelic follow-up to Atari’s arcade classic. The game runs and is very playable on my Core2 system with full sound, I don’t think the graphics are perfect but it’s a huge improvement on before where it would simply crash the emulator due to unsafe blitter operations overwriting the game ROM in memory!

(Tempest 2000 benefited from recent improvements to the Jaguar emulation and is now mostly playable with sound)

Purists might say it lacks the crisp vector look of the original, although that’s obvious given that it isn’t running on vector hardware here, but it has a style of it’s own, and I feel could easily have been an arcade release. Jaguar will need a lot more significant work applied (probably a full rewrite) before it’s anywhere near a good driver, but nice to see it getting a bit of attention in the same way that u2 has given some attention to several older MAME drivers. The original Jaguar version of Rayman also benefited from the changes with the collisions now being fixed, although that still lacks sound and the save feature shows ‘ERROR’ in all slots, still it complements the progress made with the Saturn version of the same game in u1 nicely!


(Rayman was also improved, but still lacks sound)

Speaking of Saturn there have been continued improvements to the emulation of it in u2 from Kale, mostly targeting specific issues highlighted by specific games, but many of the improvements likely have a wider impact than the individual test cases observed. A knock on effect of this Saturn work has been improvements to the ST-V emulation in MAME, and as featured on Kale’s Blog, the game ‘Zenkoku Seifuku Bishoujo Grand Prix Find Love’ is now playable in MAME. If it wasn’t clear from the title it’s an adult game where you undress Japanese ‘gals’ by playing various mini-games, including a ‘find the differences’ one, ‘pairs’ and a jigsaw game. Typical 90s garbage really, but at least it works now, interesting only really because of the platform it runs on.

(Kale got Zenkoku Seifuku Bishoujo Grand Prix Find Love working thanks to a better understanding of ST-V / Saturn hardware)

Some observations were also made about the protected ST-V games during this development cycle, and Kale identified that the broken player / ball movements in Tecmo World Cup ’98 were indeed related to a protection check, although even with that fixed the game still hangs if the USA Goalkeeper gets the ball, it isn’t clear if that is further protection on the GKs special move, or just a bug in the Saturn / ST-V emulation. From some brief studying of the protection it looks like Sega actually used a complex encryption / compression system on some of the game data for these ST-V games, similar (possibly the same as) the one used on the Naomi cartridges. Further research suggests it might also be used on Model 3, both for the games with compressed graphics there, and even the ones doing a dumb ‘string check’. That would mean Sega were using an encryption scheme as complex as CPS2 to perform nothing more than a hardcoded check against a string in some cases if true, mind boggling!

(Kale improved Tecmo World Cup ’98, but it still has game breaking bugs and bad performance)

Either way, a lot more work, and possibly extensive data collection + analysis will be needed to either confirm or deny that theory. Decathlete remains an odd-one out and seems to have the compression more for functional purposes than protection, the way it talks to the device is different to the rest, and it explicitly uploads what look like Huffman tables for the compression. I plan on having another look at that one in the future. There were other ST-V fixes as well, the long standing ‘some games give 2 credits on startup’ bug appears to have been fixed as well, and while only a minor irritation it is a sign that the driver, and understanding of the hardware are starting to mature even a huge amount of work remains, especially in terms of performance and video accuracy.

The work on Gunpey is included in 0.148u2, although no progress was made on the compression, which remains problematic. My early optimism that I would have that one sorted in a week definitely didn’t pay off! It’s actually rather playable but still marked as not-working because a couple of the sheer number of broken graphics caused by the missing decompression.

(Gunpey, quite playable but understanding the compression scheme has become a sticking point)

You’re probably sick of seeing Cool Riders by now, but that is included as well, I’d had the driver on freeze for a while as not to break in any way prior to the 0.148u2 release, I might give some of the remaining issues another look now that u2 is out of the way, the main irritation is still the sound. *edit* Cool Riders will have problems with some Mac systems in 0.148u2 due to a compiler bug with the CLang compiler used, a workaround has been submitted by Phil B, thanks for the reports.

(Cool Riders is officially supported in 0.148u2)

On the MESS side etabeta has been giving some attention to expanded cartridges for a number of systems. The Genesis and SNES were beneficiaries of this, and also improved documentation of the cartridge content (rom name, chip locations, extra hardware etc.) thanks to notes / information from ‘ICEknight’, ‘Sunbeam’ on the MESS forums and other contributors from elsewhere. This kind of information is essential to the documentation value of MESS, and of course proper identification and emulation of any important extra chips found in the cartridges.

I mentioned expanded cartridges, and for the Genesis that more often than not means 3rd party ones, usually unlicensed (by Sega) Chinese titles and the like many of which had unusual / custom mapping for things like their battery backed save systems, or custom protections. A number of games previously requiring hacked dumps to run can now be used with the proper ones, including things like ‘Tiny Toon Adventures 3’ I am however still noticing some stability issues with the driver randomly crashing, especially on startup with certain games (Mulan for example) This may or may not be related to some overall stability issues I’ve noticed since the recent HLSL work went in, where games with dynamic resolution changes are bombing out on me at random. The genesis does do dynamic resolution changes…

(A selection of unlicensed Genesis titles where the extra hardware in the cartridges is now emulated)

Other systems saw work on obscure carts / pirate releases too, with the Gameboy not being excluded from that. Work was done on support for the custom hardware used by “Shi Qi Shi Dai – Jing Ling Wang Dan Sheng” a Chinese RPG, it still has issues with drivers other than gbpocket due to unhandled bios interactions (maybe it only works on specific machines anyway?) Improvements were made to the Rockman 8 support too, a pirate sequel to the famous series although I’m not convinced it REALLY works yet, most enemies seem to be missing until you die, and the glitches with the video timing are irritating.

(Some unlicensed Gameboy titles had their emulation improved by emulating cart specific hardware)

Another Gameboy-like handheld, the Megaduck had it’s software list hooked up, although both the Software List and driver have existed in their current form for a long time so I’m guessing the lack of a hookup (a one line addition) was more of an oversight than anything else. The emulation seems to have some minor timing glitches causing the occasional bad line, unsurprisingly similar to those seen with the regular Gameboy. *edit* Apparently this was actually a regression fix, and the Softlist had been hooked up in the past, but the hookup was lost at some point in recent refactoring

(The Megaduck was hooked up to the Software List, although both the driver and list have been there for a while!)

As part of etabeta’s work the SNES saw a large number of cleanups, and refactoring to make things work in a more ‘logical’ way. For cartridges with expanded hardware you no longer need to specify different base machines, instead the software lists specify what hardware was in the cartridge and dynamically add the extra required CPUs to the emulation etc. The downside to this is that the slot system seems to be causing some pretty significant performance issues, with a drop of 20% reported on some of the SNES titles for which performance was already worrying (the DSP based ones). Hopefully this is temporary, and some more intelligent coding somewhere can win it back. The SNES also had a number of pirate titles and the like, including an odd multi-game cart consisting of an original Tetris game alongside many ported NES titles. Not all the games run especially well in MESS, although many are glitch on (at least some models of) original hardware too. Like most multi-game pirates the cartridge contains extra bankswitching logic and etabeta needed to emulate this in order for it to run at all.




(A funky SNES bootleg cart containing NES games required custom bankswitch emulation in order to boot, although still has issues)

While that pirate cart is quite funky, there were also a number of multi-games containing regular SNES games. Unfortunately most dumps of these are bad, containing only the first bank, probably due to being dumped with cart copiers incapable of dealing with the bankswitching. A similar problem exists for many Genesis mulit-game pirate carts.

There were SNES games with additional protection as well, although many of these seem to have been of an even lower quality than the Genesis ones. Tekken 2 is one such example. A cracked version of the pirate game has been supported for a while, but 0.148u2 adds emulation of the original protected pirate cartridge too. The screenshots might look reasonable but the actual gameplay on offer makes Fit of Fighting in MAME look like Marvel vs. Capcom. Imagine if you will controls, animation and scrolling running at something like 5 frames per second, and a game where most of your attacks, if you do manage to pull any off, get blocked. It’s diabolical. As it turns out, emulating the protection on this also allowed for another game to run, the Street Fighter EX plus alpha pirate, that’s marginally better, but we’re talking very, very small margins here.

(Some more terrible SNES pirate games are also now working)

You’ll have noticed something of a recurring theme with the emulation of these pirate carts, and might be wondering why etabeta has spent his time looking at these rather than spending time improving the actual SNES and Genesis emulation. I think a lot of it comes down simply to levels of interest, it’s always enjoyable to be discovering, documenting and understanding something new then recording those findings in MAME / MESS as a record of how they work, and while the games are often terrible that’s not really the point. When I was working on HazeMD it was one of my goals, to understand the things nobody had put much effort into understanding before, so I’m glad to see that continued here, and it looks like people have even started performing hardware tests for some of the protected carts to document how they really work. I’ve always said the value of MAME / MESS is the knowledge contained within it, and obviously understanding these things increases that even when the games are of little worth.

Back to the MAME side, we decided to mark Stadium Hero 96, the game featured in the previous update here, as working. Kale played through the game, completing it, and reported that there only seem to be a few issues with the clipping windows in places, and no game breaking bugs, so the IMPERFECT GRAPHICS flag seems more appropriate than the non-working one at this point.

(The previously shown progress on Data East’s Stadium Hero 96 is included)

I don’t usually cover bootleg clones, but ‘RevisionX’ dumped an unknown board which turned out to be a new bootleg of Moon Cresta called Star Fighter (making it the 3rd game we have supported to carry that name..) It has some redrawn graphics, fast shooting, and more aggressive wave advancement compared to the original at least, I’m not sure how it compares to some of the other bootlegs. The colours might be wrong because no colour PROM was dumped, and we’re using the one from the original.

(Star Fighter is an interesting bootleg of Moon Cresta)

PoPo Bear, another game featured here in a previous update is also officially supported in 0.148u2.

(Snake meets Bomberman in PoPo Bear)

From a more technical side of things one of the most significant updates in 0.148u2 is the complete rewrite of the 6809/6309/KONAMI CPU cores by Nathan Woods. This was done as an attempt to make the cores cycle accurate and should lead to far better raster effects in systems like the CoCo in MESS with some other supporting improvements. This is a very big change, and has the potential to break a lot, in fact when it first went in there was widespread breakage of many drivers in MAME and MESS, but during the course of the u1->u2 cycle the majority of the obvious ones were caught and fixed. Just be warned, some bugs could still be lurking because it’s fresh code replacing tried and tested old code. Naturally if you see any new suspicious behavior introduced for games using a CPU from this family in 0.148u2 it should be reported on Mametesters

Kale also put some work into the Casio Loopy, allowing preliminary screens of that. The system is a difficult target primarily because there is no dump of the BIOS. The system uses an SH1 with internal ROM, and boots the games from that, with some code pointing back to the bios for various interrupts / system calls. The goal of trying to emulate some of the system like this is in part to gain an understanding how how things work, and potentially come up with a way to dump the content of the internal ROM if the hardware allows for reading of it from the game code. The speech bubbles shown in one of the games might actually be an ideal starting place for such work so while most of this looks like meaningless garbage right now it is actually potentially very important progress.

(Preliminary work on Casio Loopy might help find a way to get the BIOS dumped)

Back to the ‘technical’ changes, we’ve seen a LOT of modernizations in MAME and MESS during this update in additional to Firewave going over a lot of drivers and devices adding proper initialization of many member variables in an effort to keep the project both clean, deterministic and stable. Many of these were missed during older initialization passes because the older (non C++) device model would automatically 0 out memory when creating devices, but the new one does not, and was leaving many things in undetermined states, which generally isn’t a good thing because a lot of those are detectable by the emulated system and/or can cause stability issues. I do wonder if the Genesis stability issues I’ve been seeing while writing this article aren’t related to a similar problem if we can rule out the D3D code updates made for HLSL / multithreading by default. Tracking random issues like that can be a nightmare tho, especially when they stop happening altogether in your debug builds, so I’m glad to see preemptive steps being taken to prevent many potential problems from cropping up later, it certainly helps narrow things down when you have to start looking for potential issues manually.

From the oddity department LoganB submitted a software list for the Sega Dreamcast VMU quickload files. While these aren’t technically ‘roms’ as such (but memory dumps) they do provide an accessible way to make use of Sandro Ronco’s driver by validating that you’re using recognized software, software that would definitely work on the original unit. While the approach used is not very ‘pure’ it is convenient, and very useful for regression testing and the like. Here are some screenshots of the Powerstone VMU memory dump running. No new work has been done on the actual driver, but with the software list now being present and hooked up it’s the first time I’ve given it a run through so I thought it warranted putting some shots up, for a reference to how it runs right now (even if it’s still marked as NOT WORKING)

(The Sega VMU got a Software List, this was the controller Memory Card thing used on the Dreamcast)

Not all work involving MAME and MESS involves changing the actual projects directly either. The support network is vital as well, and while I feel we should keep a lot of this tied as close to the actual emulation distributions as possible (rather than relying on miscellaneous forum posts and wiki entries) it is good to see when people make an active effort to teach people how to use MESS, and show what can be done. It’s with that I’d like to mention a thread R.Belmont created on the MESS forums to help people understand MESS to the point of being able to install an actual operating system inside an emulated PC in MESS. While doing this isn’t very practical for performance reasons it is important people realise that both MESS and UME can make use of far more advanced features of the MAME framework than MAME alone, and show how some of them are used. Now none of this would be possible without the underlying improvements to the PC emulation which have been ongoing for some time now, but the two really go hand in hand and one of the motivating factors for the project(s) is curiosity, and that desire to do things just because they can be done. There is another amusing thread of screenshots of the MESS forums taken from within MESS again showing that you can squeeze a lot of entertainment out of the projects beyond the obvious ones.

Let’s look at some more of the clone additions in MESS too. You’ll see that there has been a steady flow of Megatouch clones for the older Megatouch units showing up for a while now (most of the newer ones are PC based I believe, although I don’t know if anybody has looked at them recently after all the work done on the PC drivers)

Pit Boss Megatouch II (9255-10-01 ROG, Standard version) [Brian Troha, The Dumping Union]
Megatouch III (9255-20-01 ROK, Standard version) [Brian Troha, The Dumping Union]
Megatouch III (9255-20-01 ROB, Standard version) [Brian Troha, The Dumping Union]
Megatouch III (9255-20-01 ROA, Standard version) [Brian Troha, The Dumping Union]
Super Megatouch IV (9255-41-01 ROE, Standard version) [Brian Troha, The Dumping Union]
Super Megatouch IV (9255-41-01 ROC, Standard version) [Brian Troha, The Dumping Union]

is the whatsnew listing for Megatouch clones this time around. A question was put forward on the Mameworld board asking what the difference was between the various Megatouch clones, and ‘anoid’ put the following information forward about Megatouch III

9255-20-01 - Standard Version - Includes all options and no restrictions
9255-20-02 - Minnesota Version - Excludes Casino Games
9255-20-03 - Louisiana Version - Excludes All Poker Games
9255-20-04 - Wisconsin Version - Game cannot end if player busts; 1000 points are added to end of each hand
9255-20-06 - California Version - Excludes Poker Double-Up feature and no free game in solitaire
9255-20-07 - New Jersey Version - Excludes sex trivia and includes 2-coin limit with lockout coil
9255-20-50 - Bi-lingual ENG/GER - Same as standard version, without word games
9255-20-54 - Bi-lingual ENG/SPA - Same as standard version, without work games
9255-20-56 - No Free Credits - Same as standard version, without word games and no free credits
9255-20-57 - International - Same as standard version, without word games

Most of that doesn’t really apply here, because all these are ‘Standard versions’ ie the most complete ones so it’s possible (likely?) the ROx codes are just revision numbers, and used to indicate bug fixes etc. The information provided is interesting however because of the restrictions present in some of the other versions. Things like ‘no word games’ are obvious, the word games are going to be heavily Americanized, and unsuitable for regions not using a US-English dictionary. The rest are more complex, clearly indicating that some regions consider the standard version of the games to fall foul of gambling laws, even if the majority of people would not consider these to be gambling games. Rules such as “Game cannot end if player busts; 1000 points are added to end of each hand” would appear to be tailored around very specifically worded legislation!

While on the subject of gambling, the Data East hardware ‘Dream Ball’ (as featured in a previous update) is also included.

(Dream Ball is supported)

A bunch of new clones were added to the Igrosoft Multifish driver by MetalliC too, including the final game released on that platform ‘Crazy Monkey 2’ but the graphic roms and palette have some unhandled address line swapping on that one, so while you can initialize it like any other it currently only plays ‘blind’

The new Head On set is also an interesting clone because it uses a different maze to any of the other sets. ANY dumped this one, and I added support for it, bypassing what seems like it might be a trivial protection check on startup. It’s since been revealed that there was a much older dump of the same set, also from Italy, and that it should run on the Sidam boardset for the game (which lacks a Colour PROM, so chances are it should also be black & white) I guess this must have been a relatively common version of the game in Italy?

(This odd Italian clone of Head On features a different maze to the usual version)

ShouTime also continued the run of tracking down important clones and thus we can say the World version of Starblade is supported now as well. Visually it looks identical to the Japan one, sans the warning at startup, so there isn’t really anything to show or write about for it other than this quick mention, but by having a World version confirmed and supported the documentation value of MAME is enhanced because it confirms the game was released outside of Japan, and that a specific version was made for that.

In MESS, R.Belmont along with some others continued to add support for the various Apple II expansion cards, the Street Electronics Echo Plus, Zip Technologies ZipDrive and Apple II Rev. C SCSI Cards. The first of those is apparently a speech board, with the others being more self-explanatory.

Numerous other fixes were made across both projects, a couple you’re unlikely to really even notice the difference from unless you’re intimately familiar with the games in question, but nevertheless important fixes. An example of this is the fix made to the Deniam Logic Pro 2 sound banking, apparently just one sample differs between the banks and the error / missing banking had gone unnoticed for years.

Wrapping things up, Kale put in an early driver for the Casio FP-200 and you can already enter basic programs (make sure to RESET the memory first tho by typing RESET)

(The Casio FP200 had a small screen built into the keyboard unit)

As you can see, a lot of the progress again comes from the MESS side of things, and that’s even with me having worked flat out on MAME stuff for the past 2 months but there really isn’t much else to write about in terms of visible progress that I haven’t covered. There are definitely a few more interesting bit and pieces in the pipeline from other devs, but quite when they’ll hit nobody knows (Phil’s progress on Turret Tower still hasn’t been submitted for example, and the possibility of being able to submit another driver I worked on jointly with him but we’ve had to keep private for the past 3 years is increasing, so I’m crossing my fingers over that)

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.

As an end user this means that the software provided here is not only capable of emulating arcade machines like the baseline versions of MAME, but in addition can emulate a large number of home computers and consoles from across the world using the very same code, developed by the very same team of developers.

0.148u2 Windows binaries (32-bit and 64-bit) (Self Extracting 7-zip) (all MAME / MESS tools included, both 32-bit and 64-bit versions in tool32/tools64)

The source is identical to that found on mamedev.org (SVN revision SVN 21962 / 0.148u2)

Non-UME binaries

In addition to providing the UME binaries I’ve also included a package with the individual legacy MAME/MESS executables here, personally I prefer the everything under one exe UME solution but I’ve noticed it’s not always easy to find binaries of the regular u builds with them not being offered from the official site so this is my attempt to address that.

Latest U release binaries for UME, as well as MAME & MESS can also always be found on the page linked in the box on the left
These binaries are coming from Mamedev (me) so are as official as you’re going to get for a u update.

What’s New

You can read the various whatsnew files on mamedev.org
From MAME, From MESS

Points of Interest

These will be covered shortly, lots of MAME bits and pieces, but you’ve seen the majority of them here already, some MESS changes worthy of discussion too.

Data East’s short-lived MLC system was probably designed to provide direct competition to the NeoGeo system, but arriving in 1995 after the NeoGeo already had a strong foothold in the market it was never going to do well.

The Flyers are hilariously bad, and highly inaccurate, talking about the competition as a 15-bit 68000 with the rest of the competition specs seemingly for a fictional system and then the actual ones for the MLC not really much more grounded in reality.

Either way, it was a ‘cartridge’ based system, not multi-game like the NeoGeo, but slightly closer to CPS2 in the way it works with a lot of the logic (including the game CPU) in the cartridge along with all the ROMs (in reality the motherboard only provides the sound & video circuits etc.) Interestingly Avengers in the Galactic Storm made use of an SH2 CPU while the others instead used Data East’s encrypted 156 ARM chip, I doubt the reasons for this decision will ever be clear. The encrypted ARM obviously provided extra security, but already existed when AGS shipped so the choice to use a completely different CPU lacking any security whatsoever was an odd one, not that it mattered, I’ve never heard of any of the cartridges being bootlegged at all.

Having previously worked with the NeoGeo for titles like Street Hoop and Karnov’s Revenge the influence on the video system design here is quite obvious. The MLC forgoes the usual Data East tilemaps + basic sprites combination and favors exclusive use of a much higher capacity zooming sprite chip. While the NeoGeo retained a simple tilemap for the text overlays this system lacks that too.

I guess the idea was to keep it simple, you no longer have to worry about multiple layers and priorities and how they’ll interact with each other, you simply have a spritelist drawn in order, one thing to learn, one thing to program.

One problem with an all-sprite system is that you lose the ability to do line effects, which makes the ‘3D capable’ points in the flyer even more laughable. There are ways around this, and Data East were certainly no strange to them. Karnov’s Revenge works around the limitation by using the scanline programmable interrupt timer on the NeoGeo to trigger interrupts on specific scanlines and change the content of spriteram during the active display, picking a moment after the processing for one line is complete, the very moment before the next one gets drawn in order to do the ‘rowscroll’ effects on the floor. It’s a common technique, and Data East had made use of it many times before, even on hardware where it probably wasn’t strictly necessary.

It’s no surprise then that the MLC system is capable of similar, it does however appear that the hardware designers shot themselves in the foot with this. You see the MLC spriteram looks (at least from what we’ve been able to gather) to be buffered. That is, the content of spriteram is copied to a private buffer for use by sprite chip when rendering. With this in mind it becomes impossible to change the positional values of sprites in realtime because the changes you make will only get seen next time the RAM buffer is updated, once per frame.

To compensate for this the hardware employs what seems to be a very kludgy workaround. Next to the scanline IRQ register are a set of 3 other registers with each one having additional x-scroll, y-scroll and x-zoom values, and any sprite can be told to use these ‘global’ values. While the spritelist can’t be updated in realtime these values can be, allowing for a similar effect to be achieved although limiting the possibilities in significant ways.

That’s probably enough background information anyway. You might be wondering how this actually relates to the games running on the system, and why I’m talking about it here? Well as it turns out at least 2 of the games on the platform make use of these features. Avengers in the Galactic Storm uses them to do a similar rowscroll effect on the floors (it’s very noticeably missing on some levels) and unfortunately I haven’t been able to make any progress with that one. The other game using it, extensively, is Stadium Hero ’96, a game that has never worked in MAME.

Implementing this was tricker than it might sound. The MLC renderer in MAME had been written in a way optimized for object rendering, in other words, rendering the entire content of the sprite list once per frame, drawing the full width and height of each object (within screen limits) at that point. That’s fine as long as you’re not trying to do realtime scanline effects. If you want to do realtime scanline effects you need to instead look to see if a sprite covers the current scanline and if it does render only the appropriate span of the sprite for that scanline, a rather different approach.

MAME provides a ‘cliprect’ system, clipping rectangles that you can use to limit the area of the screen that things get drawn to. For basic cases (assuming the rendering code acknowledges the cliprects at all) this can be used for to implement such effects, by simply passing a cliprect covering a more limited area of the screen (the scanlines you want to render) to your rendering code, pixels outside that area get cut off and the desired effect can be achieved. That’s essentially what the ‘partial updates’ you see in MAME sometimes is, it’s telling you that the screen is being rendered in multiple calls (currently MAME can’t go below scanline granularity in this with using core code, so it will never be greater than the number of scanlines)

The problem is once you start to get large sprite-lists and zooming sprites the ‘pass a cliprect’ solution starts to become highly inefficient. Forcing the MLC games to do 240 partial updates caused performance to drop to around 10% speed, from significantly higher. This is essentially because the point at which pixels got clipped out using this technique was the point at which they should have been rendered. Forcing 240 partial updates was actually near enough telling the code to render the entire screen 240 times, but only actually use one scanline of it from each call. As you can imagine, that’s not exactly efficient, it means your entire renderer is 240 times slower.

The key to solving this problem is early rejection. By rejecting sprites at the earliest opportunity, and calculating which line of a sprite correlates to the current scanline then you can save a huge amount of work, you’re no longer looping over every line and every pixel of a sprite only for it to not even show up in the final display because it doesn’t exist on the current scanline, nor are you even looping over extra lines of a visible sprite, you’re jumping straight to drawing the actual visible pixels for only the sprites visible on the current line. It’s obvious, but it needs more intelligent coding than the brute force approach.

Doing this in MAME is nothing new, plenty of systems have their own custom renderers for exactly this reason, the NeoGeo being one of them, but it still requires work, it requires reworking of code designed / optimized for one scenario to be rewritten in a way optimized for another instead. Doing this for MLC had been on my todo list for a long time, knowing there were games in need of it, and so it was good to finally get it done over the last couple of days.

The fun didn’t end there tho, there are a number of other poorly understood things about MLC, first of all there was the whole issue of how the global registers get selected, and also an issue of how they got used. The first couple of attempts at getting Stadium Hero ’96 didn’t really look much better than before, there were line effects going on, but they were completely wrong. A day or two of studying the values allowed that to be fixed however.

Stadium Hero ’96 also threw up another problem. The MLC has it’s own set of clipping windows (not MAME ones!) 8 of them to be precise. These can be used to clip sprites to certain screen areas, a feature used by Skull Fang to show the boss views when the boss if off-screen. Unfortunately the MAME code only had logic to select between 4 of them, and Stadium Hero uses all 8. I found what appears to be the higher select bit, fixing the garbage covering the game screen and allowing for the windows showing your guys on the bases to render correctly most of the time. I say most of the time because there are still problems to track down, the logic used by Skull Fang is contrived, and it’s possible Stadium Hero ’96 isn’t agreeing with it.

Actually all the bits used to enable clipping windows, raster effects and raster selection are slightly odd. I don’t think the current implementation is correct at all, and it’s possible setting one bit changes how other bits behave, but test cases are so limited it’s hard to know. One thing appears to be clear, if raster effects are to ever work in Avengers in Galactic Storm then the ‘enable use’ bit we currently use can’t be right (the sprites that need to be affected don’t have it set) but furthermore there is a problem that AGS isn’t even writing valid per-scanline values from what I can see, it sets a single set of global registers (and not even the ones our current select bits would reference) once per frame. I can only guess there are multiple issues, from it not liking the reads from one of the many unknown ‘vblank??’ handlers in the driver to some further way in which the select bits and enable bits can be changed.

Stadium Hero ’96 also had (has?) a further problem, protection. In addition to the encrypted ARM the game makes use of ‘146’ protection chip, although it only writes to it on startup, and then reads it many times during the actual gameplay / attract sequence. Kale chipped in and did some work here, correcting the return value for one of the protection reads and allowing the Title Screen to show, and gameplay rules / scoring to be fixed. It appears most of the checks are quite dumb, and probably really do return fixed values given the lack of writes after startup.

So anyway, the net result of all of this is that for u2 Stadium Hero ’96 will be massively improved, I’m hesitant to call it working because there could still be lingering protection issues, and there are almost certainly bugs caused by the clipping windows at least but it at least looks a lot better now, and can actually be played.

There are other outstanding bugs with the MLC driver I haven’t managed to fix, the regression with Hoops / Hoops ’96 test mode is a very annoying one, Mametesters shows it broke a long time ago, and it remains ‘broken’ If it wasn’t for us having default eeproms you wouldn’t actually be able to run the games at all at present because it’s still impossible to enter test mode, and without being able to enter test mode you can’t actually initialize the eeprom (or change any game settings) I’d actually be curious to find out the exact change that caused this failure because it’s most likely to point us at a fix. This is definitely a platform where some good hardware tests wouldn’t go amiss tho, even basic things like the zoom precision is questionable right now (and with my new code there is a very visible gap in the Stadium Hero ’96 logo zooming)

After that wall of text, here are some screenshots of Stadium Hero ’96

(Screenshots of the much improved Stadium Hero ’96, the 6th shot shows a likely remaining clip window issue)

Sometimes drivers sit untouched for a while, not because they’re especially difficult to make progress on, but simply because they’ve ended up at the back of the queue while other potentially more interesting targets are looked at. PoPo Bear is one of those drivers.

BMC aren’t known for their regular arcade games, everything else we’ve been with the BMC brand on it has been a poorly disguised gambling / redemption game and the compact PCB design of PoPo Bear along with the 4 banks of dipswitches (above 2 is unusual for anything other than Gambling games) I actually expected it to be another gambling game, and issued a warning that if we were to buy one of two PCBs available at the time it should probably be the other one because it looked more interesting. In the end both were purchased, because even if it had turned out to be a gambling game the current policy means it would end up supported anyway and the prices were reasonable.

The original Dumping Union MAME World post from when it was purchased can be found here and the following PCB picture was supplied as part of that.

(The compact PoPo Bear PCB could easily have been a gambling game like most BMC titles)

Upon initial inspection of the ROMs they did indeed contain strings like ‘Hopper’ and ‘Payout’ which seemed to confirm that it was, like everything else, a gambling game, even if it didn’t look it from the screenshots we’d seen (but screenshots can always be deceptive, see games like Lucky Boom) Kale did some work on the driver back then and got it running the game, but the video implementation was left significantly incomplete (wrong res, bad sprites, bad scroll, bad enables etc.) and the game remained only borderline playable due to the glitches.

The interesting thing at this point was that it actually appeared I was wrong, all the aforementioned strings in the ROM simply appear to be leftovers from the codebase of another game probably developed to run on the same platform, this game was clearly a hybrid of the classic ‘Snake’ game lots of people grew up with on their phones (and we should really get around to emulating!) with elements of Bomberman thrown in for good measure, an actual proper game with no signs of any kind of Payout system or rigged gameplay.

Anyway, I decided to pick the driver up again the other day, clean it up, and fix up as many of the video bugs as I could.

I believe BMC to be either Chinese, or possibly Taiwanese like IGS, and (original) games and hardware from that region tend to lend themselves to some curious hardware designs in terms. This hardware is no exception to that, and while the CPU is a bog standard 68000 the video hardware has some oddities.

First on the list is the tilemap handling. The majority of arcade games have the video hardware access the graphic ROMs directly. On this board they’re memory mapped, don’t decode as tiles and the CPU has to copy them into memory before use. Not too unusual, but then you have a further peculiarity with the system. Despite there being a clear tilemap layout in RAM addressing tiles by number the data doesn’t actually get copied across as tiles, but instead as a linear 512 pixel wide bitmap. The hardware transparently converts the addressing into tiles for drawing, but the CPU can draw directly to the screen directly more easily than if it had to pack everything into tiles. The game doesn’t really take advantage of that, but it’s something you don’t see on every piece of arcade hardware, and is probably used to more of it’s full potential by some other undiscovered game on the platform.

I spent a fair bit of the time cleaning up and understanding this as part of the work I did on the driver, to hopefully make it clearer that the hardware really does use tiles for the tilemaps, even if the way they get stored is odd.

The tilemap chip supports 4 scrolling layers, of 128×64 8×8 tiles, and can turn on row-select and line-scroll effects for at least 2 of them. It uses 8bpp tiles from a single palette of 256 colours outputting a resolution of 480×240, not bad for a generic looking PCB.

The sprites similarly require their data to be copied into RAM first, a different area of RAM to the tile graphics. Otherwise they’re more conventional, not tile based, but must be multiples of 8 in size. The width and height are tied together, so sprites can be 8×8, 16×16, 32×32 or 64×64 pixels in size. They have their own set of 256 colours, although the palette addressing is messy, the sprite pixel data is 8-bit, which would give you access to all the colours anyway, but there seem to be at least another 4 bits to further convolute the addressing. That isn’t fully understood because the game makes minimal use of it. The priority system is a sprite to sprite one, with 16 levels of priority, again unusual, for the majority of systems the sprite to sprite priority is determined by the list order, with only the sprite to tilemap priority being determined by the sprite priority bits. It’s unclear if there is any level of sprite to tilemap control or if priorities are fixed.

Anyway I fixed most of that as well, the primarly problem was with the sizes, and the observation that all things should be equal width/height soon made things look a lot better.

With those fixes the game is now playable, truth be told Kale had already done most of the work needed back when he looked at it initially and it just needed some fresh eyes to clean things up and better understand a couple of aspects of it.

There are still some things not quite right, I think the hardware has some kind of timers and readback of the timer registers because right now a number of elements in the intro animate at turbo speeds, and the music playback is also quite broken. I’m hoping that now I’ve fixed the graphical side of thing Kale will revisit those, but in what time frame remains to be seen.

The game sports a year 2000 copyright, I guess when you take that into consideration it is incredibly dated looking for the time period involved, but it’s what you come to expect from some of the games developed by relatively unknown parties outside of the Japan. It also coincides with when IGS were doing well making me think this attempt to jump into the games market might have been inspired by that.

Anyway, here are some screenshots from the current emulation of the game, with the various fixes I’ve made applied over Kale’s initial work from last year

(Current Emulation shots from PoPo Bear)

With the reverse engineering of the Gunpey compression scheme not exactly going well I decided to turn my attention elsewhere for the time being. (I did add a few things like the alpha blending, but it’s not worth showing)

Smitdogg and the Dumping Union got a rare Data East board for a game called Dream Ball, a gambling game.

The credit list I’ve been provided with is ‘J. Finney, TrevEB, Yohji, Smitdogg, The Dumping Union’

(The Dream Ball PCB, picture provided by The Dumping Union)

The hardware uses common Data East components, and is clearly purpose built for low-cost Gambling games, and appears to lack any form of sprite chip (it has a Data East custom 71, but without being paired with a 52 I guess it doesn’t handle sprites, probably just palette / mixing)

The game boots to an NDK 1993 copyright, which is starting to become interesting because it’s a company logo / name we’re starting to see in several Japanese gambling games with little in common between them.

Anyhow, moving on to the emulation, being common components it was pretty easy to hook the basics up, add some inputs and get a playable game. It will give a payout error if you select Payout because the hopper isn’t emulate, but beyond that it works, and was a trivial addition.

(Data East / NDK gambling game ‘Dream Ball’)

The game doesn’t seem to use any balls, not even lottery balls, but the background of the Title Screen is awfully familiar. For anybody who hasn’t already recognized it, it’s from Pocket Gal Deluxe another Data East game, at least THAT one has balls.. What this means however is it’s quite likely this ‘Dream Ball’ really is a Data East product, just licensed to NDK.

(The title screen background is recycled from Pocket Gal Deluxe)

I suggested to Kale that after Cool Riders we should take a look at another long-term non-working game, Gunpey.

The reason it hadn’t been emulated was because everybody was rather scared of the AXELL AG-1 blitter chip, boasting some useful features including graphic compression. Beyond that the game code is ugly, and difficult to follow, the interrupt system was less than clear, and previous attempts at writing the driver had resulted in something where the game code appeared to be running super-slow, the blitter copy was meaningless, and it wasn’t sending anything that resembled useful game data to the video device. Basically, if you ran it in MAME over the last couple of years you’ll have seen something like this at best. This is the result of the ‘blitter’ emulation copying some data from the roms to the screen, it’s clearly nonsense.

(Gunpey in MAME as it was 2 days ago)

Tasked with this Kale set about improving the interrupt emulation, and removing the hacks needed to run the game, while doing this he noticed something else, while the game was said to use a blitter there was actually also a spritelist in RAM, and tracing around the code showed that ASCII text from the game rom was being written here as sprites. With this in mind he changed the renderer to draw solid blocks for these and instead we ended up with something like this.

(Gunpey after Kale identified a sprite list, with solid block drawing)

Clearly a menu, the test menu. This required a little more work from him in fixing up some broken inputs and the like, but it soon became possible to navigate the test menu. I decided to help a bit at this point and hook up the same fake ASCII rom we used for Cool Riders up to the emulation, although in this case it wasn’t quite as straightforward because the ’tile numbers’ in RAM were actually co-ordinates, so to render them with the fake ASCII rom we had to convert each set of co-ordinates to a character number. I did a few, Kale filled in the rest and we ended up with this.


(Gunpey with a fake ASCII rom hooked up)

Doing this presented various useful test menus, making it clear that the OKI sound write had been hooked up to the wrong byte (I fixed that) and that the sound banking was wrong / missing entirely (Kale fixed that)

Now, keep in mind that the graphic rom is a 2048×2048 page of ‘textures’ (a very uncommon setup for a 2D game) you might ask why we didn’t just use the co-ordinates directly to index that page and draw the real text. The reason is it’s not really that simple, the co-ordinates were not references into that texture page, I did try. That’s actually where the ‘blitter’ comes in. It’s not so much a blitter to show things on the screen, but a device to copy graphics from the 2048×2408 page of graphic ROM to another 2048×2048 page of RAM, which is what we’d been trying to display in years before, not realizing it’s real purpose. The existing hookup was wrong anyway, putting the data in the wrong places, so I hacked up a quick viewer for that RAM, and improved the copy operations somewhat. This left us with a page of data in RAM where there clearly seemed to be a font at one location, as shown here.

(abusing the MAME tile viewer with 2048 wide tiles to identify where a font gets copied to RAM)

Yes, that’s tiny, but remember that’s a view of an entire 2048 wide texture page in RAM, and I could just about make out some character like symbols over there, you need a keen eye for these things sometimes…

I then attempted to replace the fake ASCII font with the one from this data, leaving us with this…

(Gunpey, first attempt at using the font copied from ROM to RAM)

Clearly not quite right, but at the same time it clearly IS a font as expected. Kale did some checks, and it appeared even my new copy operation was buggy, every texture was being copied at half-width, to the wrong places (I’d initially made the RAM texture page 1024×2048 based on the values used by the blitter) This meant that while we were indexing roughly the right place for the real font it couldn’t be right until that was fixed, so after a bit of head scratching I fixed it, so we ended up with some more readable text using the real fonts.

(Gunpey with the original font hooked up properly)

Booting the game at this point resulted in something actually resembling a game, but with many corrupt graphics. This was because our indexing was still incorrect for anything not on the first few lines of the RAM page. This did allow for some more fixes tho, the Demo Play text for example showed that the hookup for X/Y size sprite size Kale had done was swapped around (unsurprising because he only had 8×8 sprites to work with before) That made a good reference point for a fix.

(Gunpey, preliminary ingame shot, showing Demo Play text used as a reference for another bug fix)

After a bit of work I was able to improve this, and get the game booting with somewhat correct graphics.

(Gunpey with more of the source offsets fixed)

Meanwhile Kale was fixing the palettes. The palettes are stored in the ROM with the graphics, and copied to the RAM page in the same way as everything else. In addition to this Kale added support for transparent pen, and decoding of the 8bpp graphics. (The chip supports 4bpp, 6bpp, 8bpp and RGB555, but the game only seems to use 4bpp and 8bpp, although the test mode has tests for the others) He also fixed sprite X/Y positioning and a few other problems.

(Gunpey part way through Kale fixing some graphical issues)

At this point the game booted and you could easily identify what was going on, but was still it had significant, and hung if left in attract mode. Also inputs weren’t working on the I/O test screen nor properly on the character select screen. Kale figured out this was an interrupt problem, fixed that, and also identified the end of sprite list marker, and fixed that, getting rid of most bad graphics. We also found things to work better without an ‘invert bank select’ hack that had been added earlier for the spritelist, so that was removed.

I then spent an hour or two debugging some of the remaining graphic problems, figuring out, getting rid of some issues where graphics were incorrectly offset (because we weren’t using enough lower bits to index the RAM bitmap when drawing sprites) and identifying which bits were source sizes, and which ones were zoomed sizes.

That leaves us where we are now. The majority of remaining glitches can be attributed to a handful of things. The major one is the graphic compression, it’s used for most backgrounds and a number of other elements, there doesn’t seem to be an obvious bit to enable decompression when the sprites are drawn, so it might happen during the blits. Beyond that there are still transparency / alpha issues, and the zooming hasn’t been hooked up. Anyway, this is what it looks like *now*

(Gunpey as things stand now, still missing the graphic decompression, but otherwise looking good)

Not bad for a days work on a driver that has been sitting idle in the source for years where every previous attempt at making progress quickly hit a brick wall. I think it’s fair to say that Kale did most of the important work with this one, especially in getting past that initial brick wall and identifying some vital points about the hardware, but like Cool Riders team work was involved in getting us this far. The compression looks interesting, the compressed data for the BanPresto logo case shows that it might not be especially efficient, the white fill still needs a significant number of bytes to represent it, but we’ll see.

The actual game is most similar to the PSX version that became playable in UME/MESS recently, I don’t know if the background data there will be helpful / needed to decompress this, but still it’s something you might find interesting. Obviously the hardware here is VERY different, and strange for a (c)2000 release, an original V30 CPU being used at that point definitely wasn’t common.