Re: 2mg Image Is A Bad Idea?

["Charlie" <charlied@NOSPAMbboard.com>]

"Bryan Parkoff" <BParkoff@satx.rr.com> wrote in message
news:i2P79.205479$6Z1.9524608@bin6.nnrp.aus1.giganews.com...
> 2mg Image Is A Bad Idea?

I disagree, from my point of view I wish that it was the only format for disk
images.  It solves most if not all of the problems associated with the other
formats.  For instance "write protected disks" can easily be determined by a
flag in the header. It also allows for adding information to the image that
might be of help with an emulator or disk image utility in decoding non
standard DOSes.

The dsk images found on the internet are an anarchy of different formats all
under the same .dsk extension.  For instance there are ProDOS dsk images that
are DOS ordered, ProDOS dsk images that are DOS ordered, DOS 3.3 images that
are DOS ordered and I have even seen DOS 3.3 images that are ProDOS ordered.
There are also a few dsk images that have headers.  I even recently saw a DOS
3.3 dsk image that was patched to use 40 tracks but had only enough room for
the normal 35.

>     I understand that 2mg Image is truly RAW sector.  I assume that it is
> very bad idea because RAW Image can't determine the number of sectors in the
> different orders.  I understand that ProDOS is in sequence order and DOS 3.3
> is in sequence of skipping 4 sectors before jumping back to next 4 sectors.
> I know that it is the way how ProDOS and DOS 3.3 behave differently like
> Pascal.  I am aware that RAW Image DOES have flag, but it is not ALWAYS
> work.

The 2mg format does allow RAW images but these are rare.  Most 2mg images are
DOS or ProDOS ordered.

>     The better way is to write a different routine that allow to read track
> 0 and sector 0.

I believe this is essentially what emulators do with raw images. They emulate
the original Apple II boot code.  A disk image utility that runs on a PC
doesn't have this luxury.  To do what you suggest would mean reverse
engineering each different scheme on the fly.

>Track 0 and sector 0 might have some data that will let the
> routine know which to read sequence order of sectors or sequence order of
> next 4 sectors.

In raw images the sector order can be determined by reading and decoding the
address field nibbles for the sectors.  The operating system on a bootable disk
"knows" how to do this.  The way ProDOS and DOS 3.3 do this is documented.  The
way it is done on copy protected disks is of course kept secret if it has
anything to do with the protection scheme.

>     For example, some Apple II games use DOS 3.3, but it is not truly DOS
> 3.3 such as Sierra games.  I did remove copy-protected and used DSK2File to
> convert from Sierra game floppy diskette into Sierra.Dsk before I
> transferred Sierra.Dsk to PC.  Neither XGS nor KEGS fail to read Sierra.Dsk
> because it can't be so sure if sectors are in orders.

Are you sure this is why the images didn't work.  There are some copy
protection schemes, such as nibble counting would be very hard to get to work
with raw images.  All the raw images (.nib) that I have seen use the same track
length for each track, something that doesn't exist on a real disk.

Charlie