[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