Amazing effort, but just makes me pine for the write-ups of Byuu (or the Dolphin devlog in more recent times).
I would highly recommend Shonumi's contemporary devlog focusing mainly on rare or difficult to emulate peripherals for the gameboy and GBA, ranging from infrared modems to Sonar-based fish detection dongles!
Byuu was fantastic - I remember when they came onto the scene and made a big push for better emulator compatibility across the board. Byuu made positive changes in the world, and I still think about them from time to time.
A lot of very talented individuals in the community but I always keep in mind the old saying: "the candle that burns twice as bright burns half as long".
Dolphin has some absolutely fascinating right ups on the lengths they had to go to in order to get Factor 5 games to run. When you're working with a fixed hardware set there are absolutely incredible things you can do to eke out extra performance that will go completely unappreciated until years later when somebody tries to run that software on a emulate hardware.
> I should mention that I was a huge Battle Network fan growing up with the GBA. I joined my first online community (GameWinners.com) specifically for the Mega Man forum.
> My first username (Team Shadow V2) was actually a riff on one of the new features found in MMBN2.
> In a way, Battle Network is a huge reason why I'm here trying to preserve old games.
> The Battle Network games will always hold memories of joy and nostalgia for me, so I wanted to see the Battle Chip Gates fully emulated not only for the benefit of video game history, but also for my own enjoyment.
Me too... MMBN2 is a big reason why I learned English and became a programmer. Huge respect.
I still love it so much. It's fun to think back on it and reflect on how oddly prescient it was.
PCs reachable directly from the internet, hosting home pages: a world without NAT. Internet connected doghouses and dishwashers. Mobile handheld AI capable personal computers. Everyone has their own custom AI agents that help navigate the complexity of the cyberworld, and also for self-defense. What I can only assume to be vulnerabilities, reified as literal weapons used by the AIs. Underworld networks normal people don't dare to navigate into. Cyber terrorists everywhere doing things like trying to burn people's houses down by electronically sabotating ovens, causing major damage and loss of life by hacking water mains, power grids, traffic signals, trying to nuke dams, actually hacking entire nations and genociding their AI populations, disrupting global environmental control systems, hacking autopilot systems in planes to bring them down like 9/11...
Pretty wild that MAME has been under active development for over 28 years with the core concept unchanged and no serious forks. It must have a very committed dev community.
A C++ codebase with bonus non-C++ code that generates C++ code plus a build-process-that-generates-build processes all with maniacal inter-dependencies and a guy who insists on renaming everything and moving all the files around in git-destroying ways twice a year does indeed create a bit of a monks-in-the-caves vibe.
Afaik gurudumps is a total jerk, constantly being hostile for no reason to newcomers.
Haze is almost always in conflict with mame lead Cuavas when trying to upstream his code, but his anger mostly justified.
Cuavas is a huge micromanager, he won't accept your code even if you just missed a typo in a line comment.
I respect his commitment to hold the codebase to absolute standards, but sometimes he takes his micromanagement too far that just makes the whole process unproductive.
The personalities working on this project are so hostile, usually without the skill to warrant it, that it's one of the few cases where having a CoC wouldn't be a horrible idea.
This reminds me that Linus Torvalds quote that the point of open source isn't just the right to fork but also the right to merge, and that's what justify copyleft
Mame is the most comprehensive emulator you'll ever get. They emulate everything under the sun: from very obscure computers that you don't even find info on the internet to mechanical car rides (yes they even preserve the roms for those).
Yeah, it's absolutely amazing and noble, especially for us that are into those things (Personally, I have a vast collection of consoles and games, including full SNES library etc.). Wikipedia, Internet Archive + Common Crawl, Emulation scene with now MAME at the forefront - those are Alexandria of our times.
There are actually a good numer of forks, but not sure if they qualify for your criteria of "serious" or not.
I also won't be naming any of them because those "committed" mame devs are very quick to inject themselves into any story about them, and harshly judge everything else that touches their code that didn't come from them.
I really love posts like this – and moreover it's clear that emulating games has spurred the development of really deep technical skills in more than one author.
I worry that the likes of the extremely difficult to crack, on-chip DRM found within e.g. the Xbox One X, designed at every available opportunity to resist hobbyists understanding and using the hardware, will show up as a big gap in museum exhibits in our cultural memory in the 2200s. DRM has a long tail, and we societally pay quite the underappreciated price for it, for sure.
There's a fair number of low game count systems where people are really enamored with one game. For example, I'm a big fan of T-Mek (I've got a machine with issues in my barn), but that system only has two games, so it waits for someone who is interested, determined, equipped, and skilled to figure out the protection to enable it to run properly in MAME.
Indeed. With most of the more well-known, higher volume arcade hardware platforms now pretty well emulated there are still a lot of lesser-known (but still quite interesting) systems unemulated. Various people have put effort into most of them but they can be challenging puzzles.
Habbo Origins wouldn't be around if it wasn't for tinkerers who figured out how to make an already compiled Habbo DCR run as a stand-alone desktop app, over a decade later. Which prompted a Sulake Employee to try it out. Said employee was originally part of the Habbo Retro / Emulator scene. ;)
Some arcade hardware is totally custom and only runs one game. Some chips are unique and only appear on one board. MAME's mission is clear, however SNK is a big enough name, along with Samurai Shodown and Fatal Fury, that the HNG64 was always going to get attention.
Even after 28 years, there continue to be a lot of interesting things happening across MAME - and it goes well beyond the arcade machines MAME is known for to lesser known home consoles, vintage computers and other hardware.
One example I'm excited about is the recent progress emulating professional music synthesizers like the legendary Yamaha MU-series (https://en.wikipedia.org/wiki/Yamaha_MU-series). These are significant not just to musicians but also gamers because in the late 80s PC games started supporting MIDI music soundtracks. Throughout the 90s, most PC gamers only heard these soundtracks through fairly primitive PC sound cards which had limited audio sample memory, bit rates and simultaneous voice counts. So we usually heard chintzy, partial renditions of the lush full soundtracks the game's composer originally created (many composers used external MIDI hardware).
If you were a hardcore gamer with serious money you got an external MIDI sound module like the Roland Sound Canvas which could elevate your favorite game's sound from chintzy to breathtakingly beautiful. However, the absolute best MIDI game hardware was the $699 64-voice Yamaha MU80. I heard one back in the day and it blew my mind what I'd been missing (MU80 Demo Song: https://www.youtube.com/watch?v=FwWxEN2NGHA). Now thanks to MAME I can have a full software emulation of this powerful, pricey professional hardware I could only lust for back then.
I remember the weird, pretty bad MIDI songs that shipped with my Packard Bell Pentium 166 (with MMX technology) and I didn't realize there were devices at that time that would have elevated them. A quick search on youtube shows this video comparing a Sound Blaster output with the MU80. Pretty cool!
Wow. That's a shocking difference and it's similar to what I remember from back then. There was some truly wonderful music composed for these games which only a lucky few players got to hear. That video shows the similar MU50 which was a cost-reduced MU80 that could play 16 different voices at once with 32 track polyphony. The MU80 did 32 different voices at once with 64 track polyphony, although a game's soundtrack would need to use the extra voices to make a difference.
Most of the MU series were backward compatible with the newer ones mostly adding more voices, polyphony, samples, effects and expansion options. Thanks to MAME we don't have to choose as we can have them all including 1999's MU128 which could play 64 different voices at once with 128 track polyphony.
A lot of game devs of that era sadly treated the Adlib/SoundBlaster OPL2 chip as nothing more than a very poor MIDI synth, but it was capable of much better. For example, listen to some of Stéphane Picq's music. https://vgmrips.net/packs/composer/stephane-picq
For sure. That the MU80 (or later) is the best way to hear MIDI game music from the 90s and early 2000s should take nothing away from the passionate musicians and coders who did brilliant (and sometimes unnatural) things to extract better results from the innately weaker hardware of early PC sound cards (Sound Blaster et al).
Yamaha's many various OPL chips were based on cost and feature reduced versions of the FM synthesis engine in Yamaha's professional standalone music synthesizers. These chips powered not only PC sound cards but also a huge variety of 80s and 90s arcade machines, game consoles and home computers (https://en.wikipedia.org/wiki/Yamaha_OPL).
It's fascinating to explore the evolution of the OPL technology as this "lower cost, lower end" alternative to pro gear gained in sophistication and power culminating in 1994's OPL4 chip (aka YMF278) and its even more capable cousin the YMF292 used in the Sega Saturn console. These chips had impressive synthesis power for their consumer console/sound card price point. By the late 90s onboard music synthesis in sound cards, consoles and arcade machines began dying due to increasing storage and CPU power permitting playback and mixing of fully sampled music tracks. By the early 2000s the only remaining consumer application of Yamaha's powerful onboard synthesis chips was for generating ringtones in mobile phones. It's kind of sad such a rich musical legacy ended up playing 5 second mono tracks on half-inch speakers (although those mobile phone chips probably made more money for Yamaha than all their pro music gear til that point combined).
Is this similar to what CAPCOM did with their arcade system with that weird battery thing? If it powered off you had to send it back to CAPCOM to get it re-programmed. It was a DRM method used to combat piracy in the early arcade days.
I don't see how it is, but maybe you're referring to something else. I think you're talking about the CPS, or more famously the CPS2, which had a battery power its anti-piracy measures. You only had to send it in if the battery dipped below a certain voltage, after which it would destroy the security key (in memory), so the ROMs would remain encrypted. You could turn off the machine just fine. Arcade machines were regularly powered off. This coupled with the fact that the CPS2 batteries especially are prone to leak over critical components dubbed them the suicide batteries. These security measures have since been defeated in a few ways, all while removing the troublesome battery. You can replaced the encrypted ROMs on your board with Phoenix ROMs, which are decypted. You can solder on a PCB called the Infinikey, which loads the decryption key with power from the board and not the battery. Maybe there are others, too.
I think the HNG64 just had obscure/undumped/not understood hardware.
The many-year effort to finally break the CPS2 hardware protection is a fascinating story. It was huge not only for the preservation of some well-known, historically significant games but it also allowed a lot of dead vintage arcade boards to be resurrected for new generations to enjoy.
They had a proprietary decryptor chip that sat between the program roms and the CPU. The decryptor used a table held in a small SRAM that was powered by a battery. When the SRAM lost power (battery died, or someone was trying to reverse engineer the board), the decryption key would be lost.
We broke it because someone noticed that the FC1 pin was tied to the drcyptor chip. In retrospect this made sense because only the program roms were encrypted, not the gfx roms (FC1 and FC0 pins were 01 for data access and 10 for program access [1]). Whenever the 68000 was requesting an instruction, it would set FC0 low and FC1 high, and when requesting data it would be opposite - this is how the decryptor knew when to decrypt.
But there was an achilles heel!
If you use PC-relative addressing, this ALSO causes FC0 low and FC1 high (because PC-relative is assumed to be accessing more program code). So all you had to do was fetch each address using PC-relative MOVEs, and it would happily give you the decrypted instruction words.
But then there was a secondary protection scheme: The decryptor chip would mysteriously shut down after a short while! WTF!
It wasn't until Capcom released their home console based off the original CPS board, along with backports of games like Street Fighter Zero, that the penny dropped. These backports were full of mysterious reads of weird addresses that made no sense.
It turns out that these weird addresses were what the decryptor chip was waiting for on the address bus. If no such address appeared within a timeout period, the chip would stop decrypting until you reset.
But the guys backporting CPS2 games didn't take the instructions doing these accesses out - even though the original CPS board didn't need it (probably it would have been a lot of work), so that secret leaked out.
After that, it was a simple matter of writing a program that read via PC-relative addresses, sent those weird accesses from time to time to keep the watchdog happy, and then output to a dumper via IO pins.
[1] Section 3.8: PROCESSOR FUNCTION CODES (FC0, FC1, FC2)
The 68k was unique in that it included in its design the ability to act as a Harvard Architecture processor (where instructions and data have separate signal pathways rather than being together in the same address space [1])
It did this via the function code pins, which signaled differently depending on whether the chip was requesting instructions or data, in supervisor or user mode. No other consumer-grade chip had this as far as I know.
Sega's System 16 was also 68000 based (as was the Megadrive/Genesis), but I don't know anything about their protection scheme.
No other consumer-grade chip had this as far as I know.
The 8086/88 has status outputs which provide similar information, including which segment register is being used (CS, DS, ES, SS) and the type of bus cycle (interrupt acknowledge, read I/O, write I/O, halt, opcode fetch, read data, write data).
The 65816 has valid data address (vda) and valid program address (vpa) pins which are essentially the same as fc0/1/2 , minus the supervisor/user mode support.
vda vpa
0 0 internal operation, address bus may be invalid
0 1 valid program address, may be used for program cache control
1 0 valid data address, may be used for data cache control
1 1 opcode fetch, may be for program cache control and single step control
That shit is something you still find in the gambling world. Many of the modern one-armed bandits have HSMs with a loooot of protections, including batteries with drill through protections and god knows what else, although it's less used for anti-piracy but more to prevent tax fraud.
Not many knew they existed! They are sought after by collectors, and fetch a pretty penny. At least they were when I was getting into PC Engine/TurboGrafx gear ~15 years ago. I'm sure it's even more now.
They're founded later than Data East, but also Japanese. They don't appear to be any sort of spinoff of Data East or anything, but I have to wonder if with the name they were hoping to confuse people somewhat into thinking they were Data East, or to ride on their reputation...
It would be great if they finally cracked the >100 ms delay between a keypress and game response. Immediately visible in Galaga and Galaga with fast shoot.
Amazing effort, but just makes me pine for the write-ups of Byuu (or the Dolphin devlog in more recent times).
I would highly recommend Shonumi's contemporary devlog focusing mainly on rare or difficult to emulate peripherals for the gameboy and GBA, ranging from infrared modems to Sonar-based fish detection dongles!
https://shonumi.github.io/articles.html
Byuu was fantastic - I remember when they came onto the scene and made a big push for better emulator compatibility across the board. Byuu made positive changes in the world, and I still think about them from time to time.
A lot of very talented individuals in the community but I always keep in mind the old saying: "the candle that burns twice as bright burns half as long".
Byuu was the victim of sustained and targetted online abuse so I'm not sure that saying really applies here.
Dolphin has some absolutely fascinating right ups on the lengths they had to go to in order to get Factor 5 games to run. When you're working with a fixed hardware set there are absolutely incredible things you can do to eke out extra performance that will go completely unappreciated until years later when somebody tries to run that software on a emulate hardware.
Does anyone know a PC emulator that properly allows mic input via Soundblaster emulation?
I managed to find my first published app on archive.org from like 1994, but it's a music visualizer and requires audio input.
Rest in power. The scene is not the same without him.
https://shonumi.github.io/articles/art16.html
Wow, that brings back childhood memories.
> I should mention that I was a huge Battle Network fan growing up with the GBA. I joined my first online community (GameWinners.com) specifically for the Mega Man forum.
> My first username (Team Shadow V2) was actually a riff on one of the new features found in MMBN2.
> In a way, Battle Network is a huge reason why I'm here trying to preserve old games.
> The Battle Network games will always hold memories of joy and nostalgia for me, so I wanted to see the Battle Chip Gates fully emulated not only for the benefit of video game history, but also for my own enjoyment.
Me too... MMBN2 is a big reason why I learned English and became a programmer. Huge respect.
I still love it so much. It's fun to think back on it and reflect on how oddly prescient it was.
PCs reachable directly from the internet, hosting home pages: a world without NAT. Internet connected doghouses and dishwashers. Mobile handheld AI capable personal computers. Everyone has their own custom AI agents that help navigate the complexity of the cyberworld, and also for self-defense. What I can only assume to be vulnerabilities, reified as literal weapons used by the AIs. Underworld networks normal people don't dare to navigate into. Cyber terrorists everywhere doing things like trying to burn people's houses down by electronically sabotating ovens, causing major damage and loss of life by hacking water mains, power grids, traffic signals, trying to nuke dams, actually hacking entire nations and genociding their AI populations, disrupting global environmental control systems, hacking autopilot systems in planes to bring them down like 9/11...
Pretty wild that MAME has been under active development for over 28 years with the core concept unchanged and no serious forks. It must have a very committed dev community.
A C++ codebase with bonus non-C++ code that generates C++ code plus a build-process-that-generates-build processes all with maniacal inter-dependencies and a guy who insists on renaming everything and moving all the files around in git-destroying ways twice a year does indeed create a bit of a monks-in-the-caves vibe.
interrogations on motives for building from source
constant slap fights between contributors (usually involving haze or guru)
important PRs left ignored due to internal drama
8GB+ memory leak during building that they're in no rush to fix
Afaik gurudumps is a total jerk, constantly being hostile for no reason to newcomers.
Haze is almost always in conflict with mame lead Cuavas when trying to upstream his code, but his anger mostly justified.
Cuavas is a huge micromanager, he won't accept your code even if you just missed a typo in a line comment.
I respect his commitment to hold the codebase to absolute standards, but sometimes he takes his micromanagement too far that just makes the whole process unproductive.
The personalities working on this project are so hostile, usually without the skill to warrant it, that it's one of the few cases where having a CoC wouldn't be a horrible idea.
A benevolent dictator then
Not exactly a fork but there was a separate MESS, for a time, expanding the scope to non-arcade systems, until it was reenfolded.
This reminds me that Linus Torvalds quote that the point of open source isn't just the right to fork but also the right to merge, and that's what justify copyleft
I feel like every one of my repos is a separate mess.
advmame/advmess too.
> no serious forks
What about Final Burn Alpha/Neo? They're extremely popular.
Especially on rpi
What I find absolutely wild and found out by accident is that it also emulates SGI / IRIX
Thanks for pointing this out!
Mame is the most comprehensive emulator you'll ever get. They emulate everything under the sun: from very obscure computers that you don't even find info on the internet to mechanical car rides (yes they even preserve the roms for those).
Yeah, it's absolutely amazing and noble, especially for us that are into those things (Personally, I have a vast collection of consoles and games, including full SNES library etc.). Wikipedia, Internet Archive + Common Crawl, Emulation scene with now MAME at the forefront - those are Alexandria of our times.
There are actually a good numer of forks, but not sure if they qualify for your criteria of "serious" or not.
I also won't be naming any of them because those "committed" mame devs are very quick to inject themselves into any story about them, and harshly judge everything else that touches their code that didn't come from them.
This is absolutely so on brand.
Has its pros and cons, of course.
I really love posts like this – and moreover it's clear that emulating games has spurred the development of really deep technical skills in more than one author.
I worry that the likes of the extremely difficult to crack, on-chip DRM found within e.g. the Xbox One X, designed at every available opportunity to resist hobbyists understanding and using the hardware, will show up as a big gap in museum exhibits in our cultural memory in the 2200s. DRM has a long tail, and we societally pay quite the underappreciated price for it, for sure.
All that work for less than 10 games available on this console, emulation developers are really determined
There's a fair number of low game count systems where people are really enamored with one game. For example, I'm a big fan of T-Mek (I've got a machine with issues in my barn), but that system only has two games, so it waits for someone who is interested, determined, equipped, and skilled to figure out the protection to enable it to run properly in MAME.
Indeed. With most of the more well-known, higher volume arcade hardware platforms now pretty well emulated there are still a lot of lesser-known (but still quite interesting) systems unemulated. Various people have put effort into most of them but they can be challenging puzzles.
Habbo Origins wouldn't be around if it wasn't for tinkerers who figured out how to make an already compiled Habbo DCR run as a stand-alone desktop app, over a decade later. Which prompted a Sulake Employee to try it out. Said employee was originally part of the Habbo Retro / Emulator scene. ;)
The Reverse Engineering scene is quite a scene.
Some arcade hardware is totally custom and only runs one game. Some chips are unique and only appear on one board. MAME's mission is clear, however SNK is a big enough name, along with Samurai Shodown and Fatal Fury, that the HNG64 was always going to get attention.
I think the word you are looking for is passionate.
Archiving the past is a noble endeavor.
Gotta catch ‘em all
Even after 28 years, there continue to be a lot of interesting things happening across MAME - and it goes well beyond the arcade machines MAME is known for to lesser known home consoles, vintage computers and other hardware.
One example I'm excited about is the recent progress emulating professional music synthesizers like the legendary Yamaha MU-series (https://en.wikipedia.org/wiki/Yamaha_MU-series). These are significant not just to musicians but also gamers because in the late 80s PC games started supporting MIDI music soundtracks. Throughout the 90s, most PC gamers only heard these soundtracks through fairly primitive PC sound cards which had limited audio sample memory, bit rates and simultaneous voice counts. So we usually heard chintzy, partial renditions of the lush full soundtracks the game's composer originally created (many composers used external MIDI hardware).
If you were a hardcore gamer with serious money you got an external MIDI sound module like the Roland Sound Canvas which could elevate your favorite game's sound from chintzy to breathtakingly beautiful. However, the absolute best MIDI game hardware was the $699 64-voice Yamaha MU80. I heard one back in the day and it blew my mind what I'd been missing (MU80 Demo Song: https://www.youtube.com/watch?v=FwWxEN2NGHA). Now thanks to MAME I can have a full software emulation of this powerful, pricey professional hardware I could only lust for back then.
I remember the weird, pretty bad MIDI songs that shipped with my Packard Bell Pentium 166 (with MMX technology) and I didn't realize there were devices at that time that would have elevated them. A quick search on youtube shows this video comparing a Sound Blaster output with the MU80. Pretty cool!
https://www.youtube.com/watch?v=C33-YCX7Too
Wow. That's a shocking difference and it's similar to what I remember from back then. There was some truly wonderful music composed for these games which only a lucky few players got to hear. That video shows the similar MU50 which was a cost-reduced MU80 that could play 16 different voices at once with 32 track polyphony. The MU80 did 32 different voices at once with 64 track polyphony, although a game's soundtrack would need to use the extra voices to make a difference.
Most of the MU series were backward compatible with the newer ones mostly adding more voices, polyphony, samples, effects and expansion options. Thanks to MAME we don't have to choose as we can have them all including 1999's MU128 which could play 64 different voices at once with 128 track polyphony.
A lot of game devs of that era sadly treated the Adlib/SoundBlaster OPL2 chip as nothing more than a very poor MIDI synth, but it was capable of much better. For example, listen to some of Stéphane Picq's music. https://vgmrips.net/packs/composer/stephane-picq
For sure. That the MU80 (or later) is the best way to hear MIDI game music from the 90s and early 2000s should take nothing away from the passionate musicians and coders who did brilliant (and sometimes unnatural) things to extract better results from the innately weaker hardware of early PC sound cards (Sound Blaster et al).
Yamaha's many various OPL chips were based on cost and feature reduced versions of the FM synthesis engine in Yamaha's professional standalone music synthesizers. These chips powered not only PC sound cards but also a huge variety of 80s and 90s arcade machines, game consoles and home computers (https://en.wikipedia.org/wiki/Yamaha_OPL).
It's fascinating to explore the evolution of the OPL technology as this "lower cost, lower end" alternative to pro gear gained in sophistication and power culminating in 1994's OPL4 chip (aka YMF278) and its even more capable cousin the YMF292 used in the Sega Saturn console. These chips had impressive synthesis power for their consumer console/sound card price point. By the late 90s onboard music synthesis in sound cards, consoles and arcade machines began dying due to increasing storage and CPU power permitting playback and mixing of fully sampled music tracks. By the early 2000s the only remaining consumer application of Yamaha's powerful onboard synthesis chips was for generating ringtones in mobile phones. It's kind of sad such a rich musical legacy ended up playing 5 second mono tracks on half-inch speakers (although those mobile phone chips probably made more money for Yamaha than all their pro music gear til that point combined).
Here are two good links from my retro research bookmarks: The best rundown on the genealogy and capabilities of Yamaha's FM sound chips I've seen: https://gist.github.com/bryc/e85315f758ff3eced19d2d4fdeef01c.... And a collection of very impressive OPL4 music tracks: https://www.youtube.com/watch?v=zqD52xioky4.
When do you think we'll be able to ask an AI to recreate some nostalgia induced fantasy game in the 90s?
Is this similar to what CAPCOM did with their arcade system with that weird battery thing? If it powered off you had to send it back to CAPCOM to get it re-programmed. It was a DRM method used to combat piracy in the early arcade days.
I don't see how it is, but maybe you're referring to something else. I think you're talking about the CPS, or more famously the CPS2, which had a battery power its anti-piracy measures. You only had to send it in if the battery dipped below a certain voltage, after which it would destroy the security key (in memory), so the ROMs would remain encrypted. You could turn off the machine just fine. Arcade machines were regularly powered off. This coupled with the fact that the CPS2 batteries especially are prone to leak over critical components dubbed them the suicide batteries. These security measures have since been defeated in a few ways, all while removing the troublesome battery. You can replaced the encrypted ROMs on your board with Phoenix ROMs, which are decypted. You can solder on a PCB called the Infinikey, which loads the decryption key with power from the board and not the battery. Maybe there are others, too.
I think the HNG64 just had obscure/undumped/not understood hardware.
The many-year effort to finally break the CPS2 hardware protection is a fascinating story. It was huge not only for the preservation of some well-known, historically significant games but it also allowed a lot of dead vintage arcade boards to be resurrected for new generations to enjoy.
I would love to see a write up of the CPS2 cryptography and how it was cracked; my understanding it was some custom Feistel cipher.
Yes, it was a 2-part scheme:
They had a proprietary decryptor chip that sat between the program roms and the CPU. The decryptor used a table held in a small SRAM that was powered by a battery. When the SRAM lost power (battery died, or someone was trying to reverse engineer the board), the decryption key would be lost.
We broke it because someone noticed that the FC1 pin was tied to the drcyptor chip. In retrospect this made sense because only the program roms were encrypted, not the gfx roms (FC1 and FC0 pins were 01 for data access and 10 for program access [1]). Whenever the 68000 was requesting an instruction, it would set FC0 low and FC1 high, and when requesting data it would be opposite - this is how the decryptor knew when to decrypt.
But there was an achilles heel!
If you use PC-relative addressing, this ALSO causes FC0 low and FC1 high (because PC-relative is assumed to be accessing more program code). So all you had to do was fetch each address using PC-relative MOVEs, and it would happily give you the decrypted instruction words.
But then there was a secondary protection scheme: The decryptor chip would mysteriously shut down after a short while! WTF!
It wasn't until Capcom released their home console based off the original CPS board, along with backports of games like Street Fighter Zero, that the penny dropped. These backports were full of mysterious reads of weird addresses that made no sense.
It turns out that these weird addresses were what the decryptor chip was waiting for on the address bus. If no such address appeared within a timeout period, the chip would stop decrypting until you reset.
But the guys backporting CPS2 games didn't take the instructions doing these accesses out - even though the original CPS board didn't need it (probably it would have been a lot of work), so that secret leaked out.
After that, it was a simple matter of writing a program that read via PC-relative addresses, sent those weird accesses from time to time to keep the watchdog happy, and then output to a dumper via IO pins.
[1] Section 3.8: PROCESSOR FUNCTION CODES (FC0, FC1, FC2)
https://www.nxp.com/docs/en/reference-manual/MC68000UM.pdf
> The decryptor used a table held in a small SRAM that was powered by a battery.
IIRC Sega’s System 16 did something similar. Was that board’s encryption cracked in the same way?
Was this style of anti-piracy measure widely used at the time, or was it only on a few 68000-based systems?
The 68k was unique in that it included in its design the ability to act as a Harvard Architecture processor (where instructions and data have separate signal pathways rather than being together in the same address space [1])
It did this via the function code pins, which signaled differently depending on whether the chip was requesting instructions or data, in supervisor or user mode. No other consumer-grade chip had this as far as I know.
Sega's System 16 was also 68000 based (as was the Megadrive/Genesis), but I don't know anything about their protection scheme.
[1] https://en.wikipedia.org/wiki/Harvard_architecture
No other consumer-grade chip had this as far as I know.
The 8086/88 has status outputs which provide similar information, including which segment register is being used (CS, DS, ES, SS) and the type of bus cycle (interrupt acknowledge, read I/O, write I/O, halt, opcode fetch, read data, write data).
The 65816 has valid data address (vda) and valid program address (vpa) pins which are essentially the same as fc0/1/2 , minus the supervisor/user mode support.
Great explanation. The address bus reminds me of port knocking.
That shit is something you still find in the gambling world. Many of the modern one-armed bandits have HSMs with a loooot of protections, including batteries with drill through protections and god knows what else, although it's less used for anti-piracy but more to prevent tax fraud.
It's to prevent cheating! If the roms weren't cryptographically signed, people would "homebrew" their own "mods" lol.
Article mentions LaserActive. I remember going to my uncles house as a kid where he had one and I had no idea it existed https://en.wikipedia.org/wiki/LaserActive
Pretty sure I just used it to play genesis games
Not many knew they existed! They are sought after by collectors, and fetch a pretty penny. At least they were when I was getting into PC Engine/TurboGrafx gear ~15 years ago. I'm sure it's even more now.
> Vajra and Vajra 2 - A pair of LaserActive-exclusive rail shooters by Data West
Wait, Data West? Apparently there was indeed such a company: https://www.mobygames.com/company/6613/data-west/
They're founded later than Data East, but also Japanese. They don't appear to be any sort of spinoff of Data East or anything, but I have to wonder if with the name they were hoping to confuse people somewhat into thinking they were Data East, or to ride on their reputation...
I felt the urge to zoom into the first picture and look at the price tags:
- Battle Toad in Battlemaniac (Battletoads in Battlemaniacs) = 53900 JPY.
- Akumajou Dracula XX (Castlevania: Vampire's Kiss) = 27500 JPY.
- The King of Dragons = 39800 JPY.
It would be great if they finally cracked the >100 ms delay between a keypress and game response. Immediately visible in Galaga and Galaga with fast shoot.
That's rad yo!
Somehow I like the random unrelated ramblings about vintage movies and the author's trip to tokyo at the beginning.
Cool. But this writing style of intentionally not getting to the fucking point is very good for getting pesky visitors on to other websites.
The recipe site meta is spreading
it's one part of a newsletter.
And the pictures section is longer than the actual intro section.
[dead]