Atari 8-bit Software Preservation Initiative

[ebiguy]

 

 

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

 

http://a8preservation.com/#/software/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 ?

[+remowilliams]

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

 

https://mega.nz/#F!NolQwaBZ!Z7slHdxUBMxtRh4MVYcp9w

[ebiguy]

 

 

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

 

http://a8preservation.com/#/software/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

[ijor]

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 July 22, 2018 by ijor

[ijor]

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.

[Wilheim]

Hi! Seeding the zip file. Thanks!

[ebiguy]

 

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 ?

 

[ebiguy]

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 ?

[ijor]

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

[ijor]

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 July 28, 2018 by ijor

[Zarxx]

Collection 4

 

https://drive.google.com/open?id=1S9n8krGzWOJQirKp-GskTXPLfz9Rdkff

 

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

Edited August 6, 2018 by Zarxx

[Zarxx]

Rescued these.

 

 

Originals.zip

[THX11381973]

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

[Kyle22]

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

[ebiguy]

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:

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:

Any explanation ?

Edited August 12, 2018 by ebiguy

[Atari_Ace]

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 ?

 

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.

[Farb]

 

 

 

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

[Atari_Ace]

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.

[phaeron]

 

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.

[_The Doctor__]

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 August 12, 2018 by _The Doctor__

[ijor]

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 August 13, 2018 by ijor

[Farb]

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://a8preservation.com/proto/#/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 August 13, 2018 by Farb

[phaeron]

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.

[Farb]

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

[Mclaneinc]

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..