Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!munnari.oz.au!murtoa.cs.mu.oz.au!ditmela!latcs1!stephens
From: stephens@latcs1.oz (Philip J. Stephens)
Newsgroups: comp.sys.apple
Subject: Re: Reset Vectors
Message-ID: <6483@latcs1.oz>
Date: 4 Oct 89 13:17:49 GMT
References: <memo.170411@lynx.northeastern.edu>
Organization: Comp Sci, La Trobe Uni, Australia
Lines: 40

In article <memo.170411@lynx.northeastern.edu>, davidbrierley@lynx.northeastern.edu writes:
> 
>      Could anyone tell me how to deactivate the reset key (i.e.
> causing the program to resume when it is interrupted by reset) and
> to cause a branch to another part of a program when reset is pressed.
> I am particularly interested in techniques that do these things by
> using POKEs or short ML routines.  Thank you in advance.
> 
>                                       David R. Brierley
>                                       davidbrierley@lynx.northeastern.edu

The reset key can never be "deactivated".  It always causes a jump to a
machine language program whose address is stored in $3F2 & $3F3.
   When you press RESET during the running of an Applesoft program, you
will be interrupting the execution of the current statement.  Hence the best
you could do is to write a ML routine (called when RESET is hit) to re-run
the program starting at the statement that was interrupted.
   However, there are many, many addresses in zero page ($0000 to $00FF) that
Applesoft requires to run a program.  If any of these locations loses its
integrity due to RESET terminating the executing of a statement halfway
through, then chances are high that the program will crash some time after
resuming.  The best you could do is restart the program from the very
beginning, forcing Applesoft to re-initialise the critial zero page addresses.
  The same problem applies to jumping to another line in the program. 

  Someone else may prove me wrong, but I believe that the statement made in the 
Applesoft BASIC reference manual is _WRONG_.  You cannot achieve what it says
you can do without possibly crashing the Applesoft interpretor.

  [As an aside, the only foolproof technique would be if on a RESET the
address of the program counter in the 6502 was preserved on the stack.  You
could then jump back to the next instruction in the Applesoft interpretor,
and all would be fine.  However, the 6502 does no such thing on receiving
a reset signal, so this is just a dream.]

+-----------------------------------------------+ 
| Philip J. Stephens                            |
| Computer Science III, LaTrobe Uni., Melbourne |
| ACSnet: stephens@latcs1.oz                    |
+-----------------------------------------------+