Re: Applesoft and RESET

[mwillegal <mike@willegal.net>]

On Jun 4, 6:40 am, vladitx <vlad...@nucleusys.com> wrote:
> On Jun 4, 4:26 am, gids...@sasktel.net wrote:
>
>
>
> > Try this little program to intercept the reset key
>
> > 300:A9 10 8D F2 03 A9 03 8D
> > 308:F3 03 49 A5 8D F4 03 60
> > 310:68 A8 68 A2 F8 9A 48 98
> > 318:48 20 EA 03 20 00 03 4C
> > 320:3C D4
>
> > This is a revised routine from D683 which resets the stack pointer,
> > reconnects DOS, resets the RESET pointers to point back to the
> > subroutine and then jumps into applesoft.
>
> > If this works then something is corrupting the stack pointer on a
> > reset. which could be anything from a card in a slot,  (Remove all
> > cards and test again), or a corrupted DOS or program that might be
> > running illegal instructions that can cause unpredictable results.
>
> Yup, it works as it solidly puts $F8 in SP each time.
>
> The machine is barefoot IIc (255) without any disk booted, not even
> BASIC program entered.
>
> > Also to see the value of the stack pointer, change to this
>
> > 310:BA 8A 20 DA FD 4C 3C D4
>
> > and hit reset.  If you run a few different programs, then hit reset
> > after each one, the number that shows up on the screen should always
> > be $FB.  If the number is creeping lower then something is interfering
> > with the reset routine and it is not resetting the SP properly.
>
> That really caught it. Every RESET gives random SP value, on average
> decreasing by about 16 bytes, but could be anything.
>
> So there must be either IRQ handler or the software flashing cursor
> diving into stack heavily and then RESET interrupting it. And the
> culprit is leaving SP unitialised.
>
> Rob, thanks for great insight!

My first thought when seeing this thread, is that there is a problem
with address decoding circuitry which is causing the stack to become
corrupted - but i've been wrong plenty of times before.

regards,
Mike Willegal