[Coco] disabling the break key in BASIC programs.

Aaron Banerjee spam_proof at worldnet.att.net
Wed Mar 29 21:34:53 EST 2006


Robert,
   Thanks for the help!  This was originally for my 16K coco, but I was
wanting to modify it to prevent my small son from pressing the nice bright
red break key in one of his BASIC games.
                 - Aaron

On Wed, 29 Mar 2006, Robert Gault wrote:

> 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.




More information about the Coco mailing list