Re: Which Hex Address Start In ROM?

[dempson@actrix.gen.nz (David Empson)]

[Please note that I've directed followups to comp.sys.apple2.programmer
again - this discussion isn't appropriate on comp.sys.apple2.marketplace
or comp.sys.apple2.usergroups.]

Bryan Parkoff <BParkoff@satx.rr.com> wrote:

>     If it is true that Apple II has no language card for Interger BASIC
> and/or Applesoft BASIC, it will jump to ROM Monitor that will appear with
> "*" prompt.  It is interesting.

That is not what I was saying.  The language card and availability of
BASIC has nothing to do with it.

The original Apple ][ firmware ("Old Monitor ROM") behaves differently
from the later firmware ("Autostart Monitor ROM") which was introduced
with the Apple ][+.

The F8 ROM chip (containing the monitor) can be swapped between an Apple
][ and ][+, so you can run either machine with either version of the
monitor.

In addition, Apple made a ROM card which was typically installed in slot
0.  They had a version of this card which came with Applesoft BASIC and
another which came with Integer BASIC.  The Applesoft version included
the Autostart Monitor, and the Integer version included the Old Monitor.
These cards use the same ROM chips as the Apple ][ and ][+, so you can
also swap chips between these cards and the motherboard.

The card has a switch on the back which specifies whether the card or
motherboard ROM will be activated when the computer is reset.  If you
were running DOS, it would recognise this card (as long as it was
installed in slot 0) and let you switch between Integer and Applesoft
BASIC using the INT and FP commands.

The card also had a "solder blob" modification option which lets you
specify that the motherboard F8 ROM should always be used, rather than
switching between the card and motherboard ROM.  This means you can
install your preferred monitor ROM (probably the Autostart one) on the
motherboard and still get access to both Integer and Applesoft BASIC
through the use of the switch.

The language card came along later.  It was also designed to work in
slot 0, so you typically cannot use it at the same time as the
Integer/Applesoft ROM card (unless you patch DOS 3.3, and even then it
isn't a good idea).

The language card provides 16K of RAM (with two 4K banks at $D000-$DFFF,
allowing the whole thing to fit into the 12K address space $D000-$FFFF).

Using the language card for supporting both Integer and Applesoft BASIC
requires booting into DOS 3.3.  At startup, the HELLO program (or a
utility program called by it) detects the language card, works out which
version of BASIC is on the motherboard, and loads the other one into the
langauge card from the INTBASIC or FPBASIC file.

Early versions of DOS 3.3 had a 50 sector version of these files which
included the entire $D000-$FFFF area, i.e. it included the monitor as
well as BASIC.  I think that both INTBASIC and FPBASIC included a copy
of the autostart monitor.

In later versions (designed for the IIe) the size of the INTBASIC and
FPBASIC files dropped to 42 sectors and they added a binary file called
LOADER.OBJ0 which did the loading of whichever one was appropriate.
With this variant, the monitor was copied from the motherboard to the
language card, rather than using a version buried in the file.

It is also worth noting that the IIe 80-column firmware has some support
code which copies the monitor into the language card if it detects that
BASIC is being used.  I haven't looked closely enough at the enhanced
IIe or the IIc or IIgs to see whether this practice has continued.

The language card is also used for other purposes.  For example, when
booting ProDOS, the operating system kernel and several device drivers
end up in the language card, leaving most of main memory free for use by
SYS applications.  (BASIC.SYSTEM occupies roughly the same amount of
space as all of DOS 3.3, so you don't get any extra memory for Applesoft
BASIC programs.)  The language card is also used to hold part of the
Apple II Pascal operating system.

Another factor which comes into play here is that for the Apple ][ and
][+, the language card enable state is not affected by a hardware reset.
This means that if the computer is reset while the language card is
active, it is the code in the language card which controls the reset
operation.  For Pascal, the operating system reinitializes itself and
returns to the main menu.  For ProDOS, the operating system transfers
control to the firmware reset routine.  For DOS 3.3, the reset will be
handled by the copy of the monitor in the language card, typically the
autostart version, which will end up doing a warm reset via the
$03F2/$03F3 vector, which will warm start DOS.

This behaviour does not apply to the IIe and later machines.  They have
the equivalent of the language card built into the motherboard, but a
hardware reset will always switch control back to the ROM, so the
monitor will handle the reset.  (This means that it is not possible to
warm reset the Pascal operating system on a IIe and later, because the
monitor's reset code overwrites some Pascal system variables, and Pascal
doesn't attempt to regain control via the $03F2/$03F3 vector.)