Hi,

Obvious question #1314:

I'm aware Break can't be disabled (ignoring the screw on the Master 128) but that it can be used fairly trivially to call a command after it's pressed using *KEY10.

Back in the early 90s though, I'm pretty sure I had some code which also had some effect over Ctrl+Break - specifically, the program I have in mind allowed you to add your own custom message under the BBC Computer text line which stayed there even when Ctrl+Break was used. No idea where that routine is now, tho.

Anyway - getting to the question, is there a way I can override Ctrl+Break to get it to respect something like:


?

Cheers,

Sam.

Ctrl-Break can be intercepted by putting a JMP to the code you want to run at address &287 (or use OSBYTE &F7-&F9 to do it the OS legal way).

I've knocked together a quick demonstration that uses OSCLI to re-make the key 10 assignment (which would have been cleared by the Ctrl-Break), then the standard break handler will do the rest:


Once this program has been run, pressing Break or Ctrl-Break will run the key 10 definition.

Are you sure you want to do this though? It can be annoying when programs hijack the machine like this, forcing a power cycle when you're done with them.

Cheers,
Paul.

That's the sort of thing I was looking for, thanks.


Not entirely sure, no - I'm just experimenting atm but I don't think it's as bad as you're imagining. I don't intend to reload the same program, so two Ctrl+Breaks would return you to the usual reset state (as the second program wouldn't take over the Break key).

Sam.

I posted a similar routine here, which makes Break / Ctrl-Break just generate an error, which can then be trapped by BASIC's ON ERROR command. It's a slightly 'cleaner' way of trapping it which doesn't result in the *KEY definition from being seen as it's entered into the keyboard buffer.

Hmm ... Paul's routine seems to do what I want - but I'd like a way of stopping it after one Break or Ctrl+Break. I can set ?&287 to 0 in the Break key definition to stop the Ctrl+Break action working, but how can I disable the Break key, preferably without adding a new KEY10 definition to the program I want to be loaded on Break? Presumably I can poke somewhere to clear the KEY10 definition? Doing a *KEY10 within the first KEY10 definition is a no-no, because it results in a "Key in use" error message.

Also, Paul, you mentioned OSBYTE &F7-&F9 but then didn't appear to use that is there an OS-legal version of your patch?

Rich, I tried your patch on STH but couldn't get it to do anything - tried on two emulators. I'm not sure it does what I want, tho, from your description - I don't want to stop anyone from using Break (as Paul says, that would be annoying), I want to to catch the event once only and send them back to a menu.

Sam.

Just tried the following in BeebEm, based on the other code I posted - seems to work ok.

The easiest way I can think of is to use a different key definition then run it manually with the equivalent of *FX 138 in the break routine. That way, it can be disabled with a simple *FX 247,0


Most folks just seem to poke the code directly into &287, but if you want to use the OSBYTEs, replace line 90 with this:

OK, I've got both your examples working in test form ...

However, in practice, I'm trying to have it work behind the CH_EGG binary and it just hangs ...

I assumed it was to do with where the code is assembled so I've tried setting P% to &880 which I thought was safe in both examples, but that hasn't helped.

Possible, or am I in way over my head?

Sam.

P.S. Disc image attached with example code in SAMPDV2 and SAMRCH2, respectively.

Looking at it briefly, putting the code at &880 should have been okay. However, Chuckie Egg sets the flag at &258 which clears the memory on break so it was wiping out the patch.

On the model B, moving the patch to &140 protects it from the memory clear and that seems to work. The Master is more problematic. It looks like it clears out the break vector too meaning the patch never gets called.

Anyone know of a way around this? If the built-in memory clear can't be used, the break patch would have to undo the damage Chuckie Egg does to pages &B and &D.

Yep, compiling to &140 works with your patch on a basic Model B, though not with Rich's - I assume that's the fault of the &258 flag again.

Would be nice if I could find a way to make this work on a B+ and Master, though.

Sam.

Just to add, I tested and it works on the Electron as well - so it's just the B+ and Master.

I had a look through my Master reference manuals but couldn't find anywhere talking about the memory clear - though I may just not be looking in the right place.

Any suggestions, Rich?

Sam.

It doesn't look like it's possible to stop the break vector from being cleared on the master. The nearest thing to a solution I could think of was taking advantage of the fact that sideways ROMs are notified of a break. It might be possible to write a small service ROM (loaded into one of the master's SRAM banks) that catches the event and either makes the key definiton or re-sets the break vector. This does seem to be getting overly complicated though and, because of the requirement for an SRAM bank, still wouldn't work on a 64K B+.

Approaching it from the other angle, that is stopping Chuckie Egg from clearing the memory on reset, presents its own problem. The memory at &d00 is left full of junk which affects the way sideways ROMs are handled on break (Ctrl-Break works fine because that will reset the ROM table). I tried a few different ideas including trying to force Ctrl-Break behaviour on a normal break. This kind of worked, but on the master it always cleared out the break vector again.

So the question is, can the master be reset in such a way as to re-load the CMOS settings, re-build the ROM table in &d00 but not clear the vectors. And can it be done in a way that's compatible with all the other beeb models? I'm guessing not, but there's no harm in asking.

To be honest, Sam I think it would be better to just use the break key definition for the editor and leave the game as it is. That way, pressing Break simply quits out of the game, or pressing Shift-Break re-loads the menu, and it works on all machines. The simplest solution is often the best

Thanks, Paul.

I asked the question on the BBC Micro Mailing List here.

Looks like you're right - there isn't any simple way to achieve this on a beeb (though there was some mention of the sideways RAM not being cleared, so there might be a possibility of hiding something there. Though that might only work on MOS 3.2 anyway).

Unless anyone else comes up with a bright idea, I think I'll make it a BBC B/Electron only feature. Master / B+ owners can re-load the menu themselves (though it does require them to go through the main menu to get to the sub-menu in question).

Thanks for the effort you've put in investigating though, Paul. Really appreciate it!

Sam.

Oh, and of course, Rich as well!!!

Sam.

Hopefully one last, quick question. Paul, is it possible to modify your patch so it only works with Break (with the memory clear bit set- otherwise I'd use *KEY10!), but not Ctrl+Break?

Sam.

Sure, just replace the old line 50:


with this:

Paul,

Just tried your code amendment in two emulators, but it doesn't appear to change the behaviour i.e. both BREAK and CTRL+BREAK still call the key function. Here's what I'm running:


Am I doing it wrong?

Sam.

The instruction at line 50 should be LDA &028D (number 8, not letter B)

D'oh.

Yeah, that works great. Schoolboy error.

Thanks, Paul. Much appreciated!

Sam.