[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: detecting ProDOS vs. Dos3.3
We were talking about using the warmstart vector at $3D0 to identify the
current OS, and otherwise just kind of waiting around for David Empson to
jump in, which he finally did... 8-)
Althoff, who knows DOS 3.3 better than ProDOS, sez...
: > 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.
Empson, who knows Apples better than most anybody corrects...
: 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.
Interesting. I'd thought that ProDOS required 64k from the outset.
(Althoff again--)
: > 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?
(Empson)
: 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.
(Althoff)
...because the 3D0 vector is provided by BASIC.SYSTEM, not by ProDOS.
Which answers my question about the use of the 3D0 vector later.
(Empson)
: 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.
(Althoff asks the question alluded to earlier)
: > That is, does $BE00 reconnect ProDOS, or does it reconnect BASIC.SYSTEM?
(Empson answers)
: $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).
(Althoff comments)
Now this is an interesting situation as well. Woz gave us that nice
vector in Page $03 for the DOS entry point at $3D0, so that if you change
DOS it points to the right place. Conveniently enough, ProDOS...or
rather, BASIC.SYSTEM...uses the same entry point vector at $3D0. But it
appears that the $3D0 vector under BASIC.SYSTEM always points to $BE00,
which is itself a vector to the "real" BASIC.SYSTEM entry point somewhere
else. Makes me wonder why BASIC.SYSTEM doesn't just set $3D0 to the
"real" entry point location and be done with it. Or is there a table of
vectors up in Page $BE with the $3D0 vector merely set for the convenience
of old-school DOS guys like me...
--Dave Althoff, ][.
--
/X\ _ _ _ *** Happy New Year!!! ***
/XXX\ /X\ /X\_ _ /X\__ _ _ _____
/XXXXX\ /XXX\ _/XXXX\_ /X\ /XXXXX\ /X\ /X\ /XXXXX
_/XXXXXXX\__/XXXXX\/XXXXXXXX\_/XXX\_/XXXXXXX\__/XXX\_/XXX\_/\_/XXXXXX