David Haywood's Homepage
MAME work and other stuff

Gamate Makeover

October 20, 2017 Haze Categories: General News. 7 Comments on Gamate Makeover

The Gamate is a console made by Bit Corporation, it was released around 1990 and designed to compete with the original Nintendo Gameboy offering a similar 4-shade green tinted screen which unfortunately suffered from a lot of ghosting, which combined with the rather poor response times many games have on the controls made playing it quite a frustrating experience.

It’s a Taiwanese system, and compared to others developed in the region, even many years later, it was surprisingly well built and had the potential to be fairly competitive.

MAME has had a driver for a short time now, coming from when MESS was merged in, however prior to the original MESS driver being developed around that time there were no dumps for the system due to the custom card media, and protection system that hadn’t been cracked. Once the protection had been figured out dumps arrived and MESS got a preliminary driver that ran the dumps available at the time, however as new dumps showed up the emulation was found to be lacking and didn’t see the necessary improvements to support them properly.

Kevtris had already written up a tech document about the system, and done his own FPGA based implementation of it, so with those in hand I decided to rewrite the majority of the MAME driver. As a result the MAME driver now appears to be on par with the original system, complete with many graphical errors that were also present when using original hardware, but harder to see due to the poor quality LCD screen (for example flickering sprites, wobbly status bars, badly flipped sprites etc.)

At this stage most games that were known to be released have been dumped for the system, so it seemed like a good time to improve the driver. There are some hardware features that none of the games seem to use however, and only one uses the serial link which I haven’t emulated yet (it apparently barely works even with original hardware so I’m not sure it will really work under emulation either)

From a hardware perspective the system is quite interesting, it uses a 6502 series chip, with an AY8910 clone for sound (strangely the original MAME driver had an entirely custom implementation for this)

Video is probably where the system design becomes a bit more questionable, the CPU drives 2 1bpp framebuffers which are combined to give 2bpp output, however, it can only write one framebuffer at a time (there’s a register to switch) and every read/write has an auto-increment, so to draw 4 colour graphics is tricky. There are no hardware sprites or tilemaps, it’s all done with software in the framebuffers.

There’s x and y scrolling, but they apply to the entire display so you’re left either having to erase and redraw either your backgrounds or your sprites if you don’t everything scrolling together, that can be quite demanding on the relatively weak 6502. This is why some games have wobbly status bars when scrolling, as after scrolling the status bar needs to be redrawn at a new position.

There are also 2 special ‘Window’ modes that make having a non-moving status bar easier, the most commonly used one of these allows the top 16 rows of the display to become a static, non-scrolling area taken from a different part of the video ram. This is one of the things that was previously not emulated in MAME.

The 2nd Window mode, which nothing seems to use allows for between 1 and 7 lines taken from yet another place in VRAM, although I think it also turns off vertical scrolling for the rest of the screen, so could be seen as less useful.

Anyway, what sparked my interest in fixing up this driver was a recent dump of Kiki Inland, which is a game influenced by Adventure Island / Wonderboy. The emulation was especially bad before, now it’s just bad in ways that match the original hardware.

Some screenshots for the non-videoy people. (I’ll add more later)

Gamate Bootup
Kiki Inland Kiki Inland

and some videos for people with better bandwidth.

I’ve also made some videos of some of the other games on the system, and will likely upload more to my YouTube channel in the coming days

In other, less interesting news, I updated the MAME SH3 and SH4 cores to use the SH2 recompiler, which gives the Cave SH3 / CV1K driver a speed boost on weaker hardware. Unfortunately most Naomi games don’t seem to want to boot with the recompiler enabled, so it’s still disabled on those, if you do enable it then Crazy Taxi gets a boost to around 75-80% ingame without any other driver optimizations on my system tho, which is a good start if the issues can be fixed.

Go to article.. »

On Target

September 28, 2017 Haze Categories: General News. 9 Comments on On Target

The only thing Gaelco appear to make these days are electronic Darts games, therefore the gun shooting games they produced in the past are in some ways probably more connected (albeit still loosely) to the current product range.

One of the Gaelco gun shooting games developed in the 90s was Target Hits, a relatively simple collection of 3 different shooting challenges all involving hitting moving targets with precision. Target Hits is another one of those games that was protected with a DS5002FP so until now was unemulated.

Morten Shearman Kirkegaard and Peter Wilhelmsen did their magic to read out the SRAM content for the DS5002FP from 2 Target Hits boards, one donated by Brian Troha, and the other purchased, but very kindly picked up by Clawgrip as it was a full cabinet setup, pick-up only and we only required the PCB. This involved a drive from Madrid to Bilbao and back again so we’re very grateful for that as the game doesn’t actually show up too often. As a bonus, the romset on the PCB he picked up is clearly an undumped revision too, so even if the SRAM extraction had failed (which it didn’t) it would have been worthwhile anyway. That will be dumped in the coming days, it identifies as Version 1.1 like the parent set in MAME, but shows a different checksum.

The 2 boards allowed us to easily construct a good dump, the game is now playable. There are some questions over the gun hookup as the game tells you that you have to reload between shots, but doesn’t actually require you to do so. It’s possible the reload logic was part of the gun not the game, but I’m uncertain. Here are some screenshots. The visible area is also uncertain, I’ve decided to go with the area covered by the startup screen because while most of the background graphics are much wider, there are some stages that aren’t, and usually startup screens are designed for monitor calibration. The screenshots are with the smaller visible area.

Target Hits Target Hits
Target Hits Target Hits
Target Hits Target Hits
Target Hits Target Hits
Target Hits Target Hits

I’ve also made some videos, these were recorded before reducing the visible area.

*edit* the previously undumped set was dumped, so we now have 3 sets, 2 identifying as 1.1 but clearly different code, and a single set as identifying as 1.0. If you have a PCB for this game with a boot screen that differs from the 3 shown below please get it dumped.

Target Hits Target Hits Target Hits

Two additional Touch and Go PCBs were also dumped because when that was originally dumped we didn’t know about the issue with some bytes not reading properly, it turns out our original read did infact have some errors, and those will be corrected shortly.

We’re still after working ‘Play 2000’ PCBs.

Go to article.. »

Deco Cassette in MAME 0.189

September 11, 2017 Haze Categories: General News. 10 Comments on Deco Cassette in MAME 0.189

MAME 0.189 was released the other day and one piece of progress that went into it, which I actually feel is one of the most significant progress made between 0.188 and 0.189 comes in the form of improvements to the DECO Cassette System driver. AJR has put a fair bit of effort into getting these things right, and in 0.189 it’s finally paid off.

Since it was first emulated the DECO Cassette System has proven tricky to emulate properly, not only due to the fragile nature of the games meaning that every dump we have should be treasured, but also because it was built as quite a flexible system, with the video system offering a number of different modes of operations, many only used in a handful of places. It also didn’t help that some of the games are just plain ugly on real hardware, almost as if even the programmers didn’t fully understand the hardware and sometimes ended up just accepting what was displayed was the best they were going to get, even if it wasn’t what they were aiming for.

One of the big issues the driver has always had came in the form of the way certain colour mixing modes work; the incorrect emulation of these resulted in a number of situations where the colours being shown in MAME did not match those being output by the original games running on the actual system. With MAME 0.189 it appears that this issue has finally been solved, every emulated Deco Cassette game now perfectly matches the colours in all the original hardware captures we have been able to find.

While not a particularly interesting game, one of the most obvious examples of where things improved was with Lucky Poker, old MAME shots are on the left, correct, newer MAME shots are on the right. You can see that the game gains a green background and black text boxes ingame, and a blue background on the title screen.

Lucky Poker (wrong colours) Lucky Poker (good colours)
Lucky Poker (wrong colours) Lucky Poker (good colours)

The Deco Cassette Multigame (an unofficial conversion for the hardware that uses a ROM containing the games instead of cassettes) also saw the selection menu become a lot less garish, now correctly showing a blue background.

Deco Cassette Multigame (wrong colours) Deco Cassette Multigame (good colours)

Astro Fantasia is another where the colours changed a lot, previously the emulation looked like this, with every stage having the same colours.

Astro Fantasia (wrong colours) Astro Fantasia (wrong colours)

With the fixes each stage gains a unique palette.

Astro Fantasia (good colours) Astro Fantasia (good colours)
Astro Fantasia (good colours) Astro Fantasia (good colours)

We have videos of the game Manhattan which show similar colours changing between levels, but from what I can tell that’s a different version of the game, the one we have doesn’t even attempt to write to any registers to do this. It isn’t uncommon for there to be multiple versions of Deco Cassette games. One game with significant colour changes between versions, which can now be seen is Rootin’ Tootin’ (aka LaPaPa)

In older MAME versions both versions of the game (the one with Rootin’ Tootin’ in attract, and the one with La Pa Pa in attract) used the same default blue background as the bios

La Pa Pa (Rootin' Rootin') (bad colours) Rootin' Rootin' (bad colours)

With the fixed colours there’s actually a very significant difference in the background colour of each set, one having what is actually a rather ugly green background, and the other going for a more neon look with a black background. While the green looks ugly, it is verified on hardware, it wouldn’t surprise me if the set with the black background is a newer set after players didn’t like the green much.

La Pa Pa (Rootin' Rootin') (good colours) La Pa Pa (Rootin' Rootin') (good colours)

Highway Chase was also much improved in 0.189, with the headlight effect working properly. The new colours are arguably uglier, with a blue road instead of a black road, but again this was a Data East design choice, the blue road is verified against hardware; you can see the same colours & graphics used in the ‘madalienb’ clone of ‘madalien’ so again it was probably something Data East changed over the course of several revisions until they were happy with it (although no cassette versions with the grey road have been seen) Left is Highway Chase in older MAME versions (headlight effect not working – always on but not masking anything, black road) and on the right is Highway Chase in newer versions (headlight masking works, road is blue)

Highway Chase (bad colours) Highway Chase (good colours)
Highway Chase (bad colours) Highway Chase (good colours)

There are many other examples of places where colours have changed, and as mentioned, in every case, even ones where things look subjectively worse, the new colours are verified against actual hardware videos, so again, big thanks to AJR for working on this because it really brings the actual driver for the system up to scratch. Now here’s hoping some more rare cassettes turn up and can be dumped before it’s too late for them

Go to article.. »

Gaelco Mania

September 5, 2017 Haze Categories: General News. Comments Off on Gaelco Mania

The generally less interesting part of today’s news is about Gaelco’s Maniac Square.

Maniac Square

Again, a DS5002FP protected version of this game exists, and again we ended up finding a previously undumped set, which is clearly an alternate code revision while buying up boards for dumping. Like with Glass both sets identify as Version 1.0. The first of the boards was supplied by Charles MacDonald, so thanks to him goes for that.

Maniac Square Maniac Square
(boot screens from the 2 protected Maniac Square sets)

As with Glass, there was already a version of Maniac Square emulated, an unprotected version with the following boot screen. In this case they did actually remember to remove the Co-Processor message from the screen.

Maniac Square

So, what is there to say about Maniac Square? Not a huge amount really. The protected versions are now playable, as you can see in the screenshots below. From a gameplay point of view I’ve not been able to find anything different compared to the unprotected version.

Maniac Square Maniac Square
(gameplay shots from the protected version of Maniac Square)

It’s a simple ‘race against the clock’ columns game, and there are no difference to write home about when comparing the protected versions to the unprotected versions in this case. It’s the same simple game. Analysing the DS5002FP program was maybe a little more interesting, as it looks like there might be an entirely unused command in there (or I haven’t found the point in the game where it gets triggered) but again, it’s such a simple game there’s not really even much interesting the protection can be doing.

I guess the problem with Maniac Square is that the released game is very much overshadowed by the prototype version. For those not in the know, the prototype clone of Maniac Square, that has been in MAME for many years runs on different hardware and presents the game in an entirely different way, with different special block types, counters for each colour, a fake pinball style dot matrix display giving you messages of encouragement etc. it’s just a much more interesting piece of software. I guess the final release with the pressure of the timer lives up to the name of ‘Maniac Square’ a little better, but it’s simply an inferior product all round. So yeah, the most interesting thing about Maniac Square remains a prototype that has been emulated for over a decade, it’s good to know the protected originals are now emulated for the sake of competition, but there’s nothing really else to say about them.

Maniac Square prototype Maniac Square prototype
(The prototype, emulated since 2003, is still a more interesting game)

Go to article.. »

Glassic Gaming 1.0

September 5, 2017 Haze Categories: General News. 1 Comment on Glassic Gaming 1.0


One thing that has become clear while working with the Gaelco games is that the versioning they used was a bit of a mess. We have 2 World Rally sets that identify as “Version 1.0”, 2 protected Maniac Square sets that identify as “Version 1.0” and 2 protected Glass sets that identify as “Version 1.0” and the same for a number of other games, despite in all cases the code clearly being a different revision. Most Gaelco games display some kind of checksum on startup, but as we’ve seen with Alligator Hunt, that doesn’t even always tell you if the ROMs are different as in the case of Alligator Hunt the region control byte is outside of the checksummed area.

With Glass, there are also 2 versions that identify as “Version 1.1” and display 1994 Version on the title screen. One of those is the unprotected Korean version that has been emulated for a while now, the other is another protected set.

The problem with Glass is that Version 1.1 isn’t actually very good, the Korean version is censored (except for the end sequence, which apparently they missed) and the images are replaced with drawings, rather than photographs, again to make them more suitable to a wider audience. Even stranger than that, the 1.1 set lacks some of the gameplay elements of the 1.0 set, such as not including static ‘skulls’ in the playfield as part of the level designs that both block your shots and require you to navigate around as they kill you if you touch them.

Now, as mentioned, there are 2 “1.0” sets of Glass, both protected. The bootup screens for the versions we know about look like this

Glass Glass

I can’t tell you the exact difference between the two sets in terms of gameplay. In the case of Glass it calls the DS5002FP the ‘TURBO’ chip (it’s not really accelerating anything, just a fancy name) and as you can see in the above pictures, it is reporting as ‘OK’

That’s because, as you’ve probably guessed by now, we’ve managed to successfully dump the DS5002FP SRAM from a Glass PCB. This is also one of the rare occasions where the dump came out perfectly, interestingly it also used a Fujitsu MB84256A-70L type SRAM, like the World Rally 2 that also came out really well, maybe those chips are more reliable than the others, or maybe we just got lucky.

Below are some screenshots from the attract demo of the 1.0 sets showing the skulls in the playfield.

Glass Glass
Glass Glass
Glass Glass

Also here’s a video, recorded a few days ago before we’d verified the SRAM dump with a 2nd PCB

Now I’ve already mentioned that the Korean 1.1 set is a bit rubbish, but the SRAM dump we have also appears to work with the 1.1 protected set (not entirely surprising) and somehow, despite having the proper images, and no censorship, it seems to have had the entire attract gameplay demo stripped out, simply showing the ‘reveal’ sequence twice where usually it would show the game being played. At first I thought this might be because it requires a different SRAM content, but it actually looks like it’s just been intentionally removed instead. Not sure why anybody would do that (although I would be interested in knowing if anybody out there happens to own a board that shipped from factory as 1.1 and hasn’t been modified in any way can confirm it) The bootup screen for protected the 1.1 set looks like this, for reference.

Glass Glass

and to complete the set, the already emulated unprotected, censored version has the following boot screen (yes, they were too lazy to remove the ‘TURBO OK’ message, even if the Co-Processor isn’t used – it’s simply hardcoded to always show OK)


It would be interesting to know if there are any other Glass versions out there with different checksums shown on startup. Actually it would be interesting to know for quite a few of the Gaelco games, based on what we’ve found buying up boards for dumping the SRAMs it would seem there are quite a lot of alt revisions out there that maybe people haven’t noticed.

Go to article.. »

Hunting Alligators

August 29, 2017 Haze Categories: General News. 16 Comments on Hunting Alligators

Again, working with Morten Shearman Kirkegaard and Peter Wilhelmsen on this, so any time I say ‘we’ I mean those 2 with me doing the MAME / emulation side of things.

Tracking down Alligator Hunt boards where the Co-processor (DS5002FP) battery was still alive and the SRAM intact was no easy task. Due to the amount of time unprotected / hacked roms of the game have been available, and the fragility of the boards, a lot had already died, or unfortunately have been converted over prematurely by people wanting to avoid them dying, making it impossible to know if they still had valid code in the SRAM or not.

Alligator Hunt

Things got off to a good start when DarkSoft donated an Alligator Hunt PCB to the cause, the battery on that one was showing a worryingly low voltage, but the SRAM was still intact, and we managed to get a dump (complete with Highscores of a previous owner) However, as the dumping process still damages random bytes, a single board was not enough to be confident in enough in the dumped SRAM to say it was good; infact a number of bytes in a data table had to be handfixed just to get it to pass an internal checksum, luckily those bytes all came from one big table which was also present in the unprotected version, however, the code area of the DS5002FP SRAM had no such checksum.

Many sellers of the game were contacted, all but one were selling boards that had already been converted to use the unprotected set, something that is easy to tell from the program checksum printed on the startup screen of the game. The one board that didn’t match the checksum of the unprotected set was however still something of a mystery, it didn’t match the known checksum of the protected set either, so we weren’t exactly sure what it was going to be, but decided to take a gamble on buying it.

When it was arrived, it was dumped, and it turned out to be another unprotected set, which would have been a bit of a downer except for the fact that it was actually a very different set to the one in MAME. The new set has a different background on the title screen and skips the first 2 levels with the skateboarding kids, instead jumping straight to the ship launch and space levels. Obviously my first thought was that it might be some kind of hack, but all the code / data offsets in the ROM strongly indicate it’s compiled / assembled from scratch. Possibly a set used for a show or competition?

Alligator Hunt
Alligator Hunt Alligator Hunt

What was more curious about this set however, is despite being an unprotected set, not making use of the DS5002FP or SRAM, the voltage on the battery still showed good and the DS5002 box looked like it had never been opened or tampered with. This again makes me wonder if the ROMs on the PCB had been swapped on for a specific event, and then never swapped back to the protected set.

So, come the weekly dumping session it was decided that an attempt would be made to dump the SRAM on this board, to see if it actually contained anything valid. To cut the story short, it did, so this unknown version of Alligator Hunt, despite having an unprotected ROMset on the PCB, actually still contained the original code in the SRAM and gave us the 2nd dump we needed to verify the dump from the board DarkSoft provided. With the 2 dumps I was able to construct what I’m confident is a 100% correct version of the SRAM content which can be used to emulate the protected version of the game with certainty that the correct code is running and correct data is being provided by it.

The protected version we had was actually interesting for other reasons too, it’s has Spanish ‘win-quotes’ between levels, and Spanish subtitles on the cutscenes. Maybe not too surprising because Gaelco is a Spanish developer, but unexpected. I did for a while wonder if the DS5002FP might provide the region as it’s not unheard of for protection devices to supply a region byte; IGS did that all the time for example. You can see an English quote, and a Spanish quote on the screenshots below.

Alligator Hunt Alligator Hunt

Anyway, my uncertainty over what determined the language was quickly put to rest when I checked my email and found an email from a long-time MAME user who wishes to be identified as ‘Pablo’ saying that they’d dumped the program ROMs from a dead Alligator Hunt they had and one of them didn’t match MAME. The new dump quickly pointed at a byte in the main program ROM controlling the game region thus giving us a new parent set in MAME and making the Spanish set a clone.

Being the curious kind, I decided to see if the byte in question controlled anything else, and to my surprise it did. The byte in question not only controls the game language, but also the region warning (US, NON-US, or none) and maybe most interestingly the title screen. One bit in the byte causes the game to identify as ‘Lizard Hunt’ instead of Alligator Hunt. I’ve not heard of the game actually being released with this title, and no ROM using that title has ever been dumped, but it certainly existed as a possibility, maybe it was intended to be released to the US market with this title instead?

Lizard Hunt

Anyway, here are some videos, first from the newly emulated protected set, second from the new unprotected set.

Hopefully next in line is Glass, we have one SRAM dump from that which works, but like Alligator Hunt, we need to verify it with a 2nd. That would have been done already, except one of our PCBs was in too bad condition to cleanly attach the dumping device, so even if that PCB was working before we started, it didn’t survive the process. We’ve got another PCB on the way, hopefully that one is better, and hopefully we don’t need a 3rd to be 100% sure on it (there’s a possibility of that, Glass uses a lot of data tables, they’re not easy to verify against the unprotected set either)

We’ve still not managed to locate a single working PCB for ‘Play 2000’ which is worrying. Gambling titles are some of the most ‘at risk’ out there due to regulation etc. and ones like this where we know in a few years they’ll definitely all be dead due to the battery are especially at risk. Again, if there’s any possibility you might have one in your collection, please consider donating it.

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.