[Coco] disabling the break key in BASIC programs.

[Robert Gault]

See comments below. This program seems to have been written for a Coco 
without Disk Basic and with 16K of RAM. It needs modification for use with 
a disk system and larger amounts of RAM but the modifications are trivial. 
If used with a Coco3 or with a Coco1 or 2 in all RAM mode, Basic can be 
changed directly.

Aaron Banerjee wrote:
> All,
>    I recently stumbled on an old routine I used to use for disabling the
> break key in BASIC programs.  I was just trying to decipher it.
> 
  Line 1 assumes that the Coco is not in all RAM mode else changes would be 
made directly to Basic in RAM. It assumes 16K of RAM based on the PEEK 
location. The program assumes that Disk Basic does not exist so all Disk 
commands should fail after running it. Line 1 first looks to see if it has 
already been run but the test is inadequate. Testing a single byte is not 
sufficient to tell if 101 bytes are correct.
  If the PEEK <>32 then the Extended Basic command interpretation loop is 
copied from "ROM" to low RAM. The constant comes from $82B9-$3EB9=$4400 so 
I-&H4400 points to the correct locations.
> 1  IF PEEK(&H3EB9)<>32 THEN CLEAR 350,&H3EA0:FOR I = &H82B9 TO &H831E:
> POKE I-&H4400, PEEK(I): NEXT I ELSE 3
Line 2 changes part of the code from JSR $ADEB (check for BREAK key) to 
NOP, NOP, NOP. So, there will be no check for the BREAK key.
> 2  FOR I = 0 TO 2:POKE &H3EBD+I,18:NEXT
Line 3 changes a system RAM "hook" which points to the command loop. Since 
the code was moved so that all least significant bytes have the same values 
as the original, only the most significant byte of the pointer needs to be 
changed. A more versatile program would use any location in RAM and change 
the entire pointer.
> 3  POKE &H19B,&H3E:RUN5
> 4  REM  PROGRAM STARTS ON LINE 5
> 
> Once upon a time I had this one figured out.  We're copying code, NOP'ping
> out a jump, and then realigning a pointer.  
> 
> If my memory serves me correctly, this effectively disables the break key
> so long as the computer is executing instructions that are not waiting for
> user input (e.g. INPUT, etc).  If you wanted to INPUT something with the
> break key disabled using this, you could do something using INKEY and it
> would work.
> 
> I'm assuming &H19B is some sort of pointer or "hook" (which presumably is
> &H19B and &H19C).  Any idea of when that address is jumped to?
> 
> It's been a while since I've been curious enough to mess with this sort of
> thing....
>                            - Aaron
> 
> p.s.  The above worked on an Extended Color BASIC 1.0 machine...  I
> haven't a clue if it would on a more "modern" coco.
> 
>