Re: 2mg Image Is A Bad Idea?

["Terry & Utahna Olsen" <tolsen64@nospam.boycot.dns2go.com>]

Is there an Apple II program that can create/extract 2mg images????

"Charlie" <charlied@NOSPAMbboard.com> wrote in message
ajot1t01u9p@enews2.newsguy.com">news:ajot1t01u9p@enews2.newsguy.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
>
>