> I ultimately tricked it by inserting a real 27C322 first and reading that before swapping over to the chip I actually wanted to read. Once the reader’s recognized at least one chip, it seems happy to stick in 27C322 mode persistently.
My people. I only aspire to be this damn clever. It's why I surround myself by people smarter than me.
I did this to get free laundry in uni. It read the balance from your card and then wrote the new balance. I discovered you could swap cards at the right point and write the new balance to any card, thus getting free money.
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
Ah yes - a piece of blu-tac and timing the swap just right.
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.
It’s been ages so I don’t recall the exact details but you could pull a similar trick with the PS2 version of Guitar Hero to play custom songs on an unmodded console. You would burn a copy of the game with custom songs, insert and start a legit copy of the game, and then physically pull open the DVD tray and quickly replace the legit copy with the burned DVD at a specific time between when the PS2 had authenticated the disc as legit but before the game had actually loaded. It was a little finicky but with some practice it would work like 2/3rds of the time.
You could use a similar method to play burned PS2 disks using a Datel (of Action Replay fame) "Swap Magic" disc and a card to pull the tray out. the Swap disk appeared as a genuine PS2 disk with bad sectors, which would cause the drive motor to stop and give some time for the swap to occur.
I got a dongle that plugged into the back and let me enter cheats, Action Replay style. It also happened to stop the CD spinning after it'd been confirmed as legitimate - swap at your leisure then press X to continue.
Getting your PlayStation chipped in the UK was like a working class rite of passage. You’d hand it over to some bloke and get it back a few days later, along with a printed spreadsheet of pirated games you could get.
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.
> 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?
The PSX's CD-ROM drive was a pretty sleepy thing compared to the screamers that came at peak CD-ROM in the PC space.
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 remember swapping back to a yellowed 24x drive from a newer 72x back in the day. The 72x could copy large files faster but the time it took to spin up meant if I was reading an single file (like with a games CD check) the latency was horrible and it sounded like a jet engine while doing it. The 24x was much quieter and quicker to spin up. Honestly, even moderate file transfers didn't seem any faster once you accounted for the spin up to me but that just a feeling. I imagine the teeth chattering sound biased me against that drive.
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.
The warnings about not inserting X format discs into Y drives were usually about not inserting non-circular discs (or sometimes mini-CDs) into slot-loading drives.
You're severely underestimating the robustness of CD systems. They were fully made with the assumption that a spinning unstable plastic disc continually handled by humans would go wrong often.
Look up for example Philips SBC444A test CD for the kind of things CD players were required to handle for certification.
This seems like the complete opposite of my experience for CDs. I've had so many CDs go bad on me without any mishandling or visible damage. DVDs were more like what you're saying.
Both can be true. I take the parent commenter to be talking about reading data off of the CD in a way that accounts for the irregularities from inconsistent spinning speeds, (I distinctly recall a friend pulling a CD out of the CD player and placing it back in to resume spinning, while a song was playing without any break in the song). Perhaps, additionally, the was some degree of accounting for resilience to things like blemishes and fingerprints.
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.
And CDs had the data on the metal film on top of the disc, while DVDs sandwiched it between plastic layers. It is much easier to damage a CD. Short of breaking it in pieces, almost any damage to a DVD can be buffed out.
Yes. You may damage things if not careful but the PS1 disc has obvious feedback when the lid is open while reading the disc.
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.
I used to do this CD swap as a kid - you wouldn't touch the CD - you would put your finger on the mount that you clip the CD onto, and then when it had stopped, pop the CD off.
Most people I knew used the ink tube of a ballpoint pen, as it could be held in place with the lid of the console. You knew who pirated games, because the lid of their console had ink stains all over the inside..
it was the wobble line on the inner circumference. that could not be reproduced by burners. problem was it checked for that, then allowed the rest of the disc to be read. that was the window in which you could put on your jolly roger hat and laugh.
SNES ROMs have a checksum right in the header, but there were still bad dumps circulating for years. Presumably they escaped before the header was properly reverse engineered.
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.
Most systems/formats/protocols were not robust against data corruption ca. 1990, so it might have been to detect corruption of the master copy in transit to the factory (whether that be via floppy, tape, EPROM, modem, etc.).
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.
It's pretty hard to calculate that checksum if you're writing homebrew, since the checksum is written to the rom file, which changes the checksum again...
> 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.
A hobbyist working on new software for the TRS-80/Tandy Color Computer recently realized that video emulation had a timing issue that caused the aspect ratio to be wrong and broke some clever techniques used to display more colors than supported. Apparently, no one noticed before or cared. I always thought it looked a bit off but assumed it was my wetware memory that was wrong.
Good timing for a MAME story as v 0.263 was just released a couple days ago. Lots of good fixes as usual but not as big as last month's release that added a number of LaserDisc games like Dragon's Lair.
Yup... but the headline is still very clickbaity! In the end it turns out they didn't delete a game, they deduplicated it (i.e. deleted a game that was listed as a separate version, but was actually identical to the original), and they didn't do it accidentally, but on purpose.
without any experience in emulation or software preservation i still really enjoyed the post.
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"...
In this case it looks like it was marked bad dump. But really a good dump but something else was wrong. It is why they keep bad dumps in there. Sometimes it is a resistor on the board tagging something in the code. I have one device that I do not think is in MAME yet. It has 4 games inside it. But it is sold as 4 different units and they just change the board config to make it boot different games. But the binary is the same on all 4 units.
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.
> In this case it looks like it was marked bad dump. But really a good dump but something else was wrong.
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.
I'm presuming the title refers to the bad dump of the "Taiwan romset" being deleted from the MAME database, since the good dump is a dupe of the China romset.
For problem with mechanical interference, the old school trick was to stack a few DIP sockets together and plug into those. These would space the adapter up off of the reader. (We used to use extra sockets to save wear on the chip pins during the program/burn/crash/debug cycle.)
It would be pretty similar but you would use something closed source like orcad. And the pcbs for such a small batch would be made manually using the toner transfer process instead of using a subcontractor.
Slightly related, but if I were retired today, one of my pet projects would be to train a LLM or whatever to generate new characters for MUGEN[0]. How cool would that be? Maybe the AI could come up with new fighting personas besides the grappler, shotokan, etc. Sounds like a fun project!
I've been reading through the rules to the Fight! RPG by Divine Madness Press and have been similarly looking forward to building characters, moves, and combos for that fight system.
could somebody tell me why all the ROMs need updating _every time_ a new version of MAME is released? it would seem like a major cockup: updating the data, the ROM dumps which I imagine are always the same as they come from hardware(?), instead of the code? imagine if everyone had to update the data in their databases every time a new minor version of the database software was released!
Short answer: They don't all need updating. Many of the most popular games go on for years without needing any updates, and usually if you already have settled on specific games and revisions thereof, you won't need to update.
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.
It would be nice for MAME the "multiple arcade machine emulator" to be MAMAME the "multiple arcade machine and MAME emulator" , so that it could play ROMs built for older versions of MAME. PlayStation can emulate its older versions.
Based on dates in the merged ROM set I checked, there were 170 new/updated ROMs in MAME 0.263 (Feb 2024) and 90 for MAME 0.262 (Jan 2024). Those were from merged rom sets so every zip file has 1-20 individual ROMs inside
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.
I agree it's not optimal. It's not like every game changes on every MAME release, but some indeed get re-dumped from time to time. The usual example is encrypted audio data or color palette ROMs. In an earlier version, lacking the ability to decrypt them they would be emulated with samples or code respectively, then once it's possible to dump them they get integrated into the romset for better accuracy.
I agree that that's annoying as well... but coincidentally something similar can also happen to NES/SNES emulators if they use a "ROM database".
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...)
My people. I only aspire to be this damn clever. It's why I surround myself by people smarter than me.