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