Code demarcation

Looking around the memory of WCB a bit more there is a large block of data from address $d279 through to $d3a5 that mainly contains the value $0.  Interesting.  Also, there is exactly one explicit reference to the code located after address $d3a5 from all the code before $d279.  Remember the code after $d3a5 contains our debugger mnemonics. Very interesting.

That one reference comes in the following block (explanation follows):

  ;---------------------------------------------------------------------------
  ; Periodically check for a stack overflow and dump the stack memory 
  ; to screen in the event one occurs

  L_52B2:
      CMPI    #$0316, R6              ; check for stack overflow (R6 > $316)
      BLE     L_52EF                  ; if no overflow, goto L_52EF (done)
                                      ;
      MVI     $01D9, R0               ; check the contents of $1d9
      TSTR    R0                      ; 
      BNEQ    L_52EF                  ; if non-zero, goto L_52EF
                                      ;
      MVO     R6,     $01D9           ; store the stack pointer in $1d9
      BEGIN                           ;
      DIS                             ; disable interrupts
      MVII    #$0200, R4              ; set R4 to the start of backtab
      MVII    #$0006, R3              ; load the colour yellow
      MVII    #$02F1, R2              ; set R2 to the start of stack memory
                                      ;
  L_52C5:                             ;
      MVI@    R2, R1                  ; load value from memory and print
      JSR     R5, L_DB87              ; <<<< JUMP TO LOCATION AFTER $D3A5 
                                      ;
      INCR    R2                      ; step onto next stack memory location
      CMPI    #$02F0, R4              ; are we at the end of the screen?
      BLT     L_52C5                  ; if not, load and write more data
                                      ;
  ... skip a bit ...                  ;
                                      ;
      EIS                             ; enable interrupts
      PULR    R5                      ; restore the state of R5 
                                      ;
  L_52E9:                             ;
      DECR    R7                      ; wait here indefinitely
      NOP                             ; 
      NOP                             ; some kind of end of code marker?
      NOP                             ; 
      NOP                             ; 
      NOP                             ;

This little block is a check that runs periodically. If it finds that the CPU stack, used to temporarily store data, has grown too large it draws Mike's crash screen. It does this by reading the first 60 words from 16-bit stack memory, starting at address $2f1, and writing them to the screen like this:

As has already been mentioned, more details of this crash screen and when it occurs were documented back in 2017.

If the code above address $d3a5 is only called when a crash occurs, could all of it be Rick's debugger? Meaning that the code below $d279 is the WCB game itself. Well there is an easy way to find out. Remove all the code above $d3a5, re-assemble the game and try to play it. And...

 
...initial testing suggests this cut down version of WCB works just fine. Therefore, this seems to be a reasonable hypothesis, which would mean that WCB itself is about 8.5K in size and the debugger is about 2.5K. Not bad, at least we have an idea of the size of the reverse engineering task we are trying to undertake.