fixed up some bugs in the ARM core, identified IRQ controller, located palette…
other layers aren’t yet emulated, but you can already see the palette uploads for what is running eg. the IGS logo
If you wait a while you get the ingame HUD for attract mode
located the background tilemap data, not added to video mixing yet, but can see tilemap RAM content in tilemap viewer
found sprite list. sprites use 1 rom for ‘mask’ (1bpp shape) and another for colour (5? bpp palette) Similar to PGM1, but not the same as the offsets to both are in the sprite list this time. hooked up the 1bpp mask data for now.
started hooking up colour data to the sprites, giving them detail, not quite right yet
worked out the slight scramble on the colour data
improved various things about the sprites, still some issues with y-flipped sprites tho
Metallic added preliminary sound, as I can’t demonstrate this in screenshots here’s a quick video
started adding in the background layer (priority still wrong) and fixed the y-flipped sprites. still the odd sprite issue (actually looks like the badly coloured sprite in the 2nd to last screenshot should just be hidden by the bg and never seen) sprite zoom not yet implemented either. Metallic also made further sound improvements.
emulated sprite priorities, fixed a few other sprite bugs. most (all?) the features of the video needed by Oriental Legend 2 are now emulated, so it’s looking pretty good. made a new video
added linescroll effects
although annoyingly the game still seems to crash at this point.. even with no hacks etc. I’ve seen videos of the hacked build doing this too, so bit of a mystery at this point, maybe another ARM bug?
While I came up with a crude hack to work around the above crash (which probably isn’t safe) I’ve been unable to find a real solution yet, although the game is playable past this point with the hack.
PGM2 dumping is likely to resume on Wednesday, maybe having proper dumps of some of the other titles will throw more light on the issue.
Morten Shearman Kirkegaard and Peter Wilhelmsen built an FPGA based board that plugs into the program ROM socket on a PGM2 board.
Doing this allows direct control over what the IGS036 CPU reads, and allows us to monitor all bus signals to and from the external ROM.
The hardware setup they created looks like this
With this, and existing knowledge of the encryption scheme they were able to modify the code running on the board while it was running, thus allowing their own code to be injected. Code was added to read the internal ROM space at 0x0000 to 0x3fff, as we didn’t know how the video hardware worked at this point the value read was then used as an offset to read into external rom, the bus signals were monitored meaning we could translate our external rom read offset back into the byte value for each address in the internal rom. This proved successful. Surprisingly, unlike the later PGM1 games there wasn’t even an Execute Only area on the PGM2 CPU being read (Oriental Legend 2) so they managed to get a complete dump.
All the actual dumping was done without the PGM2 board hooked up to monitor / display, but instead simply by looking at what the FPGA was sending back. (Earlier testing to get the setup built obviously did make use of an actual monitor)
Anyway, it was easy enough to see some of the startup strings in the internal ROM.
Hooking this up to MAME revealed a few things, first of all the internal ROM code really doesn’t like the ARM7/ARM9 MMU implementation; it could be different here, so for the time being I’ve disabled it if the CPU type is IGS036. That allowed a few basic devices to be hooked up, which gave the following
After that the code rather jumped into the weeds, clearly there are other ARM9 bugs in MAME, as the code flow below shows
Obviously it shouldn’t be jumping straight back into the middle of a BL (HI) / BLX (LO) combo. This one seems relatively easy to fix, it was simply adding 4 to an address where it should add 2.
Even with that fixed, the code ends up going off the rails tho. More investigation is needed, but this is a good start.
btw, if anybody has “Jigsaw World Arena” or “Puzzle of Ocha / Ochainu No Pazuru” we could do with borrowing them. They used to sell for dirt cheap relative to the other PGM2 titles at the time (around $250 – $300) but lately they haven’t been showing up for anything like that. They’re single board PGM2 games that were only distributed in Japan to the best of our knowledge. The internal ROM is different for every game, so they will need dumping using the methods outlined here. Apart from those 2 boards we have access to at least one of each other game (although AFAIK only the China regions – internal ROM controls the region)
Further note, please don’t post links to that ghastly hack of MAME with badly hacked in PGM2 support, it’s loaded with anti-debugger nasties, has no source and it doesn’t seem safe to run (it blew up my VM image) and is entirely the wrong way of going about things. The point of the work being done here is to actually get it done as it should have been done.
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)
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.
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.
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.
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.
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.
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.
Astro Fantasia is another where the colours changed a lot, previously the emulation looked like this, with every stage having the same colours.
With the fixes each stage gains a unique palette.
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
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.
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)
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
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.