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

[Rubywand <rubywand@swbell.net>]

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.


> 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.



Rubywand