Re: Apple IIe boot question

["Chuck Morris" <nospam@nospam.net>]

Michael J. Mahon <mjmahon@aol.com> wrote in message
20030622044247.11524.00000951@mb-m13.aol.com">news:20030622044247.11524.00000951@mb-m13.aol.com...
> >
> >My IIe (enhanced) will boot from whatever is in the highest slot also,
> >but, it won't bypass an empty Disk II or Apple 5.25 drive.
>
> This is a function (or failure) of the Disk ][ Controller card.  When it
> was designed, no provision was made for "timing out" on a not-ready
> disk drive.  Therefore, it stops the boot scan.
>

Actually, it wouldn't have mattered whether the controller card handled
timing out or not because the boot code in the autostart rom also has no
provision to handle such an error returned from the controller.  Once it
finds a card that it thinks it should be able to boot from, it will never
continue the scan no matter what happens.

> > Also, it won't
> >recognize all 4 partitions on a CFFA card in any slot but 5.
>
> This is a function of which version of ProDOS you are using.
>
> If you use the latest version (2.0.3) it will happily map extra
> partitions from any slot to any other slot's drive numbers.
>

Sounds like an upgrade is in order then, Bill.  This also renders my
comments in a separate reply that spoke of how this could be due to an error
in the CFFA's rom code irrelevant.

> > So, I have to
> >put the 3.5 in 6, the CFFA in 5 and the 5.25 in slot 4. The unenhanced
> >IIe board I just got purposely to test firmware in an IDE device that
> >wasn't made for anything but a IIe enhanced or IIgs. It seems to be
> >working ok, except for not booting and only sees the first 2 of the 4
> >partitions.
>
> Try ProDOS 2.0.3--you'll like it.  ;-)

Almost as much as I suspect you'll enjoy being able to boot from the CFFA
card. ;-)

>
> > I was very excited to discover that the ProDOS Users Disk
> >has a conversion feature that allows DOS 3.3 programs to be made to
> >run on ProDOS disks.
>
> This is not really a conversion--it just moves files "as is" from one file
> system to the other.  If the file is a program, it may work under the
> other file system as long as it doesn't do any disk I/O (which would
> require some actual porting--usually quite difficult).
>

At least when you're talking about Applesoft programs, the difficulty of
modifying the code to work properly under ProDOS varies depending on what
types of disk I/O are being done, and how the programmer wrote the code in
the first place.  DOS 3.3 filenames that are referenced may need to be
modified, but the biggest problem I've seen with making the programs run is
due to how the disk commands had to be issued, more than what the commands
were.  In DOS 3.3 a disk command was issued by doing a PRINT statement that
printed the command, prefixed by a control-d character.  Though this is the
same method that ProDOS uses, in DOS 3.3 the command would only be
recognized if the control-d was the first character printed since the last
carraige return was printed.  In ProDOS, the command would only be
recognized if the control-d was the first character printed in that
particular PRINT command.  Since programs sometimes issued PRINT statements
that did not end by outputting a carraige return, it was common practice for
the PRINT statement that contained the disk command to start by printing a
carraige return, a control-d, and finally the command.  This made sure that
the disk commands would always be recognized as such by DOS 3.3.  In ProDOS,
the same code would make sure that the disk commands would NEVER be
recognized, since the control-d would not be the first character output by
the PRINT statement.  Fortunately, most programmers under DOS 3.3 made it a
habit to define a string variable (usually D$) at the beginning of any
program that had to issue disk commands that was initialized as D$ =
CHR$(13) + CHR$(4).  Then when they wanted to issue a CATALOG command from
with a program, the command PRINT D$;"CATALOG" would always work.  If all
other aspects of the disk commands being issued by a program are otherwise
compatible, simply changing the initialization of the D$ variable to D$ =
CHR$(4) is all that is required.  If the programmer just loved to type a lot
though and didn't use a string variable in this way, then you might have to
change each and every disk command individually.