Errors occuring while the OS is entering a new language

[SteveF]

I don't think this is a big deal, I just found it interesting...

Just to set the scene, the AUG says (not unreasonably):

When entered at the language entry point, a language should always set up the BRK vector to its error handler. Even the simplest language requires error handling, since just writing a character to the screen can cause an error when output is spooled.

So what happens if we're spooling the output and an error occurs while the OS is printing the language name before transferring control to the language entry point?

Starting with a blank 80T DFS disc, I contrived this happening (on OS 3.20, FWIW; OS 1.20 seems to do the same, as I'd have expected):

It works!? Presumably this is just "luck" because we're transferring control back to the same language, so the existing BRKV handler points to the right place.

(Incidentally, the "*SAVE FOO" command is there to work around DFS's unwillingness to create a new file for writing with so little free space. There's probably no deliberate connection, but arguably that offers a little extra protection against this rare case occurring. Of course, even with an empty disc a physical fault on the disc could cause an error at any point; it's just easiest to reproduce in terms of running out of space.)

Let's try it again, entering VIEW instead:

That crashes in a mildly interesting way.

I don't think there's any way to guard against this if you're writing a language ROM. Am I right? It's perhaps a shame the OS does character output during this window when there might not be a BRKV handler to deal with any errors, but 99.99% of the time it works just fine and it does help that BASIC (for example) doesn't have to print its own startup banner, saving space for other code in the ROM.

Does anyone know why the first example doesn't get stuck in an infinite loop with BASIC trying to print "Can't extend" from its BRKV handler and triggering new errors as it does?

• BASIC's BRKV handler doesn't seem to do anything like issue *FX119 to close *SPOOL/*EXEC files.
• Looking at TobyLobster's OS 1.20 disassembly, the OS issues service 6 call to tell the sideways ROMs before chaining through to BRKV, but...
• MMFS (at least) doesn't seem to do anything to close files in response to service call 6, so I assume DFS doesn't either.

But something is handling this, as BASIC doesn't get stuck and "PRINT ?&257" (the address of the *SPOOL file handle) at the BASIC prompt shows 0 afterwards, even though "FOO" is still open (as can be seen if you try to *DELETE it).

[jgharston]

It's not BASIC getting stuck. When the error occurs the MOS has the destination language selected as the current language, but the language hasn't taken over yet, so BRKV is still pointing to the previous language's error handler - in a different ROM.

So, what happens in the second example is:
LANG (OSBYTE 252)=BASIC, BRKV=>BASIC's error handler
*VIEW
View issues OSBYTE 142
MOS sets LANG=VIEW
MOS prints VIEW's title
error occurs
MOS pages in current language set in LANG, ie VIEW
MOS jumps through BRKV, ie to the address of BASIC's error handler.

Arguably, MOS should set LANG immediately before entering the language, after printing the title not before. In MOS 1.20 the STX &028C at DBE8 should be between DBFA and DBFD.

[SteveF]

Thanks Jonathan, that's interesting - I had been overlooking the fact the OS tracks the current language separately from "the currently paged in ROM bank" and it looks like your suggested STX move would neatly fix this problem.

The last question on my original post was actually a bit of a tangent and not related to entering languages, as I now realise. When an error occurs during *SPOOL output, something seems to disable spooling, which is necessary in order to prevent an infinite loop:

• OSWRCH generates an error because the disc is full
• The BASIC default error handler is called and tries to print the error message using OSWRCH
• (repeat forever)

But what bit of code is actually disabling spooling?

• At least in OS 1.20, there doesn't seem to be any attempt to detect errors from OSBPUT within OSWRCH.
• BASIC's error handler doesn't seem to do this.
• The OS generates service call 6, but MMFS (at least) doesn't seem to do anything in response to that.

[regregex]

But what bit of code is actually disabling spooling?

It's the DFS itself. Within OSBPUT, on finding a file can't be extended it tests whether the file handle in question is the *SPOOL handle and if so, calls OSBYTE &C7 again to set the handle to zero.

Code: Select all

9809 A9 C7     LDA #C7                  A=00 X=00 Y=11 S=E1 CZ..B..
980B 20 B6 A0  JSR A0B6                 A=C7 X=00 Y=11 S=E1 C...B.N
A0B6 A2 00     LDX #00                  A=C7 X=00 Y=11 S=DF C...B.N
A0B8 A0 FF     LDY #FF                  A=C7 X=00 Y=11 S=DF CZ..B..
A0BA 4C F4 FF  JMP FFF4                 A=C7 X=00 Y=FF S=DF C...B.N
...
980E 20 1C 98  JSR 981C                 A=C7 X=11 Y=00 S=E1 C...B.N
981C 8A        TXA                      A=C7 X=11 Y=00 S=DF C...B.N
981D A8        TAY                      A=11 X=11 Y=00 S=DF C...B..
981E 20 E6 97  JSR 97E6                 A=11 X=11 Y=11 S=DF C...B..
97E6 48        PHA                      A=11 X=11 Y=11 S=DD C...B..
97E7 98        TYA                      A=11 X=11 Y=11 S=DC C...B..
97E8 C9 10     CMP #10                  A=11 X=11 Y=11 S=DC C...B..
97EA 90 04     BCC 97F0                 A=11 X=11 Y=11 S=DC C...B..
97EC C9 18     CMP #18                  A=11 X=11 Y=11 S=DC C...B..
97EE 90 02     BCC 97F2                 A=11 X=11 Y=11 S=DC ....B.N
97F2 20 C4 81  JSR 81C4                 A=11 X=11 Y=11 S=DC ....B.N
81C4 0A        ASL A                    A=11 X=11 Y=11 S=DA ....B.N
81C5 0A        ASL A                    A=22 X=11 Y=11 S=DA ....B..
81C6 0A        ASL A                    A=44 X=11 Y=11 S=DA ....B..
81C7 0A        ASL A                    A=88 X=11 Y=11 S=DA ....B.N
81C8 0A        ASL A                    A=10 X=11 Y=11 S=DA C...B..
81C9 60        RTS                      A=20 X=11 Y=11 S=DA ....B..
97F5 A8        TAY                      A=20 X=11 Y=11 S=DC ....B..
97F6 68        PLA                      A=20 X=11 Y=20 S=DC ....B..
97F7 60        RTS                      A=11 X=11 Y=20 S=DD ....B..
9821 CC C2 C2  CPY C2C2                 A=11 X=11 Y=20 S=DF ....B..
9824 60        RTS                      A=11 X=11 Y=20 S=DF CZ..B..
9811 D0 11     BNE 9824                 A=11 X=11 Y=20 S=E1 CZ..B..
9813 A9 C7     LDA #C7                  A=11 X=11 Y=20 S=E1 CZ..B..
9815 A2 00     LDX #00                  A=C7 X=11 Y=20 S=E1 C...B.N
9817 A0 00     LDY #00                  A=C7 X=00 Y=20 S=E1 CZ..B..
9819 4C F4 FF  JMP FFF4                 A=C7 X=00 Y=00 S=E1 CZ..B..

DDOS 3.46 does the same, but this routine in DFS will also cancel a *EXEC in progress.

[SteveF]

Thanks, that makes sense now. And now I know where I'm looking I can see the equivalent code in MMFS too.

[regregex]

Arguably, MOS should set LANG immediately before entering the language, after printing the title not before.

Fixed in OS 1.26

[SteveF]

Fixed in OS 1.26

That is very cool! I'd be hard pressed to say why, but it is!