Re: How to make .nib disk images?

[Rubywand <rubywand@swbell.net>]

Ron Kneusel writes ...
> 
> Rubywand wrote:
 ....
> 
> Basically, I want to add .nib format creation to DSK2FILE.  I can read
> the raw track data easily enough but what I lack is information on how
> to package that data into a .nib format disk image.  For example:
> 
> -- How many self-sync bytes to include between tracks, address fields,
> data fields?

     A good source of info is looking at a .nib file of a standard (non-
protected) DOS 3.3 disk with a hex editor. (That plus the good old
"Beneath Apple DOS" book by Worth and Lechner!)

     Since reads are automatically synced (the software is, necessarily,
reading bytes), self-sync bytes are just FF's.

     There are 5 FF's between the Address field and Data field. (Also, 
the Address field seems to omit the EB from the usual DE AA EB epilogue.)

     Each Sector seems to be 367 ($16F) bytes long:

Address field-  13 bytes
FF's-            5 bytes

Data field-
  Prologue       3 bytes
  Encoded Data 342 bytes
  Checksum       1 byte
  Epilogue       3 bytes

Total          367 bytes


     Each Track is 6656 ($1A00) bytes long.

     The usual number of FF's between sectors seems to 45 or so; sometimes
a little more.

     There is no separation between tracks. (No need since length is fixed.)



> -- Is there an expectation that the .nib image start with the address
> field header for track 0 sector 0?

     No. Sectors appear to be in genrally ascending order; but, the block of
bytes for a track can begin with any sector. Frequently, a track begins in 
the middle of a sector. (Tracks are circular; so, it doesn't matter.)


> This part of every bootable disk is "normal" (for the most part)
> otherwise the disk controller couldn't read the disk.

     DOS can use Address field info to locate sectors in each block of
track bytes.


> -- Must each track be a set number of bytes long?

     Seems like each track must be 6656 ($1A00) bytes long. This fits since
6656 x 35 = 232,960 bytes, the usual size of a .nib image.

 
> These are the sorts of questions I'm looking to answer.  Perhaps I am
> making the problem more difficult than is necessary.  The disks I want
> to make images of are not particularly well protected, for the most part
> they only permute the address and data field header bytes.  No sync'ed
> tracks or half-tracks.

     Don't know how emulation deals with synced tracks-- might not be a
problem. Half tracks don't sound like they should be difficult to deal
with as long as the total number of tracks does not exceed 35.

     A big problem for the .nib format seems to be tracks that are
longer than usual. I think that's what defeats coming up with a good
.nib image for Infocom's "Trinity".


Rubywand