I accidentally deleted a bad game revision from MAME
mistys-internet.website
mistys-internet.website
My people. I only aspire to be this damn clever. It's why I surround myself by people smarter than me.
For anyone else:
The lid of the PS had a small protusion which pressed down a button when the lid closed. The game could not be started with the lid open. So a piece of blu-tac was used to depress that button.
The first thing the PS did when loading a game was to check somewhere on the game disc for some code. This code confirmed the disc was genuine so the trick was to put any genuine game in the drive, use the blu-tac, start the console and at a certain point, after the code had been read but before the game loaded and at that point pull the genuine disc and insert the pirate disc you had.
Confused... so you'd pull out a spinning CD? And the insert one while the spindle was still spinning? And you'd do this safely, and fast enough that the game wouldn't have time to start reading the disc contents before the swap? And you'd do this every single time you're trying to play the game?
This sounds pretty impossible to pull off without hurting yourself and damaging everything... what am I missing?
Look up for example Philips SBC444A test CD for the kind of things CD players were required to handle for certification.
It can nevertheless be true that the CDs were failing all the time. So robust error correction is real to achieve the degree of functionality that we did enjoy during the heyday of CDs, and despite this, the fragility of CDs as an information medium meant that they were still disappointing us.
The PSX's 2x drive can spin, at most, at about 1,000 RPM. There just isn't much momentum (kinetic energy) there. And IIRC, the wobble-track detection happened at 1x (or a maximum of about 500RPM).
There was nothing particularly iffy about the hit-swapping with PSX's CD-ROM. It could have, at most, less than 0.2 Joules of stored kinetic energy. You can just put your finger on it and stop it with no particular danger.
The PC drives, meanwhile, generally topped out at around 8,000RPM.
That's getting into the realm of scary, with something in the realm of 64x the kinetic energy -- which is more energy than a rather competent air rifle might provide.
(Beyond 8,000RPM, CDs often had disintegration issues, and exploding CD-ROMs were also sometimes reported at somewhat slower speeds. But at 500 or 1,000 RPM? Nah. It's a really boring amount of kinetic energy.)
I'm not sure on the why? But the tray eventually would eject with the CD still spinning? Bad braking system?
You could hear the drive go nuts and speed up to weird speeds and one day a disc exploded inside.
Remember the warnings about not inserting X format discs into Y drives.
Does anyone know why this happens?
I think the 72x drives were really just another example of "big number marketing" that was even more prevalent in desktop PCs back then than it is now.
Kenwood did have drives (which others also sold derivatives of) that would, ideally, do 72x at peak. That was a thing.
They did this by cheating: They would read more than one track from the CD-ROM, concurrently, and in parallel. This is a proper hack, and it worked: It could read a CD at a faster rate, with a slower rotational speed, than many other drives.
I never owned a drive that used the Kenwood method. (I never wanted one; my ideas for high-speed CD reading centered around getting good reads from audio CDs, which was still hairy around that time.)
More-common "52x" (or more) drives just spun the fuck out of the CD. Mu circa-1997 girlfriend had one of those drives in her desktop tower PC, and it always sounded like it was going to disassemble the whole PC when it managed to get spun fully up.
But they never really exceeded 8k RPM. It was just a difference of read methods.
There was CAV, CLV, partial CAV, and other methods -- both for reading, and writing. In reader-space, the documentation wasn't always complete in describing the methods -- it became universal that "faster is better".
My own peak CD-ROM time happened with a Plextor PR-820 burner and a "24x" Plextor reader, both connected with parallel SCSI.
It was very fast for the time, but I was never successful with direct high-speed disc-to-disc copies with this rig. Even with IBM UltraStar 9ES ultra-wide SCSI disks and plenty of RAM, and plenty of time for tweaking -- I just couldn't a a reliable copy possible. (And all of my reported-successful burns were proper, and that was important to me.)
So I rolled on with this rig for a couple of years, when a friend brought over a new pile of PC parts to have me assemble.
And I did assemble the things, and then we did the requisite copying of the Windows CD.
He wanted to copy it at max speed. I was sure it would fail.
Except: He had a fast reader (>32x), and a "32x" burner (which isn't really a thing), and... We put the source disc in the source drive, and the blank disc in the target drive, and it just fuckin' worked. I timed it, and it took 2 minutes and 43 seconds. Both drives spun up like jet engines, and the progress bar just spooled across the screen without a pause in Nero Burning ROM.
It was amazing to observe. And it probably did not exceed 8k RPM on either drive, despite the necessary read/write rates.
(That was early in 2002, as a reference.)
When authenticating it slows down considerably then displays the PS logo screen. You would watch it slow down then speed up then slow down (happens for a few seconds) and you'd simply grab the disc and replace it.
Once PCs with writable CD drives became more affordable the catalogue became less relevant and you’d just rent titles from Blockbusters and copy them instead.
By the time the Xbox 360 and PS3 were out, the pre-owned market was strong enough that you could buy a game on release and trade-it in at practically no loss once you were done.
I got the idea from a great book "Security Engineering" which IIRC mentioned some people in Africa doing the same trick with electricity cards or something. Might have misremembered.
That book had a foreword saying something to the effect of "Should this book be written? Some say people will use it for nefarious purposes, however..."
Sorry authors, I used it for nefarious purposes. :D
I'm not exactly sure why that checksum exists, the console doesn't check it, and in manufacturing you could just read and compare. But it's certainly convenient for verifying a good dump.
specifically
> Because the ROM header will be part of the computed checksum, before computing the checksum we should first fill the header's checksum and complement values with $0000 and $FFFF. Any value plus its complement will produce the same result, so this ensures the resulting checksum matches the ROM even after the computed checksum is replaced in the header.
I know that's how the option ROM checksums on PC BIOSes work.
Fwiw I think they were used for automated cartridge testing, since they all used varying memory bank controllers, so the hardware checking the ROM needs to know which MBC it's talking to.
i was waiting in suspense for the author to make a mistake and was so relieved when i saw they did not. when they were talking about the socket i was thinking "oh no, they must have cracked something"...
Edit: I changed it to "I accidentally deleted a bad game revision from MAME" for now - is that accurate enough?
Or “I found a bad dump in MAME and corrected it”
What about "Adventures in MAME ROM dumping and games preservation"? It's the one that might stand the test of time to be useful for posterity.
'Unexpectedly' would be a little more accurate I think. Or just 'That time I deleted a game from MAME'.
It is also good to go re-checking things. As new dumps show up sometimes. The problem people are starting to see though is MAME is see as a 'golden copy' and people are using it to make fixes/changes to real board. Then those boards end back up in the hands of people doing dumping and it becomes unsure if it is a verified dump or something else. Or people see the game in the list and say 'good enough' but it is actually a revision of the game. There is a whole site dedicated to that (not sure how up to date it is) unmamed.
No, it sounds like it was a bad dump. This writer found that they were able to get a different bad dump from the same game, but then when they ensured good contact with the reader, they managed to get a good dump that was a duplicate of another rom.
It seems that for this arcade system, the roms for Taiwan and Mainland China are usually the same, with some system board setting? triggering use of Traditional vs Simplified writing, but when the taiwainese packaged game was dumped with errors, it didn't match; when dumped properly, it does match the mainland rom.
https://www.youtube.com/watch?v=objL2hGAEgU
Living in L.A. in the 90's, I remember Pack Mann in Pasadena had this one.
http://www.arcaderestoration.com/games/3330/Gals+Panic+II.as...
The ROM dump's been done but people seem to be stuck on the RLE encoding. It's hard to say what kind of wizardry is needed in this case.
Years ago I made a similar interposer and it took me a few hours in kicad. Had 20 of them fabricated by futurlec for a few bucks each.
Longer answer: Every MAME update changes things, which includes adding, removing, and changing the definition of ROMs. Due especially to the nature of arcade games, there aren't convenient de facto wrapper formats (like, say, .nes or .sfc files), and MAME just defines each independent ROM as their own files, with MAME's own idea of what the names should be and accompanying sha1 hashes. If MAME developers/contributors have discovered that a game revision previously dumped was incorrect (as is the case in TFA), it might be replaced with a known good dump. In that case, you are expected to redump the game from your arcade board, this time the right way (or well, pirate the game, which most MAME users do...).
It may seem annoying, but it's the nature of game preservation. It'll never be in a perfected and finished state.
To be fair, no ROMs are "built for MAME", just that MAME's database changes.
The denominator here is 14,566 so that's 0.6% to 1.1% per month which is substantially less than all. These would mostly be ROMs for machines that weren't previously supported, replacing high level emulation with low level emulation, new ROM dumps, and replacing bad dumps.
They aren't quite versioned like on mame, but if you don't use their special checksummed ROMs they will run, but try telling you that you have a bad dump... only problem is that most NES ROMs have bad headers altogether.
(I've seen a lot that say they have 8k of battery-backed SRAM when they infact don't. I wound up spending a week rewriting the headers on my ROMs from scratch, referencing the pcb pictures online. Edit: this also includes bad Disk Dude overdumps that still haven't been fixed ~40 years later...)