"Lazarus I. Long" wrote in message news:68a2ec1b.0404291538.ace5c61@posting.google.com... > someone give me the specs/format of the trackstar disk images and i'll > write one. :) Hi Laz, I have never been able to find any official specs/format information on trackstar disk images. As I mentioned I tried reverse engineering images I found on the net. After digging around I found some old notes that I made a while back. Here is what I wrote: -------------------------------------- What I know (or think I know): Trackstar disk images have the ".app" MS-DOS file name extension. They can be either ProDOS or DOS 3.3. Everyone I have seen is 266,240 bytes long. This is enough room for 40 tracks, each 6656 bytes long. Usually only the standard 35 tracks are formatted. Each track has a 128 byte header that is not encoded. This header usually contains some ASCII text, but is mostly filled with zeros. The rest of the track is encoded. The encoding used seems to be the normal 4-4 nibble encoding for the address fields and 6-2 encoding for the data fields except that everything is written in descending order. That is, when reading data the last nibble of the trackstore track is the first one read. The tracks themselves are placed in ascending order from the beginning of the image. The physical sectors are in a descending order that "wrap around" as if they were on a real disk where the start of the track could be anywhere. When read the sectors must be skewed (interleaved) of course. I believe Pascal skewing is used! Trackstar images use the normal prologue and epilogue bytes but some disk images allow one data field epilogue to be overwritten by the 128 header mentioned above. Inexplicably, on some images there is an occasional address field that is written in ascending order although these seem to serve no purpose and are not always associated with a data field. In a normal 35 track disk there should be 560 address fields and 560 data fields. Unfortunately, every Trackstar image that I have found contains less than 560 address fields and even fewer data fields. Note this is using a routine that counts an address or data field only if it has the proper 3 prologue bytes and the first two epilogue bytes. Here is a list of the images I have (the numbers indicate the address & data fields that my routine detects): Name Address Data OS BLEEP.APP 0 0 ? COPYII.APP 559 532 ProDOS dosutils.app 558 530 DOS filetrn.app 544 512 ProDOS pdutiles.app 558 530 ProDOS SAMPLRAW.APP 555 525 ProDOS startup1.app 0 0 ? STARTUP2.APP 162 9 ? ------------------------------------------------------------- Obviously, I was doing something wrong, but I never figured out what. Someday maybe I'll go back and try again. So many formats, so little time. Charlie In comp.sys.apple2 Gerald Ryckman wrote: > You can add a write routine similarly. A dsk2app utility should be > similar. I have one somewhere if it is needed. [...] Converting a .do file to a .app file should be pretty easy. Converting a .nib file to a .app file could be tricky, because (if I understand this correctly) the maximum length of a TrackStar track is 6656 minus the 128 byte header, the 2 byte length indicator, and a 1 byte "this is where the track stops" value. For example: 0000000: 444f 5320 332e 3320 5359 5354 454d 204d DOS 3.3 SYSTEM M 0000010: 4153 5445 5220 2020 2020 2020 2020 2020 ASTER 0000020: 2020 2020 2020 2020 2020 2020 2020 0000 .. 0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000080: 0096 9796 9b96 9796 9b96 979b 9696 9696 ................ 0000090: 9696 9696 9696 9696 9696 9696 bdcf bcd6 ................ 00000a0: d6d6 a7ce d6f5 daf7 e7f5 dcf7 cbf5 adfe ................ 00000b0: fedc aebe bace fb9b dc9d dcd9 eebb f3b2 ................ 00000c0: f4d3 eab4 a6e6 f9ff abf4 f6ee f9d9 e7eb ................ 00000d0: d9d3 bef3 a7f4 d3ea f3da e6f9 ffab ead9 ................ 00000e0: d3be b4bb acdf eaf2 daed d7fa e7f7 f7d6 ................ 00000f0: f4eb ecf9 f6d9 d7db d9d3 bef3 a7bb bdd6 ................ 0000100: a7ce ebe5 a6eb e5a6 ebe5 bef7 bcfa ddea ................ [...] 0001900: fbeb cd9a ceb7 baed f7da dae6 bfb4 adcb ................ 0001910: b4ad b9cb e9ad 9b97 969b 9b96 979b ade9 ................ 0001920: cbb9 adb4 cbad b4bf e6da daf7 edba b7ce ................ 0001930: 9acd ebfb b6e5 ffbb e5ff bbb6 b4cf d3e6 ................ 0001940: b2de b6b4 bcb9 d6af e6e6 ebaf afdd af9e ................ 0001950: e6dd dfb5 efea aede aaeb ffff ffff ffff ................ 0001960: ffff ffff ffff ffff ffff ffff ffff ffd5 ................ 0001970: aa96 fffe aaaa aeaf fbfb deaa ebff ffff ................ 0001980: ffff ffd5 aaad cef6 b5dd facd f4f3 fcb2 ................ 0001990: adaf a6e6 e5ef f69e aeaf abb3 eceb da9e ................ 00019a0: 9fb6 b9ea dade f7b7 969a 9eba cdcd 9af6 ................ 00019b0: ebdf 96d6 f3bd b3ef f5b2 fcef cfd6 edf2 ................ 00019c0: edb6 efe6 d6dd ae9b fcb3 fb9f b3e5 deae ................ 00019d0: 97af e9ec ac96 d7ba fcaf bedc cdbe f6eb ................ 00019e0: cfed dee6 dace f2eb bef6 ddb7 f4eb cbf4 ................ 00019f0: dee6 dabd f5de e7d9 bdf5 ddb6 f3ec 9918 ................ 0001a00: 444f 5320 332e 3320 5359 5354 454d 204d DOS 3.3 SYSTEM M 0001a10: 4153 5445 5220 2020 2020 2020 2020 2020 ASTER 0001a20: 2020 2020 2020 2020 2020 2020 2020 0000 .. 0001a30: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0001a40: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0001a50: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0001a60: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0001a70: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0001a80: 009a 9db7 aed3 aea7 9db7 aed3 979e 9eff ................ 0001a90: bae7 e7db cdba a6ff ceda ceba dfe9 b3de ................ Note the value at $80 is zero. The gunk from $191a through $19fd inclusive is garbage, which explains the d5aa96/d5aaad occurrences in forward order. The maximum .app track length is 6525. A 6656-byte .nib image uses all $1a00 bytes. Some emulators also support 6384-byte ($18f0) .nib images; this is the minimum necessary to hold a track (using the gap widths employed by the DOS 3.3 format routine), and was sometimes used when converting .do to .nib. It should be possible, of course, to convert a .nib to .do and then .do to .app, but that would lose the data that made storing the image in .nib format worthwhile in the first place. In theory some portion of the track image in a .nib file will overlap. Because of the way the tracks get created, it's not guaranteed that the overlap is aligned with the start of the track in the image file. If the nib image was created from a .do file, it probably doesn't have any overlap, but rather a large FF region. Bottom line: converting .app to .nib or .do should be straightforward. Converting .do to .app should be straightforward. Converting .nib to .app without loss of data looks hard. -- Send mail to fadden@fadden.com (Andy McFadden) - http://www.fadden.com/ CD-Recordable FAQ - http://www.cdrfaq.org/ CiderPress Apple II archive utility for Windows - http://www.faddensoft.com/ Fight Internet Spam - http://spam.abuse.net/spam/ & http://spamcop.net/