[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: detecting ProDOS vs. Dos3.3



Dave Althoff Jr <dalloff@gcfn.org> wrote:

> Rubywand (rubywand@my-deja.com) wrote:
> : Dennis Jenkins <dennis@usb.com> writes ...
> 
> : > Hello,
> : > I am writing some code that needs to know which OS it is running
> : > under.  I'd prefer a "rock solid" way of doing this.
> : > Currently, I just examine the jump table target address
> : > on the $3d0 JMP.  If it is "BE00"
> : > I assume prodos and if it is (I forgot) then
> : > I assume Dos 3.3, anything else is an error.
> : > Is this a good method?  What about all of the Dos 3.3
> : > hacks out there...
> : >
> :  ....
> 
> :      It's a pretty good check. 4C 00 BE seems to be a good indicator for
> : ProDOS. Meanwhile, DOS 3.3 and popular variants like Prontodos, EsDOS,
> : and DavidDOS all have 4C BF 9D at $03D0.
> 
> If you want to be truly bulletproof, it might be safer to look for the 4C
> 00 BE to indicate ProDOS and assume that anything else is a DOS 3.3
> variant.  Why?  Well, Rubywand mentioned the possibility of DOS having
> been moved to the Language Card (which you can't do with ProDOS since it's
> already there...).  There is another possibility as well...if the DOS 3.3
> disk is an old one, built on a system with less than 48k RAM, and without
> the DOS relocation code (i.e. not a master disk), then DOS isn't smart
> enough to load high.  So location $3D0-$3D2 might contain 4C BF 5D, for
> instance, if the disk were created on a 32k machine.
> 
> That said, I don't think Apple has sold a machine with less than 48k in it
> in the last 20 years or so, so the point is probably needlessly nitpicky
> and pedantic.  Of course, ProDOS requires a 64k machine to operate, so
> this isn't an issue.

Not quite: ProDOS 1.0 and 1.0.1 will work in a 48k machine.  The global
page is still in the same place, but the kernel resides below it.

It isn't possible to run BASIC.SYSTEM in this configuration, so it is a
moot point in the context of this discussion.

> As one not familiar with the guts of ProDOS...Is the code at $BE00
> actually in ProDOS, or is that sitting in some .SYSTEM file someplace and
> so can't necessarily be counted on either?

The $BE00-$BEFF page is owned by whichever application you are running.
In the case of BASIC.SYSTEM, it is the global page defined by
BASIC.SYSTEM which provides most of the well-defined entry points for
use by machine code programs.

If you were running a different application (e.g. AppleWorks or your own
SYS file) then this page is owned by the running application, and might
contain completely different code.  In addition, $3D0-$3EC are owned by
whichever application you are running, and there might not be a JMP
instruction at $3D0 (and even if there was, it might be an old one
lurking around from a previous boot of DOS 3.3).

It is probably reasonable to assume that an aribtrary binary file (or
chunk of code poked in by a BASIC program) will be running under
BASIC.SYSTEM.

If the code has to be more generic than this, then it will need to use a
different technique to detect the operating system.  I'd suggest looking
for known patterns of data on the ProDOS global page ($BF00-$BFFF), such
as a JMP instruction at $BF00, and either a JMP or RTS at $BF06.  The
operands of these locations cannot be relied upon, as they may vary
between ProDOS versions or if a patch has been installed (e.g. the Apple
II Workstation Card).

There are also JMP instructions at $BF03, $BF09 and $BF0C, which are
used internally by ProDOS.

Beyond that you would have to look at some of the data values to see
whether they made sense.


> That is, does $BE00 reconnect ProDOS, or does it reconnect BASIC.SYSTEM?

$BE00 is the warm start entry point for BASIC.SYSTEM.  It does a JMP to
the actual warm start routine, which is somewhere earlier in memory (at
a location which may vary between versions).