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!
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.
Me too... MMBN2 is a big reason why I learned English and became a programmer. I still love it so much.
> 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.
Huge respect.
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
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.
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.
Has its pros and cons, of course.
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.
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.
The Reverse Engineering scene is quite a scene.
I think the HNG64 just had obscure/undumped/not understood hardware.
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)
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?
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.
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 controlPretty sure I just used it to play genesis games
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...
- Battle Toad in Battlemaniac (Battletoads in Battlemaniacs) = 53900 JPY.
- Akumajou Dracula XX (Castlevania: Vampire's Kiss) = 27500 JPY.
- The King of Dragons = 39800 JPY.