Re: Help with NIB, PO, and DO?

[Rubywand <rubywand@swbell.net>]

Jeffrey Theusch writes ...
> 
> I am starting work on an ADT-like program called "ADS", Apple Disk
> Server.  It involves using a disk image selector interface and
> transferring the image to a temporary 5 1/4" floppy.  After it is
> booted, a restart of the Apple would result in transferring the temp
> floppy back to its original image file on the PC, updating any
> changes.  Other options would do simple transfers and other ordinary
> "stuff."
> 
> I have most of the operation planned out, but for a few details, I
> need more information to continue:
> 
> 1. A powerful feature of my new application could be the use of a
> variety of image formats, most notably NIB (You can make transfers of
> copy-protected disks and also preserve volume numbering!).  From what
> I now know, NIB is the format containing original disk bytes, right?.
> Therefore, a fairly simple routine could dump these bytes over a
> serial line.  But, how do you do this?  Each track must have a
> starting point and ending point, how do I detect this when the disk is
> spinning?  What order is the NIB disk image in relation to the
> physical disk?  And what about half- and quarter-tracks?  How are
> these managed?  Would a disassembly of Saltine's Super Transcopy help?
> 

     Looking at SST might help answer some of the above.


> 2. I know that .dsk files can possibly be in Prodos Order (.po) or DOS
> Order.  What are these orders,

     A sector ordering is a translation of the particular DOS's sector
naming/numbering to hard sector names/numbers. For DOS 3.3, you have ...

DOS 3.3    Hard 
Sector #   Sector #

  0          0
  1          D
  2          B
  3          9
  4          7
  5          5
  6          3
  7          1
  8          E
  9          C
  A          A
  B          8
  C          6
  D          4
  E          2
  F          F


 

    "DOS 3.3 ordering" in a regular 5.25" .dsk or .do disk image would
arrange the data in the order used by DOS 3.3. Putting this another way, if
you are running DOS 3.3 you can read the disk image file in 256-byte chunks
and write it sequentially (starting with Sector 0 on Track 0),
sector-by-sector and track-by-track.

     Similarly, "ProDOS ordering" places data in a disk image in sequential
512-byte block order. On a 5.25" disk, the ordering is ...


ProDOS          Hard 
half-Blocks    Sector #

  0a             0
  0b             2
  1a             4
  1b             6
  2a             8
  2b             A
  3a             C
  3c             E
  4a             1
  4b             3
  5a             5
  5b             7
  6a             9
  6b             B
  7a             D
  7b             F




     There is a discussion of suffixes and ordering in the FAQs File Utils
page at http://home.swbell.net/rubywand/Csa2FLUTILS.html#006 .


> and how can I detect the difference in disk image files?
>
     Some emulators try to do this for .dsk files (which, technically, can be
DOS 3.3 or ProDOS order).  Not sure what method they use. Possibly, they
assume DOS 3.3 order and run the boot code-- if it bombs, they try ProDOS
order.

     You could check an image for the presence of code normally associated
with DOS 3.3 or ProDOS or assorted DOS 3.3 variants and see if its location
in the image corresponds to DOS 3.3 or ProDOS ordering.

     A simpler approach is to stick with current standards. That is, a 5.25"
disk image name ending with ".po" --> ProDOS ordering. Otherwise, you have
DOS 3.3 ordering. You could allow the user to override these defaults.
  


> 3. Is there any basic info on the 2mg format that could help me
> incorporate it into my application?
>
 ....

     There is a good explanation on A2Central.com  at ...

http://a2central.com/programming/resources/filetypes/ftn-e0.0130.html

The statement: "+$008  Word  The length of this header, in bytes.
Should be 52" seems to be incorrect. The usual value is 40 00 (header length=
64 bytes).


Rubywand