[HN Gopher] I accidentally deleted a bad game revision from MAME
___________________________________________________________________
I accidentally deleted a bad game revision from MAME
Author : ingve
Score : 201 points
Date : 2024-03-01 11:51 UTC (11 hours ago)
(HTM) web link (www.mistys-internet.website)
(TXT) w3m dump (www.mistys-internet.website)
| whaleofatw2022 wrote:
| Good read, a bit of a clickbait title though.
| bityard wrote:
| Fun story indeed, but yeah, nothing was deleted, accidentally
| or otherwise.
| sumtechguy wrote:
| 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.
| toast0 wrote:
| > 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.
| mewse-hn wrote:
| 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.
| ZFH wrote:
| Don't let the clickbait headline dissuade you, this is a great
| read if you're into emulation/retrogaming/any kind of software
| preservation.
| MPSimmons wrote:
| Yeah, agreed. I'm not actually into this scene but I enjoyed
| the write up.
| avg_dev wrote:
| 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"...
| rob74 wrote:
| 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.
| dang wrote:
| What would be a better, i.e. more accurate and neutral title?
| We can change it.
|
| Edit: I changed it to "I accidentally deleted a bad game
| revision from MAME" for now - is that accurate enough?
| milesvp wrote:
| Might be more accurate to change "accidentally" to
| "intentionally".
|
| Or "I found a bad dump in MAME and corrected it"
| qotgalaxy wrote:
| I expected to add a game to MAME but instead proved that it
| didn't exist
| snthd wrote:
| I accidentally found a phantom MAME game revision
| ZFH wrote:
| That might be the first recorded case of a subpar headline
| detracting from actual quality content :)
|
| 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.
| ZFH wrote:
| Works fine - thanks!
| kotaKat wrote:
| Quite frankly no, it's not. The original title was fine and a
| pleasant way to cap the story off.
| TillE wrote:
| 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.
| mattl wrote:
| Maybe for the Nintendo Power kiosks?
|
| https://en.wikipedia.org/wiki/Nintendo_Power_(cartridge)
| 0xcde4c3db wrote:
| 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.).
| MegaDeKay wrote:
| 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.
|
| https://www.mamedev.org/
| JKCalhoun wrote:
| > 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.
| jareklupinski wrote:
| reminds me of bypassing ps1 copy checks by using a 'swap disc'
| back in the day
| markx2 wrote:
| 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.
| inputError wrote:
| 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.
| whaleofatw2022 wrote:
| Oddly, most folks I knew used a Bic pen cap or similar as a
| sort of extender for the arm...
| fdsfdsafdsafds wrote:
| 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..
| slyn wrote:
| 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.
| kipchak wrote:
| 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.
| dataflow wrote:
| > 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?
| spydum wrote:
| They didn't spin that fast and it's not as sensitive as
| you think. CD-ROMs are used to dealing with bumps and
| skips and retries.
| rplnt wrote:
| The CDs are super light and the motors are super weak.
| You can stop a spinning CD with a light touch of a
| finger.
| dtech wrote:
| 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.
| dataflow wrote:
| 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.
| ska wrote:
| Re writable CD's were pretty flaky, but regular ones were
| pretty solid I think.
| IshKebab wrote:
| 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
| Mountain_Skies wrote:
| 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.
|
| https://www.youtube.com/watch?v=IFB1bSU0T1s
| MisterTea wrote:
| > It can't have been cheap to design and manufacture these custom
| adapters,
|
| 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.
| mynameisvlad wrote:
| Now imagine doing it in 1999 when Martial Masters was released.
| nick__m wrote:
| 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.
| haolez wrote:
| 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!
|
| [0] https://en.wikipedia.org/wiki/Mugen_(game_engine)
| mmcdermott wrote:
| 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.
| actionfromafar wrote:
| I read with dread waiting for the moment where the only chip in
| existence was accidentally destroyed. Glad that wasn't it!
| RichardCA wrote:
| Yes, there are many challenges in reverse engineering these
| classic games. This is a good example.
|
| 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.
|
| https://github.com/mamedev/mame/issues/5816
| cpill wrote:
| 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!
| chungy wrote:
| 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.
| ksherlock wrote:
| 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.
| ZFH wrote:
| 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.
___________________________________________________________________
(page generated 2024-03-01 23:00 UTC)