Re: Reset vector

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

Daystrom <daystrom@dux.raex.com> wrote:

> While reading my 'ol AppleSoft Basic book, I ran into a few lines about
> a reset vector. When you hit control-reset, you could control what that
> did.
> 
> Does anyone have the peek (or poke's) that would control this?

The locations that are usually referred to (the user reset vector) are
at $03F2 and $03F3.  (See later for comments on this.)

There is a check byte stored at $03F4, which must be set to the value in
$03F3 exclusive-ORed with the hexidecimal value #$A5.  If this condition
is not met, then Control-Reset will reboot (like Control-Apple-Reset).

In decimal, these locations are 1010 (low order byte), 1011 (high order
byte) and 1012 (check byte).

Unless you might be running on an old monitor ROM (original Apple ][, or
][+ or IIe with Integer card or swapped ROM chip), there is a routine in
the ROM that can be called to calculate the check byte for you:

JSR $FB6F for assembly language.
CALL -1169 for BASIC.

(If you have the old monitor ROM then the reset vector doesn't work
anyway - reset always takes you to the monitor.)

All that remains is what to poke into the first two bytes.  You need the
address of a routine that does whatever task you want to perform.

Whatever you set this to, there are a few major catches:

1. Control-Reset physically resets the computer.  The CPU leaps to the
reset handler and forgets everything about what happened before, in
particular where it was running.  It is not possible to go back to where
you were before the reset.

2. The firwmare and hardware is reinitialized (to some extent), which
has side effects such as graphics modes being turned off.

3. DOS or ProDOS gets disconnected.

> I can remember you could make ctrl-reset do nothing

It has to do something, but it could be as simple as performing a RUN
command (restarting the BASIC program).

> restart the computer

Easy - just make sure the check byte is wrong, e.g.

POKE 1012,PEEK(1011)

If you want to be pedantic, you could point the reset vector at $FAA6.

> halt the program

Unless you mean "lock up completely", this is what reset normally does -
reinitialize DOS/ProDOS, reinitialize BASIC, go to the command prompt.

To hang the computer, you would need to point the reset vector at an
infinite loop.  Assuming locations $0300-$0302 are not used, the
following would work:

POKE 768,76
POKE 769,0
POKE 770,3
POKE 1010,0
POKE 1011,3
POKE 1012,166


Getting back to my first paragraph: the actual reset vector, used by the
processor to fetch the location of the first instruction to be executed,
is at $FFFC and $FFFD.  On the IIe, this vector is fetched from ROM
unless you have a card in a slot that uses the INHIBIT signal to
override the ROM, and remembers to do this after a reset.

The language card used in the ][+ is an example of this.  Its read
enable latch is not affected by a hardware reset, so if the language
card is enabled, the reset vector will be fetched from $FFFC/D in the
language card.  Apple II Pascal made use of this to capture the reset
and reinitialize correctly (without having the monitor firmware step on
zero page locations that were being used for different purposes).

The built-in language card in the IIe does not retain this feature.  The
ROM is always switched in after a reset.  Pascal will reboot if you hit
Control-Reset on a IIe.

The reset vector points to $FA62.  This routine reinitializes some parts
of the system, then checks the RAM-based user reset vector and jumps
through it if the check byte is correct.  If not, it jumps to the cold
start routine at $FAA6.

I haven't investigated how the IIgs interacts with INHIBIT after reset,
but it is possible that it will be ignored completely.  The IIgs does a
lot more work at reset time than 8-bit models.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand