pce.xml: mark alts as bad dumps

[0kmg]

• alts now with "[b]" in file name are listed as bad dumps in NoIntro
• remaining two alts are not in NoIntro, added comments about bytes that differ from parents
• Benkei Gaiden alt was actually the verified dump, switched CRCs
• R-Type Part-2 alt seems to be a proper bugfix release, made the later revision the parent

[DopefishJustin]

Bad dumps of revisions that we have the good dump of should just be removed.

[0kmg]

NoIntro comments say these were listed as alternates in Good*. For some they mention the possibility they may be earlier revisions or betas, yet they have flagged them all bad dumps. I figured it would be best to do the same in MAME and "baddump" seems the only way to flag them as suspicious. This of course leaves aside the two alts that NoIntro doesn't even track.

I don't feel super strong either way. I could comment them out for further investigation? Or given that nearly half of the 4000+ games in nes.xml are listed as baddump (despite the fact that there's a much more robust dumping community around NES than PCE) I don't mind flagging these and keeping them in either. At least that was my original rationale.

[ghost]

I have noticed some of these 'outside' collections are overly aggressive with bad dump marking - for example some of the protected Genesis dumps were marked as 'bad' (simply on the basis that they didn't run by default / on a flashcart) with the hacked ones being considered correct.

btw, I was alerted to the fact there are 2 compilations of NES games on the PCE, which were released as unlicensed carts back in the day. When I looked they were missing from the softlists, have they since been added?

If a dump is obviously just a corrupt dump of an existing one, yes, it should be removed, if it's a bad dump of a revision that no good dump exists for, it should be retained. It sounds like some of these are potentially the latter.

[0kmg]

Is it better to NOT mark them as bad dumps and just leave a comment in the softlist then? It is difficult to determine if they are corrupt dumps of an existing one, if they are bad dumps of a revision, or if they are good dumps even of a revision that no one has verified.

Recently I corrected a few games in pce.xml to known good dumps. One had a one byte change that was the # lives. Another had large amounts of identical data slightly shifted which caused sprite corruption. Those were obvious bad dump candidates. With this batch of alts I haven't found obvious ones yet but still thought they should be flagged.

(About the NES compilations, no it looks like the PCE list hasn't been touched [other than metadata] since MESS SVN era—just an rtype revision and the off the wall proto you added. FYI there is a VIC 20 compilation for PCE that seems to be from the same group "back in the day".)

[dshadoff]

(About the NES compilations, no it looks like the PCE list hasn't been touched [other than metadata] since MESS SVN era—just an rtype revision and the off the wall proto you added. FYI there is a VIC 20 compilation for PCE that seems to be from the same group "back in the day".)

I am almost certain that I know the origin of these, and they were homebrew, never intended for release. Just tech demos.
If you have questions, the person to ask would be "turboxray" from here: https://pcengine.proboards.com/

[dshadoff]

Also, you have made a mistake by marking Benkei Gaiden CRC32 e1a73797 as bad dump - it is the original, and I have verified by dumping my own collection and verifying against external sources for 2-way match.

[ghost]

I am almost certain that I know the origin of these, and they were homebrew, never intended for release. Just tech demos.
If you have questions, the person to ask would be "turboxray" from here: https://pcengine.proboards.com/

They were sold commercially in Asia, so they're eligible regardless.

[dshadoff]

I have a complete collection, and I'm not aware of anything like that being sold in Asia.
Only this company did anything like that, and they are based in Germany (they sold all sorts of unauthorized reprints and unauthorized physical copies of translations): https://pceworks.wordpress.com/
But in any case, it's up to you what is included/excluded from the lists.

[0kmg]

Also, you have made a mistake by marking Benkei Gaiden CRC32 e1a73797 as bad dump - it is the original, and I have verified by dumping my own collection and verifying against external sources for 2-way match.

Oh, thank you. No-Intro lists it as a bad dump but possible earlier revision. So it's an earlier revision then?

Do you have any of the other marked alts in your collection and/or can you shed light on their provenance? The PC Genjin - Pithecanthropus Computerurus for instance seems it could be a revision.

[dshadoff]

Benkei Gaiden was not so popular to warrant a second release - and with the fixed-cost expenses for HuCard releases, I don't believe that they would have released a revision, so my expectation is that No-intro's is a bad dump. (There are several CDs with multiple releases however).

The PC Genjin copy in my possession is CRC32 2cb5cd55. It was popular enough to be possible to have had a separate release, but I doubt that this happened; I saw no records of it in Japanese books. I should note that while re-ripping in 2019, I found several titles to have bit-rot, and acquired replacement copies in order to have known-good copies in my collection. Certain titles made at a transitionary point in time were more likely to have decayed data - such as both USA and Japanese versions of PC Genjin 2 (most common), but also Power League 4, R-Type 2, and Champions Forever Boxing (USA).

Without going through the full list, I can share my own notes with you:
https://docs.google.com/spreadsheets/d/1UjOekYZoaHPy9dqjehBxK5THg94AucbzuYBN_9LvsTE/edit?usp=sharing

The HuCard tab lists CRC32 of all Japanese ROMs (I don't list American ones as they have multiple variations - bitflip, protection removal, etc.)

[ghost]

Benkei Gaiden was not so popular to warrant a second release - and with the fixed-cost expenses for HuCard releases, I don't believe that they would have released a revision, so my expectation is that No-intro's is a bad dump. (There are several CDs with multiple releases however).

Code is moved around between the sets, shifted, jump offsets changed. This does not look like the hallmark of bitrot, rather a different revision. Bitrot results in single bits randomly flipped etc.

Same for PC Genjin.

These are different releases, not bad dumps.

There either were second releases, or maybe one is a prototype.

[dshadoff]

Prototype I can believe. Or a hack/patch. But if you're looking for one to be the "quintessential" version, it should be one with a known provenance.

[ghost]

For benkei, if we look at the disassembly for example, the startup code looks like this, note all the jumps shifted, because there code has been moved around.

(parent set)
00000: ea                    nop
00001: 78                    sei
00002: d4                    csh
00003: a9 ff                 lda  #$FF
00005: 53 01                 tam  #$01
00007: a9 f8                 lda  #$F8
00009: 53 02                 tam  #$02
0000b: a9 00                 lda  #$00
0000d: 53 80                 tam  #$80
0000f: a9 01                 lda  #$01
00011: 53 40                 tam  #$40
00013: a2 ff                 ldx  #$FF
00015: 9a                    txs
00016: 20 49 ee              jsr  $EE49
00019: 20 f2 fb              jsr  $FBF2
0001c: 20 2d f9              jsr  $F92D
0001f: 20 00 40              jsr  $4000
00022: 20 0f 40              jsr  $400F
00025: 20 61 f9              jsr  $F961
00028: a9 00                 lda  #$00
0002a: 8d 02 14              sta  $1402
0002d: a9 33                 lda  #$33
0002f: 8d 00 0c              sta  $0C00
00032: a9 01                 lda  #$01
00034: 8d 01 0c              sta  $0C01
00037: 20 01 fc              jsr  $FC01
0003a: 4c 50 ee              jmp  $EE50
0003d: a9 ff                 lda  #$FF
0003f: 85 b6                 sta  $B6
00041: 20 68 ee              jsr  $EE68
00044: 20 43 ee              jsr  $EE43
00047: 20 88 fe              jsr  $FE88
0004a: 20 4d ea              jsr  $EA4D
0004d: 20 ce fd              jsr  $FDCE
00050: 20 d4 fd              jsr  $FDD4
00053: 20 8a ef              jsr  $EF8A
00056: 20 76 ef              jsr  $EF76
00059: 20 78 ee              jsr  $EE78

(alt set)
00000: ea                    nop
00001: 78                    sei
00002: d4                    csh
00003: a9 ff                 lda  #$FF
00005: 53 01                 tam  #$01
00007: a9 f8                 lda  #$F8
00009: 53 02                 tam  #$02
0000b: a9 00                 lda  #$00
0000d: 53 80                 tam  #$80
0000f: a9 01                 lda  #$01
00011: 53 40                 tam  #$40
00013: a2 ff                 ldx  #$FF
00015: 9a                    txs
00016: 20 55 ee              jsr  $EE55
00019: 20 fe fb              jsr  $FBFE
0001c: 20 39 f9              jsr  $F939
0001f: 20 00 40              jsr  $4000
00022: 20 0f 40              jsr  $400F
00025: 20 6d f9              jsr  $F96D
00028: a9 00                 lda  #$00
0002a: 8d 02 14              sta  $1402
0002d: a9 33                 lda  #$33
0002f: 8d 00 0c              sta  $0C00
00032: a9 01                 lda  #$01
00034: 8d 01 0c              sta  $0C01
00037: 20 0d fc              jsr  $FC0D
0003a: 4c 5c ee              jmp  $EE5C
0003d: a9 ff                 lda  #$FF
0003f: 85 b6                 sta  $B6
00041: 20 74 ee              jsr  $EE74
00044: 20 4f ee              jsr  $EE4F
00047: 20 99 fe              jsr  $FE99
0004a: 20 51 ea              jsr  $EA51
0004d: 20 df fd              jsr  $FDDF
00050: 20 e5 fd              jsr  $FDE5
00053: 20 96 ef              jsr  $EF96
00056: 20 82 ef              jsr  $EF82
00059: 20 84 ee              jsr  $EE84

If we look at that from a code flow point of view, you can see that from the first changed jump $FBF2 vs $FBFE the function that it calls (starting with stz $0402) is correctly found at the new address. same for all the jumps.

(main)
E001: sei
E002: csh
E003: lda  #$FF
E005: tam  #$01
E007: lda  #$F8
E009: tam  #$02
E00B: lda  #$00
E00D: tam  #$80
E00F: lda  #$01
E011: tam  #$40
E013: ldx  #$FF
E015: txs
E016: jsr  $EE49
EE49: clx
EE4A: stz  $00,x
EE4C: inx
EE4D: bne  $EE4A
EE4A: stz  $00,x
EE4C: inx
EE4D: bne  $EE4A

   (loops for 762 instructions)

EE4F: rts
E019: jsr  $FBF2
FBF2: stz  $0402

(alt)
E001: sei
E002: csh
E003: lda  #$FF
E005: tam  #$01
E007: lda  #$F8
E009: tam  #$02
E00B: lda  #$00
E00D: tam  #$80
E00F: lda  #$01
E011: tam  #$40
E013: ldx  #$FF
E015: txs
E016: jsr  $EE55
EE55: clx
EE56: stz  $00,x
EE58: inx
EE59: bne  $EE56
EE56: stz  $00,x
EE58: inx
EE59: bne  $EE56

   (loops for 762 instructions)

EE5B: rts
E019: jsr  $FBFE
FBFE: stz  $0402

The addresses seem higher on the current alt set, which suggests either code was inserted in that one, shifting things further along or the codebase was optimized, resulting in functions moving down a bit.

In reality, the exact differences between the code should be studied, to determine if one looks like a bugfix. MAME's policy is to have the most recent set as parent, not the most common.

of course I can't also rule out the unverified one having bitrot as well, but it's definitely a legitimate revision that needs documenting as such.

[rb6502]

Benkei Gaiden was not so popular to warrant a second release - and with the fixed-cost expenses for HuCard releases, I don't believe that they would have released a revision, so my expectation is that No-intro's is a bad dump. (There are several CDs with multiple releases however).

It's worth noting that while that's the accepted wisdom in console dumping circles, a fair amount of cartridge and other ROM games have turned out to have legit multiple releases when people actually check. I worked in the industry at that time and ROM revisions were certainly heavily frowned upon but could happen if something bad enough turned up or to fix triaged bugs that annoyed the team if a first run sold out.

[dshadoff]

@davidhaywood That is very interesting, and looks like something to be studied. It is elaborate enough that it would have been done based on source, rather than an aftermarket hack/patch.
@rb6502 Yes, ROM revisions would have been frowned upon in any manufacturing scenario - but even more so in the case of HuCards, because of the manufacturing approach - these weren't ROM chips soldered to a PC board; they were dies affixed to a substrate, epoxy added, and inserted into a plastic carrier with silkscreen print. A very different process, and much more expensive for revisions. The chip dies could have been PROMs rather than mask-programmed at that point, but my recollection is that cost-effectiveness of this approach would have taken place around 1990 rather than 1987.

[rb6502]

Anyway, since the two versions are clearly actual recompiles of different versions, neither should be marked as bad. Lacking better info I'd call the one dshadoff verified the parent and the other as an alt version until TCRF or someone figures out what the changes mean.

[0kmg]

@davidhaywood Thank you for looking into Benkei. As you've noted a cursory glance at the PC Genjin dissassembly suggests something similar.

@dshadoff Has No-Intro mistakenly listed you as a second dumper of Benkei with CRC C9626A43? Indeed that's why it is "verified" not just "trusted" there.

BTW, what is MAME's policy on adding Wii Virtual Console dumps to the software lists? It seems like we don't. I ask because the only other trusted dump in No-Intro for Benkei is from a Wii. It could be that CRC C9626A43 is a later revision that was never released on HuCard. This fits well with @dshadoff's intuition about the likelihood of revisions on PCE.

[dshadoff]

@0kmg I have no connection to No-Intro, but I have shared my spreadsheet to other previously. As my verified list does not include the CRC that you list, that is some kind of misattribution error. If it is a Wii extract, that could explain a lot (and I would not know about such things).

[ghost]

Did the dump exist before the Wii version? I've thought things might be Wii extracts in the past, but traced the ROM to exist prior to that.

A lot of the Wii versions are hacks of existing binaries, not recompiles, as no better sources were available. Some are unreleased ROMs from the vaults (sometimes with hacks applied to comply with epilepsy, colourblindness etc. regulations)

Sometimes the Wii versions get documented, as they've ended up on repro carts etc. some don't, because they don't work on hardware, they've been modified to work with the poor quality Nintendo emulators.

I know people who have worked on Wii releases, and when there are no other resources, they will go to existing collections (sadly, usually outdated ones like the 'GoodTools' because upper management see the word 'Good' and think that must mean Good / Best set, same for MAME / Arcade, they'll see '2003 Reference set', and think it means that's the definitely reference and use those ROMs) Commercial emulation is a mess.

[0kmg]

@dshadoff Thank you so much for your help! I'm guessing it's a clerical error on No-Intro's side. They seem to have added you as a trusted dump (based on your list) to a bunch of their entries at the same time (in late February 2021).

[0kmg]

@davidhaywood It seems GoodPCE v1.09 dates from Aug 2003 and available romsets out there of v1.09 have the alt. I guess this points back to pre-Wii mystery revision (that later ended up on Wii).

[dshadoff]

@0kmg I'm happy to help for anything PCE-related. I've been around since the beginning, and I know that cleaning up ROMsets is a never-ending task; many well-meaning people try to add information without ever having touched a real cart. I notice that lots of other "new" technical information from the past 5 years is still not implemented into MAME, and would like to provide a core developer with assistance (although don't have the time to study MAME internals to do it myself). If you know who I might be able to support, please let me know.