[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