Back in the day, the ability to properly handle errors programmatically was significantly hampered because, whilst ON ERROR GOTO.... allowed you to jump to code which could handle errors intelligently by error and line number (ERR and ERL), it only did this after emptying or resetting the BASIC stacks.
So having handled an error, you could jump back to the point where, or immediately after, the error had occurred, but if this was within a loop, or a PROCedure or a FunctioN, or even a subroutine, the next time a NEXT or an UNTIL, or an ENDPROC etc was encountered, another error was generated, as BASIC no longer knew where to jump to next.
I was wondering if the BASIC stack could be saved just before a section of code that is known to potentially generate errors, and then restored after the error had been handled, to allow a loop or whatever to smoothly continue.
I'll attach some sample, naive, code which tried to do this, but TL:DR - it doesn't work yet!
Limitations of ON ERROR handling. Saving the BASIC stack?
-
- Posts: 6
- Joined: Thu Feb 29, 2024 9:40 pm
- Contact:
-
- Posts: 6
- Joined: Thu Feb 29, 2024 9:40 pm
- Contact:
Re: Limitations of ON ERROR handling. Saving the BASIC stack?
So this should save the BASIC FOR/REPEAT/GOSUB stack, as a start (the page starting at &500) followed by the 2 byte stack pointer on zero page.
So when we set up our program, we reserve a page of memory, plus a few extra bytes, and set S% to point to it:
...then later we can write a routine to save the BAISC FOR stack and stack pointer:
It uses a GOTO loop to avoid any writes to the BASIC stack during the save process that would result from using a FOR NEXT loop. (Please don't let this thread turn into a discussion of the uses and abuses of GOTO!)
So when we set up our program, we reserve a page of memory, plus a few extra bytes, and set S% to point to it:
Code: Select all
10 DIM S% &110
Code: Select all
1000 M%=&00
1010 S%!M% = !(&500+M%)
1020 M%=M%+4
1030 IF M%<=&FF GOTO 1010
1040 ?(S%+&FF+1)=?&04:?(S%+&FF+2)=?&05
Last edited by Cantabrigian on Wed Mar 13, 2024 12:58 pm, edited 1 time in total.
-
- Posts: 6
- Joined: Thu Feb 29, 2024 9:40 pm
- Contact:
Re: Limitations of ON ERROR handling. Saving the BASIC stack?
And this code, should restore the stack and stack pointer:
But if you insert both save and restore routines into a FOR loop, generate an error (e.g. with a line like "MISTAKE" between the save and restore routines, handle that error via a routine pointed to by a previous ON ERROR setting, and return control to the line after the error... where the restore routine reads back the values of the stack and stack pointer, you still get a "No FOR" error when BASIC next encounters a NEXT.
Any ideas?
Code: Select all
2000 M%=&00
2010 !(&500+M%)=S%!M%
2020 M%=M%+4
2030 IF M%<=&FF GOTO 2010
2040 ?&04=?(S%+&FF+1):?&05=?(S%+&FF+2)
Any ideas?
Re: Limitations of ON ERROR handling. Saving the BASIC stack?
Code: Select all
$ bbcbasic
PDP11 BBC BASIC IV Version 0.45
(C) Copyright J.G.Harston 1989,2005-2024
>_
-
- Posts: 6
- Joined: Thu Feb 29, 2024 9:40 pm
- Contact:
Re: Limitations of ON ERROR handling. Saving the BASIC stack?
Many thanks! It looks like you've gone into this thoroughly!
I'll have a proper look and experiment when I get a chance sometime in the next 24 hours!
I'll have a proper look and experiment when I get a chance sometime in the next 24 hours!