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.
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.
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!
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.
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.
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...
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".
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.
Rest in power. The scene is not the same without him.
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
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.
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
When do you think we'll be able to ask an AI to recreate some nostalgia induced fantasy game in the 90s?
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.
Gotta catch ‘em all
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.
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
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.
Somehow I like the random unrelated ramblings about vintage movies and the author's trip to tokyo at the beginning.
That's rad yo!
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]