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

[geraldryckman@hotmail.com (Gerald Ryckman)]

"Charlie" <charlied@NOSPAMbboard.com> wrote in message news:<c6s6lb01cid@enews3.newsguy.com>...
> "Lazarus I. Long" <me@lazilong.com> wrote in message
> 68a2ec1b.0404291538.ace5c61@posting.google.com">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.