A-Z list of erroneus TOSEC AmigaDOS disks

[andreas]

OK boys.
My ADFCHK tool was only the beginning; now this could do some more effect.

I will list ALL erroneous ADOS images with checksum errors on vital data (partly checked on Amiga side, too in case of doubt) in a A-Z manner. Whenever I can find some time to check, a new letter will be added (a perfect idea before Christmas, by opening another window each day until Dec 24th )

For now, I will do all GAMES-ADF, those of which are in ADOS format (not PD).
(Since it would make no sense and nearly every NDOS game has its own special format, you won't find any disks of this type in my list, obviously.)

Here's an excerpt of 0-9 as a demo:
...
---------------------------------------------------------------------------
CHECKING DISK: '4x4 Off-Road Racing (1989)(U.S. Gold)[cr Wizard].zip'

BOOTBLOCK TYPE: 'DOS0-OFS'

AMIGA DOS VOLUME NAME: '4x4'

CHECKING FILE #1 INSIDE ZIP: '4x4 Off-Road Racing (1989)(U.S. Gold)[cr Wizard].adf'

Found valid AmigaDOS volume name: this could be a standard AmigaDOS or mixed-format disk.

---------------------------------------------------------------------------
Block # 130 - DATA - (cyl. 05 surface 1 sector 09) - CHECKSUM ERROR detected!
---------------------------------------------------------------------
Block # 135 - DATA - (cyl. 06 surface 0 sector 03) - CHECKSUM ERROR detected!
...

[PandMonium]

nice information you've got there

[Photon]

Please do G soon, TOSEC says the one called plain 'Gravity Force' is *supposed* to have blue bricks, and I disagree strongly...

[andreas]

[UPDATE] Complete! Two zips are now available on my first post:

tosec_GamesADF_A-Z_allinone_ERR.zip (all error information summarized in one file)
tosec_GamesADF_A-Z_single_ERR.zip (one file each, grouped per letter)

[TKaos]

Thanks for your work, I hope we can put these informations in the DATs soon.

[andreas]

I return the thanks for FINALLY giving some feedback (apart from PandMonium). Lots of views considering the short time passed since I've put up my final file, but everyone silent as mice

Good. People may say "thanks" to you now for encouraging me to tackle the PD DAT real soon-ish

[Photon]

Originally Posted by Photon

Please do G soon, TOSEC says the one called plain 'Gravity Force' is *supposed* to have blue bricks, and I disagree strongly...

Hey, checking into the thread again. Having recently bought the original, I can confirm that the blue bricks version has nothing to do with the original. I wonder where it comes from, I had never seen it before TOSEC

[mai]

First, thanks for your work, andreas.

CHECKING DISK: 'Portal (1986)(Activision)(Disk 1 of 3)[a3].ZIP'

BOOTBLOCK TYPE: 'DOS0-OFS'

AMIGA DOS VOLUME NAME: 'PORTAL1'

CHECKING FILE #1 INSIDE ZIP: 'Portal (1986)(Activision)(Disk 1 of 3)[a3].adf'

Found valid AmigaDOS volume name: this could be a standard AmigaDOS or mixed-format disk.

---------------------------------------------------------------------------
Block # 48 - DATA - (cyl. 02 surface 0 sector 04) - CHECKSUM ERROR detected!
---------------------------------------------------------------------
Block # 52 - DATA - (cyl. 02 surface 0 sector 08) - CHECKSUM ERROR detected!

Probably not a reason to add [b] flag.
I have often seen such checksum error in a file, which has protection flags
"HSPA".
Can you tell me something about this.

[andreas]

Sure, this is a bit trickier, though

These blocks are unused, even though the bitmap tells otherwise. Yes they are marked as "used", but not used as actual data blocks!

#48 looks like a data block of file 'i13', but it does not belong to any file - it's orphaned.
The actual 'i13' has header on block 1186, and data blocks on 26 and 27, so #48 is not touched!

#52 looks like a data block of 'p381', but it does not belong to any file - it's orphaned, too.
The actual 'p381' has header on block 1182, and data blocks in sequence (1183 - 29 - 30 - 31 - 32), so #52 is not touched!

Hence you have three free guesses why each file is copyable without any errors

------------------------------------------------

Conclusion: Future versions of ADFCHK should be able to check headers, and check back if the block number appears either in the header itself or (optionally) one of its file list blocks; if not, display some special information.

Thanks for the observation.

[PandMonium]

good work from both

[andreas]

Games-PD is done.