Trackstar format info

[peterferrie]

The value at $19FE is the length (n) of the backwards-encoded part that begins at $0081. The bytes following $0081+n are encoded forwards, A length of zero means that the entire track is backwards (track length couldn't be determined). The value at $0080 is 1 in all of the 80-track images that I have.

[fadden]

I have half a dozen .app image files that I don't actually remember where they came from. They all seem to look something like this:

000000: 4d 65 72 6c 69 6e 20 36 35 30 32 20 4d 61 63 72  Merlin 6502 Macr
000010: 6f 20 41 73 73 65 6d 62 6c 65 72 20 20 20 20 20  o Assembler     
000020: 20 20 20 20 20 20 20 20 20 20 20 20 20 20 00 00                ··
000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ················
000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ················
000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ················
000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ················
000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ················
000080: 00 b3 e7 f3 d3 b7 df f3 96 fc f3 bc e6 dc b4 a6  ·3gsS7_s·|s<f\4&
000090: a6 96 e9 ed b4 be ad aa d5 ff ff ff ff ff ff ff  &·im4>-*U·······
0000a0: ff eb aa de fe fe aa ab aa aa fe ff 96 aa d5 ff  ·k*^~~*+**~··*U·
0000b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff eb  ···············k
0000c0: aa de 97 ff af e5 f4 ac ea eb f3 b7 d3 f4 e9 fb  *^··/et,jks7Sti{
0000d0: fd d3 ea f7 d9 9f 96 fc fc f9 cf b6 f4 f9 cf a7  }SjwY··||yO6tyO'
  ...
0019e0: fc d9 cd fe 97 fd fc ae af fc fd 97 fd fc 97 fd  |YM~·}|./|}·}|·}
0019f0: fc db bb 9b bb af e6 ab ed d9 bb b3 bc cd 6c 18  |[;·;/f+mY;3<Ml·
001a00: 4d 65 72 6c 69 6e 20 36 35 30 32 20 4d 61 63 72  Merlin 6502 Macr

Is there a collection of useful test files I can grab? Maybe some examples that exhibit greater variety?

[peterferrie]

Is there a collection of useful test files I can grab? Maybe some examples that exhibit greater variety?

I can put you in touch with someone who owns an actual card and has been producing images for me.

[peterferrie]

If you send me an e-mail, I will forward you his message.

[fadden]

I poked at this a little today, specifically with regard to the "slow disk" phenomenon mentioned on http://www.diskman.com/presents/trackstar/. I grabbed one of the games from the TS01PACK collection (Threshold, TRSHOLD.APP) and compared it to an image CiderPress generated from a DSK. The results were pretty similar. Showing track lengths and raw sector numbers:

TRSHOLD.APP: Track $00: len=0x184c: 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 Track $01: len=0x184c: 06 07 08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 04 05 Track $02: len=0x184c: 0b 0c 0d 0e 0f 00 01 02 03 04 05 06 07 08 09 0a Track $03: len=0x184c: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f

ThreshConv.APP: Track $00: len=0x18f0: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f Track $01: len=0x18f0: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f Track $02: len=0x18f0: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f Track $03: len=0x18f0: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f

The CiderPress track is slightly longer. CP puts 27 sync bytes between the end of a track and the start of the next address header, while the TS01PACK image only has 12. CP generates a 48-byte initial sync field, while the TS01 track I looked at had 120.

The interesting difference is in the sector start. The TS01 version reflects the rotation of the disk, while CP just starts at zero on each track. The skew is the same on both. So if Trackstar is modeling the rotation of the drive, reads from consecutive tracks might be slower. But I'm not understanding why random access would be slower.

FWIW, my other test files show some variability in track length, e.g.: Track $00: len=0x1869: 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 00 01 02 03 Track $01: len=0x186a: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f Track $02: len=0x186c: 0d 0e 0f 00 01 02 03 04 05 06 07 08 09 0a 0b 0c Track $03: len=0x186c: 09 0a 0b 0c 0d 0e 0f 00 01 02 03 04 05 06 07 08

Anyway. Have you noticed any compatibility issues, or was this just to fill in the knowledge gaps demonstrated in the comments in the CP source code?

Also, with regard to:

The bytes following $0081+n are encoded forwards

Are those bytes supposed to be used for something? I figured it was junk left over from reading the track that they didn't bother to zero out.

(scan program: scan.c.txt)

[peterferrie]

The interesting difference is in the sector start. The TS01 version reflects the rotation of the disk, while CP just starts at zero on each track. The skew is the same on both. So if Trackstar is modeling the rotation of the drive, reads from consecutive tracks might be slower. But I'm not understanding why random access would be slower.

Yes, the random access slowdown doesn't make much sense.

Anyway. Have you noticed any compatibility issues, or was this just to fill in the knowledge gaps demonstrated in the comments in the CP source code?

No issues, just filling in the gaps.

Also, with regard to:

The bytes following $0081+n are encoded forwards

Are those bytes supposed to be used for something? I figured it was junk left over from reading the track that they didn't bother to zero out.

When extracting files from the images, I found that those bytes were needed in order to construct the right thing. The end of the backwards part continues immediately with the forwards part.

[fadden]

Format is now documented here: https://github.com/fadden/CiderPress2/blob/main/DiskArc/Disk/Trackstar-notes.md