Back in 2004 we lived in a time when not all ports of games were simply emulation based, but instead many were genuine reprogrammed piece of software. I briefly mentioned the Radica ‘5-in-1’ Space Invaders TV Game in my previous update, and that’s what I’ve been working on over the past week. If you follow my YouTube channel you’ll have noticed various Work in Progress updates on it.

It’s an interesting piece of hardware / software, and emulating it has so far been a lot closer to emulating a console than a piece of arcade hardware. Everything is driven off a 6502, but with various DMA channels and an unusual video system which stores graphics in texture pages, but then for the tilemaps, still addresses them as tiles etc. and in the case of Qix can also change the base pointer from ROM to RAM.

It also shows that back in 2004 this kind of thing was a viable product. Sure, there were emulators, and you could easily make a case that MAME ran all the games in this collection just fine back in 2004, although truth be told MAME wasn’t actually great back then (which is why it’s so painful to see people using MAME cores older than that just for the sake of running it on some god-awful hardware like the SNES mini)

So far I’ve managed to get most of the video features working, or at least have some understanding of them, although I don’t think anything is quite perfect yet. Transparency pen is definitely wrong, as is palette selection on the 8bpp sprites. Palette itself was an interesting one, it’s clearly based on some kind of HSL type colour model, not RGB, again making it very unusual compared to most arcade hardware I’ve emulated. Colours are mostly correct in MAME with this model, but certainly not quite right yet.

Sound, which I haven’t got around to emulating yet, appears to be 6-channel ‘DMA’ DAC style, where the game code sets pointers to rom and fires off a trigger. It looks like these might also generate a custom ‘finished’ interrupt too, as well as setting ‘finished’ flags (which the games wait on sometimes, hence the Radica logo vanishing so quickly I believe, because we’re always reporting sound finished right now)

Before continuing, here are some shots of the Space Invaders one running.

The programming on these is interesting too, the hardware clearly has a way of having higher priority tile clip out sprites and based on real hardware footage Lunar Rescue uses this at the edges of the screen to create a slightly narrower view. Strangely Space Invaders doesn’t, and instead has some ugly wrapping effects with the UFO even on real hardware. It seems like the individual games might have had different programmers behind them, because each one seems to make use of the hardware in slightly different ways. Aside the aforementioned clipping there are a number of other annoying issues issues too, for example the code buffers the sprites, so there’s a noticeable input delay. This delay is really noticeable in Qix where the background layer isn’t buffered so while moving you can see your line being drawn where the player sprite should be, ahead of the actual sprite! I’ve checked real hardware videos and the same is present there.

This is really where I was going when I said in 2004 these things were more viable than maybe they are today. None of the reproductions on offer here are perfect, it’s easy to tell them all apart from the arcade originals, but at the time standard definition CRT TVs were still in the majority and a number of these games ran on vertical monitors, so you’ve automatically got a resolution issue with most TVs being unable to display the required resolutions without at least altering the graphics / screen arrangement. It would also have been relatively expensive to have a CPU capable of emulating these things back then (the mainstream consoles of the period were only just capable of it) Likewise filling the units with the CPUs etc. that the original games used would also have been expensive (and likely the parts difficult to source) so instead you got ports, rewrites of the games that were suitable for the hardware available at the time. It’s not actually too different to how/why the 8-bit computers got ports in the 90s, except by 2004 it was much easier for developers to get access to original resources such as graphics / sound rather than having to do those from scratch too.

These days emulation has set the bar much higher, and while you still do see sub-par products like the NES Classic and various Raspberry Pi based solutions somehow selling despite still based on 15-20 year old emulation knowledge, they’re still a step up in quality than something you could just plug into your TV in 2004. Admittedly there are still hundreds of cheap Chinese handheld devices based on similar evolved 8-bit tech to these things, but very few of those claim to be in any way licensed.

I guess that’s what makes this kind of device fascinating to me, they’re official ports of the games just like any other, but they’re also “dead-end” ports, versions of the codebase that existed at the time and have no commercial reason to be brought forward; creations that exist because limitations of the time made them more acceptable back then.

Obviously MAME has roots in arcade emulation, and being able to show the course of evolution of these arcade games, how they ended up on home systems and in devices like this one actually means the path of the project is reflecting the course of the original material. How was Taito giving access to their 1978 hit Space Invaders in 2004? By allowing Radica to license the IP produce these devices so people could play it at home. Now, thanks to emulation, we can help to document that part of the story too, show where these things got it right, and where they got it wrong, and what possible reasons there were for that.

Radica didn’t only use this hardware for the Space Invaders product, there was also a gimmicky version of Tetris running on it, and probably plenty of other titles. We know they switched to a XaviX based solution at some point (which is more complex and has actual custom CPU opcodes etc.) but there are almost certainly a whole bunch of other products running off the same hardware as this one.

The Tetris one is interesting for many of the same reasons I highlighted above, it’s another thing that was licensed and ported all over the place, and being able to document / show that is culturally and historically important. Unfortunately the Tetris one crashes in MAME when you try to start a game at the moment, so it’s not too interesting to show at this point.

One thing of note about the Tetris one is that you can access a hidden test mode by holding Down and Anticlockwise. Space Invaders contains images for a similar test mode, but I haven’t worked out how to access that one.

This also allows player 2 inputs to be tested, which is going to be fun to figure out because I think they’re being read in a strange way, maybe via Serial or some hack of the ADC because they’re not read directly (which maybe shouldn’t be surprising, the P2 controller is optional and plugs into the P1 controller)

Anyway, I’m going to continue to try and improve these, look into adding the sound, see if I can figure out why Tetris crashes, and fix up the transparencies. I’m also hoping some more games on this hardware get dumped. Sean Riddle picked up a “Golden Tee Home Edition” and “Skateboarding” which both look like they might fit here (and if they do, both use horizontal scrolling to, so will provide additional evidence for improving the hardware emulation as nothing we have so far does)

*edit* I’ve improved the video emulation a bit, here’s an updated video showing the current state, some of this is a bit hacky due to lack of software to make conclusions, but at this point I think any visual problems aside the slightly off colours are the same as the real hardware.

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

Need to look into adding sound next.

As I’ve mentioned before Semicom was one of my favourite Korean arcade developers. While Semicom games are often a bit rough around the edges, and borrow ideas heavily from others they were original products and for the most part are playable.

Hammy found he had a Cookie and Bibi 2 PCB that is actually rather interesting, because it seems to be an earlier and generally forgotten version of the game; I don’t like to use the word prototype, since it probably isn’t, but it definitely seems to be rarer than the more common version that was already in MAME. The giveaway that it’s an earlier set to me is that it uses the old style Semicom logo, as found on Hyper Pacman, rather than the newer Semicom logo found on the later games. Most of the backgrounds are also different. Test mode is also even more incomplete (not that it is complete even in the set currently supported, Semicom often just didn’t bother to finish the test modes)

One of the other interesting changes is the screen positioning, the newer version that’s already in MAME has the screen more centered, moving most of the important graphics up by 8 lines and placing the image in the center of the black borders, rather than leaving 16 blank lines at the top. Strangely the title screen background wasn’t re-positioned in the same way, probably an oversight by Semicom.

The other obvious change at surface level is the older set will do 1P vs 2P versus mode on a single coin.

The game also expects different protection data, meaning it has different MCU content, I’ve faked this for now but we need to verify it.

Overall this is a very significant revision and clearly shows the game at an earlier point in development.

Here are some comparison shots, with the existing MAME set on the left, and the set Hammy dumped on the right.

So yes, that’s a nice little piece of history.

I’ve also been working on emulating the Radica ‘5-in-1’ Space Invaders TV Game. It’s a 6502 based device (that doesn’t appear to be a NES clone) but has some very weird video hardware, and might have a custom CPU core as the way the interrupt vectors work is non-standard. So far I haven’t managed to work out how the graphics / sound actually work for most of the games, although you can see it is running the menu, and you can just about recognize Space Invaders. Weirdly the graphics are all stored in ‘pages’ that are 256 pixels wide, rather than as tiles, but the game appears to have tilemap like structures in RAM. It might be there’s a DMA operation that converts the formats.

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

One of the games in the collection is Qix, which handles video in an entirely different way, writing directly to a framebuffer.

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

There are plenty of reviews of this device on YouTube, including some with decent quality footage captured from the original hardware such as this one which will prove valuable for testing / reference.

What’s interesting is that the Radica Tetris unit looks like a similar piece of hardware, and according to Sean Riddle, who is dumping these things, contains the same CPU die in one of the globs (which are used instead of real chip packaging) and also contains what looks like a ROM glob with the same pinout as the Space Invaders one, however unlike the Space Invaders one it lacks a 3rd glob. My theory at this point is the 3rd glob is actually dedicated RAM / framebuffer just for Qix to use. Hopefully I’ll have a dump of the Tetris one to look at soon as it might allow me to make more sense of this Space Invaders one.

I do wonder if there were any other Radica TV games based on the same technology, obviously the Genesis ones are just cloned Genesis hardware, but there are a lot of other Radica products and they’re exactly the type of thing MAME is well positioned to be emulating.

I decided to revisit one of my older drivers, Black Touch ’96.

This was promoted to working last year after code anaylsis showed that the majority of the bugs in the game did not appear to be emulation issues, but just the result of some very bad programming.

Examples of this include the game timer not working (it checks a variable in workram that never seems to be set correctly, so is reset to 20 every single frame) as well as enemies and other items ending up outside the area of the screen you can move to, walking on the backgrounds etc.

The sound is driven by a PIC16C57 which was deprotected and dumped as part of the old pre-Caps0ff decapping project, but until now nobody had got around to hooking it up.

I hooked it up, and it seems just as badly programmed as the rest, for example once it starts playing music in attract mode it never seems to send a command to turn it off. The choices of sounds are awful in many cases too.

I guess the only really interesting thing about this hardware is that it’s basically cloned from the SNK ‘P.O.W’ hardware, but with the added ability to have 256 colour sprites. We’re also quite lucky to have the PIC dump because a lot of these PCBs no doubt just ended up being scrapped due to how awful the game is. There are a number of other Korean games with PICs driving the sound where they couldn’t be dumped at the time and we haven’t since sourced another PCB now that we have the capability to dump them. (the Tumble Pop rip-off Pang Pang comes to mind)

Here is a video of Black Touch ’96 running in MAME with sound, you probably don’t actually want to watch it.

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

Well, unless you’ve been living under a rock you probably noticed the calendar switched over to 2018 a few days ago and might be wondering what this year has in store.

Skipping that for now, 2017 was actually a very busy year for MAME and over the past 5-6 months I’ve been periodically adding updates to the 2017 Write-up article that is linked over on the left. In the past week or two I put some extra effort into that because we were approaching the end of 2017 so it had reached the point where things were unlikely to change dramatically before the end of the year.

The article is still actually significantly lacking, such was the amount of progress made, but for now it covers most of the major announcements and some of the smaller bits of progress I found interesting too. Further content will be added over the course of the next couple of months, digging a bit deeper into the changes made over the year. The non-arcade parts of the article are still very much lacking, and as that’s one of my favourite areas of MAME (just one of the more difficult to always demonstrate) it is something I need to address.

Such was the level of progress in 2017 it’s actually quite difficult to know what 2018 will bring. There are definitely some things that were started in 2017, and have been highlighted in the article, that could be continued this year but it’s certainly going to be interesting to see what breakthroughs are ahead, I certainly couldn’t have predicted the Gaelco progress we saw over the course of 2017 for example.

My own plans, at the moment, aren’t actually that ambitious for 2018, I do want to improve the status of the GameKing (handheld) driver, even if it’s a terrible system, because at the moment a lot of the software list entries are marked as BAD_DUMP and it would be good if I can work with the people who dumped them to figure out the problems and maybe get better dumps. I’m also planning on revisiting the CPU core for the Hyper NeoGeo 64 I/O MCU, although it’s unlikely to improve the emulation of the system at this point (probably only make it slower) I’ve also purchased an LCD handheld from my childhood that I’m crossing my fingers is one that can be dumped and read out, although it’s unlikely I’ll be the one to work on that if it is because there’s already a very efficient and effective workflow in place for all of that.

I’m hoping somebody picks up the SH3/4 recompiler work I did earlier and figures out why Naomi has so many issues with it, I expect it’s something stupid I did because I really don’t have much experience of the recompiler framework, but it had reached the state where it was of huge benefit to the Cave SH3 titles so I felt it worth submitting anyway. Sometimes a bit of teamwork is needed to take things further in cases like this (much of the best progress in 2017 was the result of teamwork, including the aforementioned Gaelco and PGM2 work) so I’ll keep my fingers crossed that there is somebody willing to take what I’ve done and improve on it.

I might see if I can work with Peter to extract the uncompressed graphics from Decathlete so the protection/compression scheme on that can be studied because it bugs me that we have what looks like it should be a relatively simple Sega protection scheme not figured out. We might also end up studying the ‘Taito Nostaliga’ and ‘Namco Nostalgia’ units, because TV games like that are likely to be a big part of MAME’s future (as they typically represent things that MAME is capable of emulating well) As licensed (home use) products based on old arcade games they’re also kinda interesting from a MAME point of view as they follow a similar path to that MAME has taken in moving from being primarily an arcade emulator, to covering home systems.

The truth is most of the things people probably want me to look at aren’t going to get looked, although a lot of my recent work does depend on who comes forward to run hardware tests etc. to help with the process. A lot of the things that still need figuring out can’t be figured out without somebody else working with the actual hardware, again, teamwork. People simply telling me that I should be working on x, y or z doesn’t work because most of what’s left these days isn’t that simple.

I think 2018 is likely to be one of those years where there are more internal changes in MAME than ones that end-users will immediately notice. That said, with the way the project is organized these days, and the way it’s open for anybody to contribute, we might just see some complete surprises, especially when it comes to improvements for the non-arcade platforms because it seems the tickle-down effect is in full-swing now and more people than ever are seeing the potential MAME has. Even if that doesn’t happen, internal changes are never a bad thing as when they’re happening it often means people involved with the project are reflecting on how limitations of the current system are hindering our ability to emulate trickier edge cases etc. and looking for ways to tackle such things to make it easier in the future.

It would surprise me if we don’t see more Decap work over the course of 2018, and so depending on what does / doesn’t happen there (which is almost entirely beyond my control) I might find myself involved in working with their results (especially if we see movement on something like the Taito C-Chip, because I’ve already done plenty of research into that)

It has been good to see more people becoming involved with MAME, going against the recent disturbing trend of people keeping all the code locked away in closed source emulators and trying to charge for them. If anything I do expect some of the more significant pieces of progress next year to come out of the blue from surprise sources, people who have become involved with MAME / attracted to MAME due to the expanded scope of the project. There is always work to be done in MAME if you have the skills / knowledge, and MAME presents the opportunity to put a lot of different skills to good use.

The only real negative I can take from the last year is how the likes of Retroarch seem to be gaining popularity while offering a really bad MAME experience due to the rather unfortunate lowest-common denominator user-base target it has. I still struggle to find any positives in that model, it’s like having a really invasive front-end that ends up causing various features of the emulator to not even work properly, and even then the front-end isn’t even good if there’s a large amount of content or for any kind of special cases. I guess I hope that people start to realise that, and see that the emulators as the original authors present them usually offer a better experience, at least for anything that’s still being actively developed. It might be a ‘quick’ way to get started, but with emulation you get what you put in, and it’s also starting to become an annoying source of false bug reports. I also still think it’s damaging model in terms of emulation development, because people forget how important it is to develop high quality emulation cores that work for all cases because instead they’ve got something that just glues partial per-case implementations together, none of which are actually 100% correct. For the long term future of this hobby it’s important to develop high quality code that can be reused with ease, and such a model discourages that, it’s the opposite of MAME. I’d also say that a lot of the recent (and very impressive) work in MAME has been on areas that just seem to get stripped away, or become non-functional when you use such software, and I think a large part of the future of MAME is the software we have that surrounds the core emulation. Anyway, that’s enough of a rant about that, let’s look forward to what 2018 brings.

Peter and Morten dumped the internal ROM from Knights of Valour 3, the China / Taiwan / Hong Kong only installment in the series, and first game to make some significant changes to the gameplay formula.

Metallic bypassed an additional check the game makes for an FPGA on the ROM board, and I fixed up a few holes in our video emulation needed to make the game look correct (it runs at a higher resolution of 512×240 pixels) There are still some slightly odd looking visuals in some stages where the bottom row of background tiles is repeated, but I think that’s because those backgrounds were originally designed to run at 224 resolution and IGS were simply hoping nobody would notice.

Here is a video, I don’t play well here because I put the game on the hardest difficult in Service Mode. Video shows the save cards work fine in the MAME emulation anyway :-)

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

Here are some screenshots

Morten and Peter managed to dump the internal rom of Dodonpachi Daioujou Tamashii, a Chinese release of Dodonpachi Daioujou on PGM2 hardware that offers an ‘easy’ mode.

extracting this one was more difficult (I’ll update this post / do a new post explaining why later)

unfortunately for now it also appears to expose some more bugs in the MAME ARM core, these are being looked into, but basically a lot of the sprites end up with a value of ‘0’ for palette selection instead of the correct value causing them to be rendered with incorrect colours. There are no additional video attributes being set so it seems logical to conclude it’s a CPU emulation problem at this stage.

Yes, the service mode really renders at the wrong orientation, bit lazy considering they didn’t have a bios to worry about and all the code is on the game boards.

*edit* MetalliC traced down the ARM CPU core bug and fixed it, resulting in correct colours. This also potentially improves things in the GBA driver. This fix might not make 0.193 as it missed the deadline, so unless those in charge of the release decided that it’s important the 0.193 version will have broken colours shown above instead. *edit* Looks like the progress to fix the colours will be in 0.193, unless it gets backed out again at the last minute.

.. and a video of it running in MAME

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