Re: DOS 3.3 Image Does Not Work on XGS

[Rubywand <rubywand@swbell.net>]

Charlie writes ...
> 
 ....

>>
Ok, first let me say that I'm not too familiar with XGS.  I have used it a few
times in the past but I believe that Kegs32r3 is so much better that I never
went back.  With that in mind I ran the SuperQuest 2mg image on Kegs32r3 first
to see how it was supposed to run.  It worked fine,
<<

Glad the image worked. Thanks for testing it.

>>
which means that afterreading the introduction, naming and setting up
my character, etc, and enteringthe maze, I was killed in a matter of a few 
seconds.  This is normal for me in games. <sigh>
<<

That's pretty normal for most newbies to the game. It takes a little time to 
learn the ropes.

>>
I then tried the same in XGS.  It also worked but I did not know how to set the
speed in XGS to 1MHz so instead of lasting for a few seconds I lasted for a few
milliseconds.
<<

LOL! No wonder. The game is a good challenge at 1MHz.

>>
One thing I should mention though.  If the point of the experiment was that you
could just add the 64-byte 2mg prefix to any .dsk image to make a .2mg image,
then be careful.
<<

Yes; that was the point of the experiment.

>>
For one thing the two original 2mg images that you created with Asimov2 were
NOT exactly the same.  Byte $0C (zero based) of the 64 byte header is $00 for
TNILUTIL.2mg and $01 for PDUTIL.2mg.  $00 = DOS sector order, $01 = ProDOS
order.
<<

Good. Didn't notice that! There's also a format $02 = nib images.

>>
There are also several offsets in the header that you have to pay
attention to.  One points to the start of the data which does not necessarily
have to start at the 65th byte.  Two other offsets point to optional
information that could be before or after the actually image data.  Of course
in the header you used the first offset did point to the 65th byte and the
other offsets were zeroes (not used)
<<

Yes; checked the file length to make sure just the usual 64-byte header was
added.

>>
and you picked the DOS ordered header for
the DOS ordered .dsk image so everything worked.
<<

That was a good piece of luck.

>>
Another possible problem is
that there are flags in the header for write protecting the image (needed
for some disks) and for DOS 3.3 volume number which is sometimes needed for
the disk to work.
<<

Which may be a problem using current 2MG creation utilities. Neither 
ASIMOV 2.0 nor Imaker 2.0 creates 2MG images which preserve non-default
(like VN= 29) DOS 3.3 volume numbering.

ASIMOV 2.0 allows creation of DOS 3.3 and ProDOS ordered 5.25" 2MG images.
However, even if the source disk is identified as DOS 3.3 and you select 
DOS 3.3 ordering, the volume number is ignored.

Imaker creates only ProDOS ordered 2MG images. It also ignores DOS 3.3
volume number (which it should since, according to the description of 
the 2MG header, only DOS 3.3 ordered images may have the volume number
specified).

I guess you could use ASIMOV 2.0 to create a DOS 3.3 ordered 2MG image of
a 5.25" DOS 3.3 diskette. Then, use a hex editor (e.g. BlockWarden on A2)
to add special volume number info. Or you could add a stock DOS 3.3 header
to a typical .dsk image and edit in the volume number on PC.

Seems likely that XGS and Kegs32 would be able to create DOS 3.3 2MG images
which preserve volume numbering, too.

>>
Another quirk that I have noticed is that there are two versions of the 2mg
format, 0 and 1 (the version number is also in the header).  I am unsure of
what the differences are and if they have any affect on the normal operations
in XGS or Kegs32.
<<

Don't know about Version 0. Think all the headers I've checked have been
Version 1.



Rubywand