Jump to content

Photo

Atari 8-bit Software Preservation Initiative


1301 replies to this topic

#1276 ebiguy OFFLINE  

ebiguy

    Chopper Commander

  • 110 posts
  • Location:Paris, France

Posted Sat Jul 21, 2018 10:38 AM

 

 

Take a look at the page for the Age of Adventure Side A dump on the website:

 

http://a8preservatio...oftware/dump/80

 

The CRC of the file you provided does not match that page. So this is either an older dump we did and have since corrected or not ours. Our dump was generated using Kryoflux and a8rawconv 0.92.

 

Thank you for your answer.

I think I have downloaded the file in the torrent posted here maybe a couple years ago.

But I did not know that a web site was dedicated to the initiative.

Great job !

I just signed for it.

Now, how can I download the dump corresponding to the URL you put in your post ?



#1277 remowilliams OFFLINE  

remowilliams

    Quadrunner

  • 10,509 posts
  • Location:Detonation Boulevard

Posted Sat Jul 21, 2018 11:12 AM

Now, how can I download the dump corresponding to the URL you put in your post ?

 

https://mega.nz/#F!N...UBMxtRh4MVYcp9w



#1278 ebiguy OFFLINE  

ebiguy

    Chopper Commander

  • 110 posts
  • Location:Paris, France

Posted Sat Jul 21, 2018 3:15 PM

 

 

Take a look at the page for the Age of Adventure Side A dump on the website:

 

http://a8preservatio...oftware/dump/80

 

The CRC of the file you provided does not match that page. So this is either an older dump we did and have since corrected or not ours. Our dump was generated using Kryoflux and a8rawconv 0.92.

 

Thanks to remowilliams, I could get the latest version which is different than the one I had.

But I am doing the same observations as the track 2 content is exactly the same in both ATX files.

I wish I could check if the sectors that do not appear in the official dump have a clock mark in the real disk



#1279 ijor OFFLINE  

ijor

    River Patroller

  • 2,060 posts

Posted Sat Jul 21, 2018 6:34 PM

I was looking at the ATX file Age of Adventure from Electronic Arts.
Track number 2 has the following sectors (relative track numbers)
06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 01 02 03 04 05
This track contains 34 sectors.

I just discovered something about this track by looking at the sector content (but maybe this is a well known subject for others)
There are 49 sectors indeed, not 34. And the list is ...

 

I am currently on a trip and can't test or check anything. But I'm pretty sure that those tracks don't have 49 sectors. I don't remember for sure (and again, can't check it right now) if those headers you see lack the needed missing clock or if there is something else. Will give a more detailed answer next week. Remind me if I forget :)


Edited by ijor, Sat Jul 21, 2018 6:36 PM.


#1280 ijor OFFLINE  

ijor

    River Patroller

  • 2,060 posts

Posted Wed Jul 25, 2018 6:57 PM

I was looking at the ATX file Age of Adventure from Electronic Arts ...This track contains 34 sectors.

... There are 49 sectors indeed, not 34 ...
The first sector is $F8 -> 07 and the second one is $F9 -> 06. Both header CRC are OK.
I can not be sure about the fact that there are 48 sectors with only the ATX because I can not check that both headers have a C7 clock mark.

 

I double checked ... These dummy headers aren't actually headers because they have a normal clock pattern, no clock pulse is missing as is required for the FDC. Also note that, even when it doesn't matter, the CRC is actually wrong.



#1281 Wilheim OFFLINE  

Wilheim

    Chopper Commander

  • 168 posts

Posted Thu Jul 26, 2018 5:08 AM

Hi! Seeding the zip file. Thanks!



#1282 ebiguy OFFLINE  

ebiguy

    Chopper Commander

  • 110 posts
  • Location:Paris, France

Posted Fri Jul 27, 2018 1:44 PM

 

I double checked ... These dummy headers aren't actually headers because they have a normal clock pattern, no clock pulse is missing as is required for the FDC. Also note that, even when it doesn't matter, the CRC is actually wrong.

 

You're right. The CRC are wrong. I have full list of header found in each sector of track 2:

sector 6 at index 0 and position 220 data crc: Ok
found header $01 $fd $ff $f8 $ff $6a $f2 (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $f9 $ff $3c $f1 (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 7 at index 1 and position 719 data crc: Ok:
found header $01 $fd $ff $f9 $ff $3c $f1 (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $f7 $ff $7a $cc (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 8 at index 2 and position 1750 data crc: Ok:
found header $01 $fd $ff $f6 $ff $49 $fd (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $f7 $ff $1f $fe (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 9 at index 3 and position 2250 data crc: Ok:
found header $01 $fd $ff $f7 $ff $1f $fe (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $f5 $ff $1c $ae (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 10 at index 4 and position 3283 data crc: Ok:
found header $01 $fd $ff $f4 $ff $2f $9f (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $f5 $ff $79 $9c (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 11 at index 5 and position 3783 data crc: Ok:
found header $01 $fd $ff $f5 $ff $79 $9c (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $f3 $ff $b6 $08 (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 12 at index 6 and position 4816 data crc: Ok:
found header $01 $fd $ff $f2 $ff $85 $39 (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $f3 $ff $d3 $3a (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 13 at index 7 and position 5316 data crc: Ok:
found header $01 $fd $ff $f3 $ff $d3 $3a (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $f1 $ff $d0 $6a (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 14 at index 8 and position 6349 data crc: Ok:
found header $01 $fd $ff $f0 $ff $e3 $5b (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $f1 $ff $b5 $58 (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 15 at index 9 and position 6850 data crc: Ok:
found header $01 $fd $ff $f1 $ff $b5 $58 (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $ef $ff $f0 $16 (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 16 at index 10 and position 7882 data crc: Ok:
found header $01 $fd $ff $ee $ff $c3 $27 (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $ef $ff $95 $24 (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 17 at index 11 and position 8382 data crc: Ok:
found header $01 $fd $ff $ef $ff $95 $24 (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $fe $ff $c0 $54 (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 1 at index 12 and position 9414 data crc: ERROR:
found header $01 $fd $ff $fd $ff $95 $07 (real header) at index: 39 and bitShift: 2 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $fe $ff $a5 $66 (fake header) at index: 107 and bitShift: 2 with header crc: ERROR and sector number match: NO

sector 2 at index 13 and position 9933 data crc: Ok:
found header $01 $fd $ff $fe $ff $a5 $66 (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $fc $ff $a6 $36 (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 3 at index 14 and position 10964 data crc: Ok:
found header $01 $fd $ff $fb $ff $3f $a1 (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $fc $ff $c3 $04 (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 4 at index 15 and position 11464 data crc: Ok:
found header $01 $fd $ff $fc $ff $c3 $04 (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $fa $ff $0c $90 (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 5 at index 16 and position 12495 data crc: Ok:
found header $01 $fd $ff $f9 $ff $59 $c3 (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $fa $ff $69 $a2 (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 6 at index 17 and position 12995 data crc: Ok:
found header $01 $fd $ff $fa $ff $69 $a2 (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $f8 $ff $6a $f2 (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 7 at index 18 and position 14024 data crc: Ok:
found header $01 $fd $ff $f7 $ff $7a $cc (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $f8 $ff $0f $c0 (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 8 at index 19 and position 14523 data crc: Ok:
found header $01 $fd $ff $f8 $ff $0f $c0 (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $f6 $ff $49 $fd (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 9 at index 20 and position 15553 data crc: Ok:
found header $01 $fd $ff $f5 $ff $1c $ae (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $f6 $ff $2c $cf (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 10 at index 21 and position 16052 data crc: Ok:
found header $01 $fd $ff $f6 $ff $2c $cf (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $f4 $ff $2f $9f (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 11 at index 22 and position 17081 data crc: Ok:
found header $01 $fd $ff $f3 $ff $b6 $08 (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $f4 $ff $4a $ad (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 12 at index 23 and position 17581 data crc: Ok:
found header $01 $fd $ff $f4 $ff $4a $ad (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $f2 $ff $85 $39 (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 13 at index 24 and position 18609 data crc: Ok:
found header $01 $fd $ff $f1 $ff $d0 $6a (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $f2 $ff $e0 $0b (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 14 at index 25 and position 19108 data crc: Ok:
found header $01 $fd $ff $f2 $ff $e0 $0b (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $f0 $ff $e3 $5b (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 15 at index 26 and position 20139 data crc: Ok:
found header $01 $fd $ff $ef $ff $f0 $16 (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $f0 $ff $86 $69 (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 16 at index 27 and position 20639 data crc: Ok:
found header $01 $fd $ff $f0 $ff $86 $69 (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $3e $2e $42 $00 $00 (fake header) at index: 85 and bitShift: 1 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $ee $ff $c3 $27 (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 17 at index 28 and position 21669 data crc: Ok:
found header $01 $fd $ff $fe $ff $c0 $54 (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $ff $ff $96 $57 (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 1 at index 29 and position 22170 data crc: Ok:
found header $01 $fd $ff $ff $ff $96 $57 (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $fd $ff $95 $07 (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 2 at index 30 and position 23201 data crc: Ok:
found header $01 $fd $ff $fc $ff $a6 $36 (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $fd $ff $f0 $35 (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 3 at index 31 and position 23700 data crc: Ok:
found header $01 $fd $ff $fd $ff $f0 $35 (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $fb $ff $3f $a1 (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

sector 4 at index 32 and position 24730 data crc: Ok:
found header $01 $fd $ff $fa $ff $0c $90 (real header) at index: 38 and bitShift: 0 with header crc: Ok and sector number match: yes and data starting at: 63
found header $01 $fd $ff $fb $ff $5a $93 (fake header) at index: 106 and bitShift: 0 with header crc: ERROR and sector number match: NO

sector 5 at index 33 and position 25230 data crc: Ok:
found header $01 $fd $ff $fb $ff $5a $93 (fake header) at index: 42 and bitShift: 0 with header crc: ERROR and sector number match: NO
found header $01 $fd $ff $f9 $ff $59 $c3 (real header) at index: 104 and bitShift: 0 with header crc: Ok and sector number match: yes

We can see that the first sector (sector 6) contains a valid header for the next sector (at offset 38) and both sector data overlaps (the begining of next sector data is found in the first sector data at index 63).

Then the second sector (sector 7) contains a valid header for the next sector (at offset 104) but the sector data does NOT overlap

And this 2 kind of sectors are repeated until the end of the track.

The sectors are linked by pair. I mean sector 6 overlaps with sector 7, then sector 8 overlaps with sector 9, etc

 

You can notice that sector 1 at index 12 is special because we find the header of the next sector but shifted by 2 bits (this header is not byte aligned with the current sector data).

I guess this is probably the point (just before the header) where the write track command ended.

Also, you can see that sector 16 at index 27 has 2 fake headers.

 

I am stiil wondering why there is so much fake headers. Maybe this was part of the process of creating the track.

We clearly see a pattern for writing the track.

Maybe the track was written with 68 real headers but the creation process did write sector 7 at index 1, sector 9 at index 3 etc after the write track command to have good data CRC on almost all sectors, thus overwriting the clock marks of half of the sectors.

 

What is your guess about it ?
 



#1283 ebiguy OFFLINE  

ebiguy

    Chopper Commander

  • 110 posts
  • Location:Paris, France

Posted Fri Jul 27, 2018 1:55 PM

I have another question unrelated with my previous post.

When a weak byte is found in a sector. Let's says at offset 12 in the data we find no clock marks for this byte. This is a weak byte.

My question is: if normal data clock marks are found at offset 13 and after, do we read good values for those bytes or do we read random values for all the remaining bytes of the sector.

My guess is that the synchronization is lost and we read random values until the end of the sector. Am I right ?



#1284 ijor OFFLINE  

ijor

    River Patroller

  • 2,060 posts

Posted Fri Jul 27, 2018 6:42 PM

I am stiil wondering why there is so much fake headers. Maybe this was part of the process of creating the track.

We clearly see a pattern for writing the track.

Maybe the track was written with 68 real headers but the creation process did write sector 7 at index 1, sector 9 at index 3 etc after the write track command to have good data CRC on almost all sectors, thus overwriting the clock marks of half of the sectors.

What is your guess about it ?

 

It is possible that it was an artifact of the track creation, I really don't know for sure. Might be it is by design because they considered it would be more difficult to copy such kind of track, or may be it was for some kind of obfuscation hoping that some copiers would be confused by those headers. It might be a mistake, a bug, somewhere on the track creation process and they never noted. Or when they noted it was too late to fix and they didn't bother. It wouldn't be the first time I see something like this.

 

Unfortunately we don't know much about the story behind those protections. We have no idea who designed this protection and how. That's too bad. I'm sure he was a very talented and clever guy and I wish he would be here and would accept an interview with Kevin :)



#1285 ijor OFFLINE  

ijor

    River Patroller

  • 2,060 posts

Posted Fri Jul 27, 2018 6:56 PM

When a weak byte is found in a sector. Let's says at offset 12 in the data we find no clock marks for this byte. This is a weak byte.

My question is: if normal data clock marks are found at offset 13 and after, do we read good values for those bytes or do we read random values for all the remaining bytes of the sector.

My guess is that the synchronization is lost and we read random values until the end of the sector. Am I right ?

 

Yes, sync would be lost and on most cases the FDC will read random values. In theory it is possible to build a sector with some weak bytes and then after, some stable data. I don't recall seeing something like this on the Atari 8-bit. Most if not all sectors with weak bits in our platform are just a demagnetized area, and the drive itself returns only noise.

 

Note that the absence of clock pulses alone doesn't create weak bits. The PLL can correctly recover bytes without clock pulses as long as there is enough data pulses to keep sync.


Edited by ijor, Fri Jul 27, 2018 6:58 PM.


#1286 Zarxx OFFLINE  

Zarxx

    Chopper Commander

  • 104 posts
  • Location:UK

Posted Mon Aug 6, 2018 6:55 AM

Collection 4

 

https://drive.google...GskTXPLfz9Rdkff

 

Small mixed collection, unfortunately most of the disks were liquid damaged and destroyed. 


Edited by Zarxx, Mon Aug 6, 2018 7:03 AM.


#1287 Zarxx OFFLINE  

Zarxx

    Chopper Commander

  • 104 posts
  • Location:UK

Posted Mon Aug 6, 2018 3:19 PM

Rescued these.

 

Juno First.jpg Knightmares.jpg New York City.jpg Phantom.jpg Raid Over Moscow.jpg Summer Games.jpg Zone X.jpg

 

Attached File  Originals.zip   37.8MB   28 downloads



#1288 THX11381973 OFFLINE  

THX11381973

    Space Invader

  • 18 posts

Posted Thu Aug 9, 2018 11:20 AM

Can someone help me. I was wanting to know what page the lastest torrent is on. Thank you Tyler



#1289 Kyle22 OFFLINE  

Kyle22

    River Patroller

  • 3,442 posts
  • Call my BBS! telnet://broadway1.lorexddns.net
  • Location:McKees Rocks (Pittsburgh), PA

Posted Thu Aug 9, 2018 3:55 PM

Magnet URI: magnet:?xt=urn:btih:04DF7F398B1849428CB9075187AE0C4633B0A2E9&dn=Atari8bitPreservedSoftware2018-6-21.zip



#1290 ebiguy OFFLINE  

ebiguy

    Chopper Commander

  • 110 posts
  • Location:Paris, France

Posted Sun Aug 12, 2018 4:07 AM

I have a question about ATX format and Altirra.

Looking at the ATX file format described at a8preservation (http://a8preservation.com/#/guides/atx), I am puzzled with the ATX file generated by Altirra.

I made a new SD disk image in Altirra (3.10 test36), I copied some content in the sector to avoid having an empty disk and saved it as an ATX.

Here is the data I find in ATX:

altirra_atx.png

The question is about this black chunk in the file. I can not find it in the file description. I can guess with the content that it is the size of the 18 sector data.

Is this chuck mandatory ?

And, (not shown on the picture), there is a second empty chuck (8 byte) after the 18 sector data.

If I generate a file without the black chunk and without the empty chunk, Altirra complains about the file format:

altirra_error.png

Any explanation ?


Edited by ebiguy, Sun Aug 12, 2018 4:46 AM.


#1291 Atari_Ace OFFLINE  

Atari_Ace

    Chopper Commander

  • 116 posts
  • https://ksquiggle.neocities.org/
  • Location:Seattle, WA

Posted Sun Aug 12, 2018 9:23 AM

I have a question about ATX format and Altirra.

Looking at the ATX file format described at a8preservation (http://a8preservation.com/#/guides/atx), I am puzzled with the ATX file generated by Altirra.

I made a new SD disk image in Altirra (3.10 test36), I copied some content in the sector to avoid having an empty disk and saved it as an ATX.

Here is the data I find in ATX:

attachicon.gifaltirra_atx.png

The question is about this black chunk in the file. I can not find it in the file description. I can guess with the content that it is the size of the 18 sector data.

Is this chuck mandatory ?

And, (not shown on the picture), there is a second empty chuck (8 byte) after the 18 sector data.

If I generate a file without the black chunk and without the empty chunk, Altirra complains about the file format:

attachicon.gifaltirra_error.png

Any explanation ?

 

Within a track of data are a series of data chunks, each with an 8 byte header (4 byte size, 1 byte type, …).  Your first chunk header (in blue) has size 0x98 and type 1, so it's a sector list.  Your second chunk header (in black) has size 0x908 and type 0, so it contains sector data.  You can't remove that data from the file, it's part of the metadata which defines the track.  Weak bits for instance would show up as a chunk with type 0x10.

 

The description on a8preservation.com isn't 100% accurate.


  • jhd likes this

#1292 Farb OFFLINE  

Farb

    Dragonstomper

  • Topic Starter
  • 645 posts
  • Location:Frankfurt, Germany

Posted Sun Aug 12, 2018 9:33 AM



 
The description on a8preservation.com isn't 100% accurate.


Corrections and suggestions for improvement are highly encouraged. As far as I know, that page is the most complete documentation we currently have for the ATX format that isn't code-based. What specially do you feel isn't accurate?



Sent from my ONEPLUS A6003 using Tapatalk

#1293 Atari_Ace OFFLINE  

Atari_Ace

    Chopper Commander

  • 116 posts
  • https://ksquiggle.neocities.org/
  • Location:Seattle, WA

Posted Sun Aug 12, 2018 10:10 AM

Corrections and suggestions for improvement are highly encouraged. As far as I know, that page is the most complete documentation we currently have for the ATX format that isn't code-based. What specially do you feel isn't accurate?



Sent from my ONEPLUS A6003 using Tapatalk

 

The main omission is that there's no description of the chunk structure and chunk types at all.  The description of the "sector list header" is in fact the chunk header with a type of 1.  There's no requirement that I can see that chunks come in any particular order, although the fact that every ATX out there has type 1, then type 0, ... makes it seem that the format is strict.  You should be able to put the sector data first and then the sector list and still be a valid file.



#1294 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,532 posts
  • Location:USA

Posted Sun Aug 12, 2018 1:15 PM

 

The main omission is that there's no description of the chunk structure and chunk types at all.  The description of the "sector list header" is in fact the chunk header with a type of 1.  There's no requirement that I can see that chunks come in any particular order, although the fact that every ATX out there has type 1, then type 0, ... makes it seem that the format is strict.  You should be able to put the sector data first and then the sector list and still be a valid file.

 

The format allows that but some parsers might not. ATX was originally supported by reverse engineering before the official source code and format spec was revealed, so older parsers may not accept reordered chunks. There were also some files released even under the aegis of the VAPI project that had sector data within the track chunk but not within a sub-chunk.



#1295 _The Doctor__ ONLINE  

_The Doctor__

    River Patroller

  • 4,456 posts
  • Location:10-0-11-00:02

Posted Sun Aug 12, 2018 1:34 PM

time those parsers get repaired and updated.... 

and knowing this piece of info, would or could this play a role in the s-drive max atx could/can support as well in as much as what is serves up and expects


Edited by _The Doctor__, Sun Aug 12, 2018 1:52 PM.


#1296 ijor OFFLINE  

ijor

    River Patroller

  • 2,060 posts

Posted Sun Aug 12, 2018 10:33 PM

There's no requirement that I can see that chunks come in any particular order, although the fact that every ATX out there has type 1, then type 0, ... makes it seem that the format is strict.  You should be able to put the sector data first and then the sector list and still be a valid file.

 

Please don't, at least unless you have a good reason. The specifications might allow that and several other "unusal" things. But IMHO it is wise to follow de facto standard, and common sense, as well.

 

Recently some new embedded implementations are being developed. Some of them operate on very limited hardware resources. The last thing we need is to "unnecessarily" complicate the file processing with unusual format variants. Again, at least unless you have a good reason.


Edited by ijor, Sun Aug 12, 2018 10:44 PM.


#1297 Farb OFFLINE  

Farb

    Dragonstomper

  • Topic Starter
  • 645 posts
  • Location:Frankfurt, Germany

Posted Yesterday, 4:14 PM

The main omission is that there's no description of the chunk structure and chunk types at all.  The description of the "sector list header" is in fact the chunk header with a type of 1.  There's no requirement that I can see that chunks come in any particular order, although the fact that every ATX out there has type 1, then type 0, ... makes it seem that the format is strict.  You should be able to put the sector data first and then the sector list and still be a valid file.

 

 

Ok, here is a proposed update to the ATX page:

 

http://a8preservatio...to/#/guides/atx

 

I have explicitly called out all data chunk structures I am aware of with a warning to the effect that phaeron and ijor mentioned. I have also created an ATX Synalyze It!/Hexinator grammar file that can be downloaded from that page. It should help with ATX file analysis.

 

The following items are still open issues or questions:

 

1. What are the 8 bytes at the end of each track record for? These are all 0 values in the files I inspected.

2. What is the purpose of the extended sector header and what are its possible data values?

3. What is the format of the host data record? This is present in early ATX files (such as Hellcat Ace on Atarimania).

4. There is a slight discrepancy with the data chunks as I've documented them. It has been said that all data chunks start with an 8 byte header. As previously documented, sector list (0x01) and sector data (0x00) chunks have a 4 byte length, 2 byte type and 2 bytes of reserved padding. However, also as previously documented, weak sector data (0x10) and extended sector header (0x11) chunks have a 4 byte length, 1 byte type, 1 byte sector index and 2 bytes of data. To account for this discrepancy in the proposed new documentation, I have defined a data chunk's header as 5 bytes and defined sector list and sector data chunks as starting with 3 bytes of reserved padding. This doesn't feel right so if anyone has a suggestion for a better way to handle it, please let me know.


Edited by Farb, Yesterday, 4:15 PM.


#1298 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,532 posts
  • Location:USA

Posted Yesterday, 9:27 PM

1. What are the 8 bytes at the end of each track record for? These are all 0 values in the files I inspected.


It is the terminator for the track chunk list (size=0).
 

2. What is the purpose of the extended sector header and what are its possible data values?


Bits 0-1 give the actual physical size of a sector for a long sector (0=128, 1=256, 2=512, 3=1024).
 

4. There is a slight discrepancy with the data chunks as I've documented them. It has been said that all data chunks start with an 8 byte header. As previously documented, sector list (0x01) and sector data (0x00) chunks have a 4 byte length, 2 byte type and 2 bytes of reserved padding. However, also as previously documented, weak sector data (0x10) and extended sector header (0x11) chunks have a 4 byte length, 1 byte type, 1 byte sector index and 2 bytes of data. To account for this discrepancy in the proposed new documentation, I have defined a data chunk's header as 5 bytes and defined sector list and sector data chunks as starting with 3 bytes of reserved padding. This doesn't feel right so if anyone has a suggestion for a better way to handle it, please let me know.

The chunk header is 8 bytes, but one of the bytes is a sector index and the two bytes are chunk specific data. The weak sector and extended sector header chunks just use those fields and don't have any additional data.



#1299 Farb OFFLINE  

Farb

    Dragonstomper

  • Topic Starter
  • 645 posts
  • Location:Frankfurt, Germany

Posted Today, 1:48 AM

Thanks, phaeron. I've updated the page link above as well as the grammar file with the info you provided.



#1300 Mclaneinc OFFLINE  

Mclaneinc

    Quadrunner

  • 5,759 posts
  • Location:Northolt, UK

Posted Today, 4:16 AM

Loving the site, the updates are great and the style of not showing overly tech info unless looked for is spot on..You guys should be proud..

 

Its comfy on the eye to the normal user and gives extra intense (and soon to be more detailed) tech info...Perfect for the future and the advanced user..






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users