Break: name the status register properly and show the Stack Pointer

The dump labelled the status register "S", which reads as Stack to anybody
sensible - and the Stack Pointer was the one register it did not show, so
there was nothing to contradict the guess. It is written "status" now, and
followed by the bits that are up, because a dump that makes you look the
number up is only half a dump.

The Stack Pointer is not in the frame, since the frame is where the Stack
Pointer is. What the program had is fourteen bytes above it, that being what
entering an interrupt puts down, so it is worked out and shown.

Apps/Break.asm takes its second stop inside a subroutine, so the recorded
output shows the Stack Pointer at FFFF and then at FFF5: a difference of ten,
which is the size of a CALL frame. That checks the value is derived rather
than constant, which the previous version could not have told you.

Reported by Anachronaut, who read the output and asked why a pointer was two
digits long.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Programs/CosmOS/Apps/Break.asm

@@ -14,8 +14,9 @@
 ; addresses from a build without, which is the same bargain every machine makes that has a
 ; break instruction.
 ;
-; Correct output is two stops, showing A and B changing between them, and the addresses of
-; the two SWIs.
+; Correct output is two stops. A and B differ between them, the addresses differ, and the
+; Stack Pointer differs too, because the second one is inside a subroutine and a call has
+; put ten bytes down by then.
 
 #Include services.asm
 
@@ -32,16 +33,21 @@ start:
   SETD.0 Marker
   SWI osBreak
 
-  ; Something for the second stop to show as different.
-  INIA 0d68
-  INIB 0d85
-  SETD.0 Banner
-  SWI osBreak
+  ; The second stop is inside a subroutine, so that the Stack Pointer is visibly not where
+  ; it was: a call puts ten bytes down before this one gets there.
+  CALL deeper
 
   SETD.0 DoneText
   SWI osPrintString
   SWI osExit
 
+deeper:
+  INIA 0d68
+  INIB 0d85
+  SETD.0 Banner
+  SWI osBreak
+  RET
+
 #Data
 
   #Base 0x1000

Programs/CosmOS/Source/cosmos.asm

@@ -1049,6 +1049,35 @@ breakAddress:
   POPD.1
   DPUP.1 0d1
   CALL breakByte
+
+  ; And which bits of it those are, since a debug dump that makes you look the number up is
+  ; only half of one. Halt is not among them: the machine is plainly not halted.
+  PSHD.3
+  POPD.1
+  DPUP.1 0d1
+  LDA.1
+  PSHA
+  INIB 0x01
+  AND
+  BRQ breakNoCarry
+  SETD.0 CarryText
+  CALL printString
+breakNoCarry:
+  POPA
+  PSHA
+  INIB 0x02
+  AND
+  BRQ breakNoFault
+  SETD.0 FaultText
+  CALL printString
+breakNoFault:
+  POPA
+  INIB 0x04
+  AND
+  BRQ breakNoInts
+  SETD.0 IntsText
+  CALL printString
+breakNoInts:
   CALL newLine
 
   SETD.0 DP0Text
@@ -1071,6 +1100,22 @@ breakAddress:
   POPD.1
   DPUP.1 0d5
   CALL breakWord
+
+  ; The Stack Pointer is not in the frame, because the frame is where the Stack Pointer is.
+  ; What the program had is fourteen bytes above this one, that being what entering an
+  ; interrupt puts down.
+  SETD.0 SPText
+  CALL printString
+  PSHD.3
+  POPD.0
+  DPUP.0 0d14
+  PSHD.0
+  POPB
+  POPA
+  CALL printByteHex
+  PSHB
+  POPA
+  CALL printByteHex
   CALL newLine
 
   ; Anything typed carries on. Reading the data port waits however the console is set, which
@@ -1936,7 +1981,7 @@ BRegText:
 QRegText:
 "Q "
 SRegText:
-"S "
+"status "
 DP0Text:
 "DP0 "
 DP1Text:
@@ -1945,6 +1990,14 @@ DP2Text:
 "DP2 "
 DP3Text:
 "DP3 "
+SPText:
+"SP "
+CarryText:
+"carry "
+FaultText:
+"fault "
+IntsText:
+"interrupts "
 ResumeText:
 "press a key "
 MonitorPrompt: