f



Any utility to convert TrackStar board emulator Disk images to Emulator image files??

Hello,

I was curious to see if anyone had written a utility to convert
TrackStar board emulator Disk images to regular disk images that would
work on one of the Apple IIe emulators??  I was going to try and use
the ADT utility and a serial cable to make images of my disks but if
there is a utility that can convert the TrackStar images that would be
much easier.  If you know of one please let me know.

Best Regards,

Robert
0
rdoerr (21)
4/23/2004 5:09:57 PM
comp.sys.apple2 11066 articles. 4 followers. antoine.vignau (1077) is leader. Post Follow

11 Replies
852 Views

Similar Articles

[PageSpeed] 11

"Robert L. Doerr" writes ...
> 
> Hello,
> 
> I was curious to see if anyone had written a utility to convert
> TrackStar board emulator Disk images to regular disk images that would
> work on one of the Apple IIe emulators??  I was going to try and use
> the ADT utility and a serial cable to make images of my disks but if
> there is a utility that can convert the TrackStar images that would be
> much easier.  If you know of one please let me know.
> 
 ....

     Haven't heard of a utility to change TrackStar disk images to any of the
currently popular disk image formats.



Rubywand
0
rubywand (454)
4/26/2004 4:58:05 PM
> > I was curious to see if anyone had written a utility to convert
> > TrackStar board emulator Disk images to regular disk images that would
> > work on one of the Apple IIe emulators??  I was going to try and use
> > the ADT utility and a serial cable to make images of my disks but if
> > there is a utility that can convert the TrackStar images that would be
> > much easier.  If you know of one please let me know.
> > 
>  ....
> 
>      Haven't heard of a utility to change TrackStar disk images to any of the
> currently popular disk image formats.

Thats too bad.  If that utility existed then it would be very easy to
transfer
regular Apple II disks for use in the emulator ans vise/versa.  On
that note are you aware of any websites or documents that cover both
the Trackstar image format and the Emulator disk format?  With that it
might be possible to create a utility to do the conversions.

On a side note I am also looking for an emulator which runs on a PC
that also
emulates the SuperSerial port.  I've tried the Apple IIe emulator for
Windows (v1.12.3) which looks excellent but it only supports the
regular Serial Port.  Are there any other recommended emulators out
there with SuperSerial support?

Robert
0
rdoerr (21)
4/29/2004 6:57:17 PM
On a related topic: has anybody seen specs for DDD Deluxe 5.0 archives?
Or done a disassembly of the code?  (Or know where Louis Roy is?)

I have a few archives from back before ShrinkIt got popular.  It had some
nice features, and I think it packed disks more tightly than the original
DDD, but it didn't work as well as ShrinkIt and got left behind.

-- 
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/
0
fadden (547)
4/29/2004 11:24:27 PM
someone give me the specs/format of the trackstar disk images and i'll
write one.  :)
0
me6490 (12)
4/29/2004 11:38:39 PM
"Lazarus I. Long" <me@lazilong.com> 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


0
charlied1 (47)
4/30/2004 12:30:03 AM
"Charlie" <charlied@NOSPAMbboard.com> wrote in message news:<c6s6lb01cid@enews3.newsguy.com>...
> "Lazarus I. Long" <me@lazilong.com> 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


I played with this a year ago and haven't touched it since:

Each image contains 40 tracks, each 0x1A00 bytes long.  The format is
as follows:

1A00 Next track 
19fE WORD containing the number of nibbles in the track or 0
..
..    Nibble data backwards
..
0080 start of nibble data
0000 Contains trackstor description


If the the word at 19fE is 0 start reading backward at 19FD till
you hit a nibble where the high bit is 0.

Here is quick and dirty code that I added to Applewin to read app
disks.
(You will have to add a little more code to hook it up)

/****************************************************************************
*
*  NIBBLIZED Trackstar(APP) 40 Track FORMAT IMPLEMENTATION
*
***/

//===========================================================================
DWORD AppDetect (LPBYTE imageptr, DWORD imagesize) {
  return (imagesize == 266240) ? 2 : 0;
}


BYTE AppScratch[0x1a00];

//===========================================================================
void AppRead (imageinfoptr ptr, int track, int quartertrack, LPBYTE
trackimagebuffer, int *nibbles) {
  WORD TrackStart;
  int nibcount=0;
  BYTE *pNib;
  SetFilePointer(ptr->file,ptr->offset+track*0x1a00,NULL,FILE_BEGIN);
  ReadFile(ptr->file,AppScratch,0x1a00,(DWORD *)nibbles,NULL);

  TrackStart = *(WORD *)&AppScratch[0x1a00-2];

  if (TrackStart)
  {
	TrackStart+=0x80;
	pNib=&AppScratch[TrackStart];
  }
  else
  {
	pNib=&AppScratch[0x1a00-3];
  }

  while (*pNib & 0x80)
  {
	*trackimagebuffer++= *pNib--;
	nibcount++;
  }

  *nibbles = nibcount;
}


You can add a write routine similarly.  A dsk2app utility should be
similar.  I have one somewhere if it is needed. I had pretty good luck
reading unprotected disks with the Trackstar.  Some copy protected
disks worked as well. I also reverse engineered parts of the Trackstar
software.  The Trackstar E software will work with older versions of
the Trackstar hardware with minor modifications. It is a pretty cool
piece of software/hardware.


I have been looking for a Trackstar E for quite a while.  If anyone
wants to sell me one or talk about the Trackstar feel free to send me
mail.
0
4/30/2004 2:31:16 PM
"Gerald Ryckman" <geraldryckman@hotmail.com> wrote in message
news:3a4a177d.0404300631.405603eb@posting.google.com...

> I played with this a year ago and haven't touched it since:
>
> Each image contains 40 tracks, each 0x1A00 bytes long.  The format is
> as follows:
>
> 1A00 Next track
> 19fE WORD containing the number of nibbles in the track or 0
> .
> .    Nibble data backwards
> .
> 0080 start of nibble data
> 0000 Contains trackstor description
>
>
> If the the word at 19fE is 0 start reading backward at 19FD till
> you hit a nibble where the high bit is 0.

Ok, this I didn't know about.

> Here is quick and dirty code that I added to Applewin to read app
> disks.
> (You will have to add a little more code to hook it up)
>
>
/**************************************************************************
**
> *
> *  NIBBLIZED Trackstar(APP) 40 Track FORMAT IMPLEMENTATION
> *
> ***/
>
>
//=========================================================================
==
> DWORD AppDetect (LPBYTE imageptr, DWORD imagesize) {
>   return (imagesize == 266240) ? 2 : 0;
> }
>
>
> BYTE AppScratch[0x1a00];
>
>
//=========================================================================
==
> void AppRead (imageinfoptr ptr, int track, int quartertrack, LPBYTE
> trackimagebuffer, int *nibbles) {
>   WORD TrackStart;
>   int nibcount=0;
>   BYTE *pNib;
>   SetFilePointer(ptr->file,ptr->offset+track*0x1a00,NULL,FILE_BEGIN);
>   ReadFile(ptr->file,AppScratch,0x1a00,(DWORD *)nibbles,NULL);
>
>   TrackStart = *(WORD *)&AppScratch[0x1a00-2];
>
>   if (TrackStart)
>   {
> TrackStart+=0x80;
> pNib=&AppScratch[TrackStart];
>   }
>   else
>   {
> pNib=&AppScratch[0x1a00-3];
>   }
>
>   while (*pNib & 0x80)
>   {
> *trackimagebuffer++= *pNib--;
> nibcount++;
>   }
>
>   *nibbles = nibcount;
> }
>

Thanks for the code.  I'll compare it with mine to see what I did wrong.

> You can add a write routine similarly.  A dsk2app utility should be
> similar.  I have one somewhere if it is needed. I had pretty good luck
> reading unprotected disks with the Trackstar.  Some copy protected
> disks worked as well. I also reverse engineered parts of the Trackstar
> software.  The Trackstar E software will work with older versions of
> the Trackstar hardware with minor modifications. It is a pretty cool
> piece of software/hardware.

> I have been looking for a Trackstar E for quite a while.  If anyone
> wants to sell me one or talk about the Trackstar feel free to send me
> mail.

Sorry, I can't help you.  I've never even seen a Trackstar (E or
otherwise).

Charlie



0
charlied1 (47)
4/30/2004 5:19:43 PM
This sounds remarkably similar to the Nib image format...  Just strip 
the header and extra tracks and reverse each track's byte order.

Hmm.
Thankx,
Ed

Gerald Ryckman wrote:
> Each image contains 40 tracks, each 0x1A00 bytes long.  The format is
> as follows:

0
noone (9909)
4/30/2004 6:57:09 PM
In comp.sys.apple2 Gerald Ryckman <geraldryckman@hotmail.com> 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/
0
fadden (547)
4/30/2004 10:33:10 PM
ok..i've no idea what you guys are discussing...but if you get this to work
let me know ...i have a trackstar e and prob could use a util like this
if/when you get it tweaked

i'm currently trying to backup all my stuff and make it avail utils etc for
all my apple stuff...so if it works i'd throw in any trackstar stuff in the
process

but again i don't program...so if yo do get this to work.remember a lot of
us are dense

brad
former sysop lost-gonzo.com




"Andy McFadden" <fadden@fadden.com> wrote in message
news:GuAkc.9075$Fo4.114255@typhoon.sonic.net...
> In comp.sys.apple2 Gerald Ryckman <geraldryckman@hotmail.com> 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/


0
mrbrad (130)
5/1/2004 4:06:22 AM
> Here is quick and dirty code that I added to Applewin to read .app disks.

seems pretty simple.  just .nib format reversed with extra meta data right?

can someone send me a .app disk image or five so I can test with them?
0
me6490 (12)
5/11/2004 10:35:28 PM
Reply: