AtariZoll wrote:Yes, SW never expects specific data on concrete location in track dump (track read buffer). Usually $A1 is used as 'marker' . In case of Barbarian Psyg. there is 11x $FF, according to screenshot posted by DrCoolZic . So, it has +-5 bytes tolerance . I don't know is it really enough ...
What is most interesting in this case is STX image of game, available online: it is most likely made by Ijor self . Only 75 tracks are in STX, and there is no dump of track 0 at all ! Only 512 bytes of bootsector. Furthermore, there is no content shown on screenshot few posts above - the result of performed track read command in Steem Debugger. That content is btw. not correct track content, as there is lot of $FF further. So, only thing what I may assuming is that it is special hack for this particular title, edition. Performed after detecting specific conditions - like buffer address, content of bootsector, I guess.
And here may lie the reason why author is not much interested in publishing sources. Probably there are more similar hacks ..
I suppose you are referring to image provided in http://www.planetemu.net/roms/atari-st-games-stx
I have downloaded the images and yes they must have been done by Ijor as the "Tool" field is CC. This imply images done with Discovery Cartridge and this imager was never released ...
I have looked at the image using my PastiRead program (viewtopic.php?f=47&t=19904&start=25#p244419) and there is no track description for this track
Here the beginning of the dump:
Code: Select all
Pasti file version 3.0 Image Tool=CC - Number of tracks=75 - (0-15)
Track 00.0 6295 bytes 1 sect FuzBytes=No Flag=01 SDesc RecSize=544 (16-31)
Sector T=0 H=0 SN=1 S=2 CRC=6FCA bitPos=700 Time=0 Flags=00 Off=0 (32-47)
Start of Track data 48
Reading Sector 1 512 bytes (48-559)
Track 01.0 6294 bytes 9 sect FuzBytes=No Flag=01 SDesc RecSize=4768 (560-575)
Sector T=1 H=0 SN=10 S=2 CRC=2160 bitPos=702 Time=0 Flags=00 Off=0 (576-591)
Sector T=1 H=0 SN=11 S=2 CRC=1053 bitPos=5614 Time=0 Flags=00 Off=512 (592-607)
Sector T=1 H=0 SN=12 S=2 CRC=87CA bitPos=10526 Time=0 Flags=00 Off=1024 (608-623)
Sector T=1 H=0 SN=13 S=2 CRC=B6F9 bitPos=15438 Time=0 Flags=00 Off=1536 (624-639)
Sector T=1 H=0 SN=14 S=2 CRC=E5AC bitPos=20350 Time=0 Flags=00 Off=2048 (640-655)
Sector T=1 H=0 SN=15 S=2 CRC=D49F bitPos=25262 Time=0 Flags=00 Off=2560 (656-671)
Sector T=1 H=0 SN=16 S=2 CRC=998C bitPos=30174 Time=0 Flags=00 Off=3072 (672-687)
Sector T=1 H=0 SN=17 S=2 CRC=A8BF bitPos=35086 Time=0 Flags=00 Off=3584 (688-703)
Sector T=1 H=0 SN=18 S=2 CRC=FBEA bitPos=39998 Time=0 Flags=00 Off=4096 (704-719)
Start of Track data 720
Reading Sector 10 512 bytes (720-1231)
Reading Sector 11 512 bytes (1232-1743)
Reading Sector 12 512 bytes (1744-2255)
Reading Sector 13 512 bytes (2256-2767)
Reading Sector 14 512 bytes (2768-3279)
Reading Sector 15 512 bytes (3280-3791)
Reading Sector 16 512 bytes (3792-4303)
Reading Sector 17 512 bytes (4304-4815)
Reading Sector 18 512 bytes (4816-5327)
So if Past lib provides FF it must be a hack ...
But I am surprise by what this protection check.
All normal tracks will have a sequence of chars (usually around 12) interpreted as 00 or FF before the first sync. This sequence is there to allow a better synchronization of the phase lock look by providing maximum flux transition.
So it like "check that this track is normal"?