[Coco] disabling the break key in BASIC programs.

Arthur Flexser flexser at fiu.edu
Thu Mar 30 04:19:37 EST 2006


On the CoCo 3, all you need to do is put POKE &HADEB, &H39 into the first line
of the program to disable the break key (and shift-@ pause as well).

Art

On Wed, 29 Mar 2006, Aaron Banerjee wrote:

> 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.
> 
> 
> -- 
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 




More information about the Coco mailing list