Re: Question about DOS33.DMP

[Rubywand <rubywand@swbell.net>]

Mac Guillet writes ...
> 
> I have the two machines talking, code does appear on the IIgs screen but
> after only a few minutes (of the reported 20) it stops with "Not a startup
> disk!" on the screen.
> 
 ....

     Did some tests using the Dos33.dmp file you get via links on the GS
WorldView page about getting DOS 3.3.  (The Dos33.dmp file you get from
Ground at ftp://ground.ecn.uiowa.edu/apple2/upl2000/Mar/ is identical to the
Dos33.dmp file available from GSWV.)

     The file Dos33.dmp was transferred to our IIgs three times using
Hyperterm:

1. 300 baud (line delay= 40ms; IIgs accelerated; 80-col display)

2. 300 baud (line delay= 40ms; IIgs not accelerated; 80-col display)

3. 2400 baud (line delay= 40ms; IIgs not accelerated; 40-col display)


     In the first two cases, transfer time was about 16 minutes. In the third
test, transfer time was a little more than 3 minutes.

     In each case, the diskette in the 5.25" drive (Slot 6, Drive 1) was a
new blank 5.25" DD diskette. Each time, INIT HELLO was entered when the
transfer ended and the diskette INITed with no problem. Each diskette booted
fine and DOS 3.3 responded to commands like CATALOG, RUN, and SAVE.

     So, I'm pretty sure the Dos33.dmp file you get when you download and
unzip the .zip file is okay.

     The Hyperterm settings for 300 baud are the ones described in the FAQs
at http://home.swbell.net/rubywand/Csa2T1TCOM.html#020 . The main difference
between the settings in the Dos33dmp.zip directions file and the ones in the
FAQs is that line delay is set at 40ms instead of 400ms. This is because
400ms is unnecessarily long and just slows down the transfer for no good
reason.

     Hyperterm settings for the 2400 baud transfer were the same as for the
300 baud transfer except for the difference in baud rate. Although the 2400
baud transfer worked fine, sticking with 300 baud is probably a good idea.
You only need to do the transfer once. The fact that the transfer seems to
work okay at 2400 baud serves mainly to underline the reliability of doing
the transfer at 300 baud.


     The fact that your transfer glitched mid-way suggests that you did not
start with a 'blank system'.

     For example, if you were under ProDOS, you would start with the I/O
vectors at $0036-$0039 set to point to code in page $B8xx associated with
ProDOS. After doing an IN#2 and starting the transfer, things would go along
fine until transferred code overwrote code involved in handling the transfer.

     Try turning on your Apple II and not booting any disk. Or, try doing a
PR#6 with no disk in your 5.25" Drive 1. Either process seems to fix the I/O
vectors so that you are ready to do an IN#2 and do the transfer.



Rubywand