| gregf |
|
Ramtek's Trivia promoter
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 8608
|
|
Loc: southern CA, US
|
|
|
|
Send PM
|
|
|
skyarmy and rom FIXED BITS curiosity
#385568 - 03/18/20 08:09 AM
|
|
|
I am curious about the method of how the bad bits were dealt with between different games. OG did a fix for Skyarmy, but not indicating bits were adjusted to get Sky Army working.
Whereas the questionable gratiaa rom was noted as having ' // FIXED BITS (xxxxxxxx11111111)' until another rom from another pcb was dumped and compared and verified.
I thought skyarmy rom file had to be treated similar to gratiaa with // FIXED BITS
description being shown until a different Sky Army pcb can be found and the rom in question can be verified and compared with a different Sky Army pcb. iirc it may have been off by a couple bits. I thought any simple rom adjustment even required having the
' // FIXED BITS (xxxxxxxx11111111)' disclaimer notice until a rom from a different pcb is used for comparing and maybe fixing the bug issue.
Wasn't the ' // FIXED BITS (xxxxxxxx11111111)' disclaimer being used until a working rom image could replace old bad rom image a mandatory thing? I thought it was even though that was many years ago and since then a lot has changed over the years.
-
Mar 7, 2020
https://github.com/mamedev/mame/commit/87cab5bf6a62c63056edeb207aceef748096dee8
skyarmy: Fix bitrot, makes the game fully playable [O. Galibert]
ROM_LOAD( "a1h.bin", 0x0000, 0x2000, CRC(e3fb9d70) SHA1(b8e3a6d7d6ef30c1397f9b741132c5257c16be2d) )
ROM_LOAD( "a1h.bin", 0x0000, 0x2000, CRC(46507488) SHA1(a9a43caa6f3eab48c3fd9e2f34fe2b4aacfd4641) )
-
Mar 18, 2020
https://github.com/mamedev/mame/commit/d0d0c1018b6a1044fd8fb3beba173e86a5d300b4
ms32.cpp: Verified the background graphics ROM from gratiaa is correct. [Apocalypse]
-// ROM_LOAD( "mr94019-07.10", 0x000000, 0x200000, BAD_DUMP CRC(acb75824) SHA1(3b43e00a2d240761565042c8feead25a83ef0eb1) ) // FIXED BITS (xxxxxxxx11111111)
- ROM_LOAD( "mr94019-07.10", 0x000000, 0x200000, BAD_DUMP CRC(561a786b) SHA1(23df08d50801bd6e4a2f12dd3bb50632ff77f0f2) ) /* HAND CRAFTED: decrypted & re-encrypted 94019_2.07 - marked BAD_DUMP until proper ROM redump */
+ ROM_LOAD( "mr94019-07.10", 0x000000, 0x200000, CRC(561a786b) SHA1(23df08d50801bd6e4a2f12dd3bb50632ff77f0f2) )
-
|
|
|
|
Re: skyarmy and rom FIXED BITS curiosity
[Re: gregf]
#385575 - 03/18/20 04:21 PM
|
|
|
The "FIXED BITS" message is not at all mandatory. It's just a helpful diagnostic produced by MAME's romcmp tool, which can only catch a few types of common dumping errors. Depending on the hardware, some romcmp errors might not even be errors: oversize ROMs are common and graphics ROMs and bipolar decoding PROMs might not need all the data outputs that the part has.
A few types of dumping errors romcmp can't detect but have occurred:
- One or two bad bits (as in Sky Army).
- Fixed bits that extend only through certain areas of the dump. (I've patched a few cases of this by hand.)
- Bridges between address lines that cause 3/4 mirroring (as happened with the Eeekk! color PROM).
- Faulty internal latches on 8048, 8041 or related MCUs.
|
|
|
|
Re: skyarmy and rom FIXED BITS curiosity
[Re: AJR Hacker]
#385576 - 03/18/20 04:33 PM
|
|
|
> The "FIXED BITS" message is not at all mandatory. It's just a helpful diagnostic
> produced by MAME's romcmp tool, which can only catch a few types of common dumping
> errors. Depending on the hardware, some romcmp errors might not even be errors:
> oversize ROMs are common and graphics ROMs and bipolar decoding PROMs might not need
> all the data outputs that the part has.
>
> A few types of dumping errors romcmp can't detect but have occurred:
>
>
> One or two bad bits (as in Sky Army).
> Fixed bits that extend only through certain areas of the dump. (I've patched a few
> cases of this by hand.)
> Bridges between address lines that cause 3/4 mirroring (as happened with the Eeekk!
> color PROM).
> Faulty internal latches on 8048, 8041 or related MCUs.
doesn't detect combinations of data lines shorting each other out either (which happened on a recent dump from Sean, that I thought was encryption at first)
|
|
|
Stiletto |
|
They're always after me Lucky ROMS!
|
|
|
|
|
|
Reged: 03/07/04
|
|
Posts: 6472
|
|
|
|
|
|
Send PM
|
|
|
Re: skyarmy and rom FIXED BITS curiosity
[Re: Haze]
#385579 - 03/19/20 12:46 AM
|
|
|
> > The "FIXED BITS" message is not at all mandatory. It's just a helpful diagnostic
> > produced by MAME's romcmp tool, which can only catch a few types of common dumping
> > errors. Depending on the hardware, some romcmp errors might not even be errors:
> > oversize ROMs are common and graphics ROMs and bipolar decoding PROMs might not
> need
> > all the data outputs that the part has.
> >
> > A few types of dumping errors romcmp can't detect but have occurred:
> >
> >
> > One or two bad bits (as in Sky Army).
> > Fixed bits that extend only through certain areas of the dump. (I've patched a few
> > cases of this by hand.)
> > Bridges between address lines that cause 3/4 mirroring (as happened with the Eeekk!
> > color PROM).
> > Faulty internal latches on 8048, 8041 or related MCUs.
>
> doesn't detect combinations of data lines shorting each other out either (which
> happened on a recent dump from Sean, that I thought was encryption at first)
Have we added the most support we can to romcmp or would it be possible to add more support for situations such as these?
- Stiletto
|
|
|
| smf |
|
I've been here before
|
|
|
|
|
|
Reged: 01/16/15
|
|
Posts: 130
|
|
|
|
|
|
Send PM
|
|
|
Re: skyarmy and rom FIXED BITS curiosity
[Re: gregf]
#385581 - 03/19/20 01:54 AM
|
|
|
> OG did a fix for Skyarmy, but not indicating bits were adjusted to get Sky
> Army working.
It was this bit.
diff bad.asm good.asm
4716c4716
< 1F65: DD CB 9E 46 bit 0,(ix-$62)
---
> 1F65: DD CB 1E 46 bit 0,(ix+$1e)
I don't know what method he used to find it, but it's a single bit error which is not the kind of problem romcmp finds.
|
|
|
| gregf |
|
Ramtek's Trivia promoter
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 8608
|
|
Loc: southern CA, US
|
|
|
|
Send PM
|
|
|
Re: skyarmy and rom FIXED BITS curiosity
[Re: smf]
#385596 - 03/20/20 06:06 AM
|
|
|
Looking over thread, definitely some good examples. I had thought there was some
protocol to have any roms with fixed/adjusted bits to be given some // fixed bits
comment description. This was one of those rare calls since most were usually listed
as bad_dumps and the fixed bits was a rare event.
Last game I recalled with same circumstance was Midway's Road Runner [a proto clone of Midway Desert Gun] that was eventually fixed up by Guru with a different pcb and was updated with correct image dump of rom from the different Road Runner pcb that Guru had. That had to be 10 to 15 years ago.
|
|
|
| gregf |
|
Ramtek's Trivia promoter
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 8608
|
|
Loc: southern CA, US
|
|
|
|
Send PM
|
|
|
Re: skyarmy and rom FIXED BITS curiosity
[Re: AJR Hacker]
#385597 - 03/20/20 06:30 AM
|
|
|
>It's just a helpful diagnostic produced by MAME's romcmp tool, which can only catch a few
>types of common dumping errors. Depending on the hardware, some romcmp errors might not
>even be errors: oversize ROMs are common and graphics ROMs and bipolar decoding PROMs might
>not need all the data outputs that the part has.
>A few types of dumping errors romcmp can't detect but have occurred:
One or two bad bits (as in Sky Army).
Fixed bits that extend only through certain areas of the dump. (I've patched a few cases of this by hand.)
Bridges between address lines that cause 3/4 mirroring (as happened with the Eeekk! color PROM).
Faulty internal latches on 8048, 8041 or related MCUs.
Good example(s) that I overlooked. I always went the first entry. That was first one that would come to mind.
>The "FIXED BITS" message is not at all mandatory.
I had thought it was some protocol procedure, but somewhat rarely used. The last one I recall was Midway's Road Runner with one rom data file getting //fixed bits comment until Guru found another Midway Road Runner pcb and dumped rom from that pcb and replaced rom that was already in MAME source that was used with Midway Road Runner. That had to have been over 10 years earlier iirc.
During the years when Nicola Salmoria was overseeing the project some of the early mandates included no support for gambling type video games until Aaron relaxed that back in 2006. One of the other mandates by Nicola was having specific bootleg coinop videogames removed from support in MAME. Bootleg video coinop games in which the only difference between original versus bootleg was graphics hacks had to be removed from MAME back in 2001 or maybe it was 2002. That decision also created a small bit of dismay back then. I believe that decision was also relaxed by Aaron when Aaron was in charge in 2006.
You missed out on all the emudrama back in the early days on old MAME.net web site and forum days in which Gridle / Santeri S. had to beat down some of the posters and complaints on old MAME.net forums.
On occasion PacDude was over the top where one time Aaron had a complex coinop game finally emulated and he might post about it on old MAME.net forum. PacDude's reply to Aaron might have been: 'now go emulate Slither dammit'. 
|
|
|
| smf |
|
I've been here before
|
|
|
|
|
|
Reged: 01/16/15
|
|
Posts: 130
|
|
|
|
|
|
Send PM
|
|
|
Re: skyarmy and rom FIXED BITS curiosity
[Re: gregf]
#385601 - 03/20/20 01:36 PM
|
|
|
> Looking over thread, definitely some good examples. I had thought there was some
> protocol to have any roms with fixed/adjusted bits to be given some // fixed bits
> comment description.
"fixed bits" in terms of romcmp means that every byte in the file has that bit set (or clear?) i.e. it's fixed at a certain value. It doesn't mean it has been "fixed". It usually indicates that it was badly dumped, but in the case of the outrun sample rom then it was badly manufactured.
People might pull that over into the mame source to remind themselves or others that the dump is bad/questionable/nothing to worry about.
A single bit caused by bitrot won't ever be detected and once it's been (let's say) "repaired" then a comment is largely irrelevant. I would have thought it would be marked as "ROM NEEDS REDUMP" as there is no guarantee that only one bit was wrong.
|
|
|
| gregf |
|
Ramtek's Trivia promoter
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 8608
|
|
Loc: southern CA, US
|
|
|
|
Send PM
|
|
|
Re: skyarmy and rom FIXED BITS curiosity
[Re: smf]
#385604 - 03/20/20 09:49 PM
|
|
|
>> Looking over thread, definitely some good examples. I had thought there was some
>> protocol to have any roms with fixed/adjusted bits to be given some // fixed bits
>> comment description.
>"fixed bits" in terms of romcmp means that every byte in the file has that bit set (or
>clear?) i.e. it's fixed at a certain value. It doesn't mean it has been "fixed". It
>usually indicates that it was badly dumped, but in the case of the outrun sample rom then
>it was badly manufactured.
>People might pull that over into the mame source to remind themselves or others that the
>dump is bad/questionable/nothing to worry about.
>A single bit caused by bitrot won't ever be detected and once it's been (let's say)
>"repaired" then a comment is largely irrelevant. I would have thought it would be marked
>as "ROM NEEDS REDUMP" as there is no guarantee that only one bit was wrong.
Solid information there as well as AJR's and Haze's. I can see this being useful in MAME QA roms section even though it gets into nitty gritty details that most end users wouldn't be dealing with.
I was planning on asking a question about this long ago when Midway Road Runner was going through this same issue, but this was around time that either CPS-3 protection (2007) had finally been figured out or maybe it was when some laser disc games were starting to be emulated and the forums (2009), including old MAME.net back then, had been jumping around with excitement at the time. I decided to wait and ask the question later. I didn't expect the question to be another ten years later, but Skyarmy looked like the right moment to ask the question. ;-)
|
|
|
|
Re: skyarmy and rom FIXED BITS curiosity
[Re: smf]
#385611 - 03/21/20 10:51 AM
|
|
|
> > OG did a fix for Skyarmy, but not indicating bits were adjusted to get Sky
> > Army working.
>
> It was this bit.
>
> diff bad.asm good.asm
> 4716c4716
> < 1F65: DD CB 9E 46 bit 0,(ix-$62)
> ---
> > 1F65: DD CB 1E 46 bit 0,(ix+$1e)
>
> I don't know what method he used to find it, but it's a single bit error which is not
> the kind of problem romcmp finds.
Oh, the usual. Find which sprite is the helicopter that won't go left (3c, always the same whether it goes left or right actually). Find where the coordinates are computed and written, which made me find where it was initialized and the left/right decision was done. See that two bits where different between the two directions, including ix+1e that's set to either 00 and 01. Track what is done with these bits, see nothing significant. Then look at the movement computation, and see that test decides whether to go left or right. See it's a one-bit difference, and go *duh*.
OG.
PS: Also checked it wasn't a mirror, but no, it's in the middle of ram. Unless there's kinky mapping, but I doubt it.
|
|
|
Previous 
Index 
Next 
Threaded 
skyarmy and rom FIXED BITS curiosity
Reply
[Re: 
