Re: .DSK Image does not work on real machine, but, works fine in an Emulator

[olcott <olcott@qwest.net>]

Rubywand wrote:

> olcott writes ...
> >
> > The solution was to make sure that the target
> > disk was fully INITialized. After I ran INIT
> > on the disk, then copied the image, it worked
> > fine.
>
>      Yes. The ADT (v1.22 readme.txt) directions specify " THE DISK IN SLOT 6
> DRIVE 1 MUST BE 16-SECTOR FORMATTED." Probably, this should be expanded to
> include suggestions of ways to format the disk-- e.g. INITing the disk or using a
> util like Copy II+ to format it.
>

That's the problem. Formatting is not enough.
I formatted it using a version of Prodos, and
this did not work. I am guessing that the
boot sector is not copied in a disk image.
With other disk image files, they are byte-for-byte
copies of EVERYTHING that is on the disk.
Apparently ADT .DSK  image files EXCLUDE
the boot sector.

>
> > Before I ran INIT the disk would neither
> > boot, nor run correctly after booting from
> > another disk. I guess that if the boot sectors
> > are not used, then ADT copies data to them,
> > even though the file system can not access these
> > sectors. This is ONLY a guess.
> >
>  ....
>
>      ADT will replace the entire data contents (143,360 bytes) of the target
> disk-- i.e. all 16 sectors on every track (0-34)-- with the contents of the disk
> image file. It writes the first 256-byte group of bytes in the image to Track 0
> at the sector DOS 3.3 identifies as "Sector 0". The next 256-byte group goes to
> "Sector 1", etc..
>
>      ADT does not try to change the formatting of the target disk. So, if there
> is something odd about the format which does not cause an outright error during
> the transfer, the image may well get transferred; but, you can end up with a disk
> that bombs when booted. One relatively common problem is a Volume Number
> conflict.
>
>      Volume Number information is not preserved in a .dsk disk image. All .dsk
> DOS 3.3 ordered disk images, in effect, have the default Volume Number (254)
> because this is the Volume Number assumed by emulators. (If a particular game,
> etc. depends upon special Volume numbering to identify the disks it uses, it will
> not run correctly from .dsk on an emulator.)
>
>      Some programs may insist that the Volume Number of the disk from which they
> start be 254. (For instance, this could be a way to make sure you are using a
> 'working copy' instead of the 'Master Disk'.)  Other programs may have been
> modified for use on emulators so that the Volume Number looked for as part of
> some protection check is 254.
>
>      If a program which actually insists that the Volume Number be 254 is
> transferred to a diskette which happens to have some other Volume Number, then,
> the program may bomb when started from the diskette on a real Apple II.
>
>      Anyway, it's a good idea to INIT HELLO target diskettes for ADT transfers.
>

MOre than a good idea, I think that it is required.

>
> Rubywand