The BRK instruction is a very important tool for software development as this is the way to stop a program at a selected brake point and to have the status flags pushed to the stack where they then can be retrieved. There is really no other way to do this! The brake flag can then be used to distinguish between an interrupt and a brake instruction.

In most cases there is anyway no interrupts during program development and the bit does not need to be tested. But if it need to be tested the MOS Progrmming manual recommends the following code:

PLA ; LOAD STATUS REGISTER
PHA ; RESTORE ONTO STACK
AND #$10 ; ISOLATE B FLAG
BNE BRKP ;BRANCH TO BRAKE PROGRAMMING
normal Interrupt Processing

> The BRK instruction is a very important tool for software development
> as this is the way to stop a program at a selected brake point and to
> have the status flags pushed to the stack where they then can be
> retrieved. There is really no other way to do this!

One method I used a lot in the 80s was JSR BREAK, where BREAK was the name of a routine more-or-less like a monitor routine and very flexible for investigating and altering memory and processor registers (including the status) from how the program left them at that point where BREAK was called. The JSR does not alter the status register P, and BREAK did push P so you could still test all the flags except B (which there was no need to test). If you didn't intentionally change anything, exiting BREAK would return you to the program where you left off, with all registers and status the same as they would have been had the JSR BREAK never been inserted there. The JSR put the return address on the stack so you can still tell where the routine was called from.

Yes, we could have done it with a BRK instruction, but that would have made for a little more overhead on our interrupt-service routine. Actually the whole thing would not have mattered much either way. The only time I've used BRK was in that first microprocessor class in 1982 when we were using the AIM-65 and wrote very small routines for assignments and always ended with BRK to return to the monitor program because that's what the teacher told us to do. I'm sure there was a way to interrupt a program with BRK and poke around before continuing execution of our program, but we didn't get that far in that class. I've never used BRK since.

>In most cases there is anyway no interrupts during program development

If you are using a port on the computer to feed it the new code to try or to feed it instructions to display or modify something, that port will most likely be interrupt-driven. The port and the interrupts would of course not be necessary if you just keep programming new EPROMs to put in a ZIF socket. This process is not nearly as tedious as it used to be years ago, now with assemblers that only take a second to do their job on a fast computer and with EPROM programmers that can program an 8Kx8 EPROM as fast as you can put it in the programming socket and take it back out.

I've had applications I was developing where the whole purpose was centered around very fast interrupt service though, so the related interrupts were started early in the project. In this case though, even the source code was fed to the workbench computer over the interrupt-driven serial port, and the computer would take that source text and compile, assemble, or execute as appropriate, on the fly (IOW, while the text was coming in), sometimes while the new interrupt-centered job was already running in the background and I was modifying what was being done with those interrupts. Once interrupts and program modularity are understood, it is not complicated at all to be doing all these things at once.

The BBC MOS uses BRKs to signal errors, eg:

The IRQ handler is:

_________________
--
JGH - http://mdfs.net

Hi Everyone,

Just been reading through this topic about the uses for BRK and practical application thereof. I guess that you haven't done too much with BBC Basic on the original 6502 based BBC machines. This used BRK as a neat way of error handling. Or rather (IIRC) the BBC MOS' default BRK handler did this.

Basically, whenever BBC BASIC needed to generate an error it just did BRK, <single byte error code>, "Zero terminated ASCII Error Message". I'd have to check the exact mechanism by which this worked as I can't remember exactly the bits BASIC and the MOS did in handling this but it was jolly useful. When developing ROM software (or any 6502 code) on the Beeb, anytime one needed to generate a nice error message on the screen one just inserted $00, <My error code>, "My error!", $00.


George

This BBC handling of error messages seems to agree with the suggestion made earlier that OS calls can be made using the BRK instruction. Apparently the BBC uses an error code following the BRK, which on a different system could just as well be a request for a system service, like using INT 21 in MS-DOS (in this case, it might look like "BRK 21" or in assembly, BRK followed by .db $21). It seems just as well to use jump tables like the C64 did, except you have to know a service's address instead of using its call code.

Scott

I've read a lot of times the BRK instruction was intended to patch buggy EPROMS, but after taking a look at the transistor-level schematic of the NMOS 6502 I must disagree with that. When the IRQ input and the I flag are both low a control line also goes low. This line can be read as the B flag in the status register, but it also has another interesting effect: It loads the instruction register with $00 during the following SYNC cycle, regardless of what op-code is present on the data bus.
So, a hardware interrupt effectively fetches a BRK instruction into the instruction register, and this instruction pushes the flags into the stack, including the B line that is still low. Then, it sets the I flag and this makes the B line to go high again.
Therefore, the EPROM-patching use of the BRK instruction was, probably, just a coincidence. The op-code $00 is easier to force than any other in a NMOS technology because it only requires an n-channel transistor per bit.

BTW, I'm also curious about the hardware implementation of NMI and RESET. They seem to be handled independently of IRQ/BRK in spite of having a lot in common. One interesting thing I found is that the RESET decrements the stack pointer by 3 but it does not store anything on the stack. The A, X, and Y registers, and most of the flags are not changed by RESET.

On NMOS 6502s IIRC an interrupt arriving at the same time as a BRK opcode would mask the BRK opcode, so only the interrupt got executed. So this would only reliably work on a CMOS version.

André

Not buggy EPROMs, buggy PROMs. The use of BRK to patch up PROMs during software development was quite common.

Way back in the day (probably before you were alive), PROMs often had an unwritten patch area, as well as an area in which a generic BRK handler was present. If a problem was discovered in a routine, it was possible to patch it by inserting a BRK into the proper location, which on a PROM could be accomplished by blowing all the fuses at that point. The generic BRK handler was pointed to a look-up table in the unwritten area, which in turn, contained addresses at which BRKs had been inserted for patching. A parallel table was populated with the addresses of the patches themselves. A stack sniff in the BRK handler would compare the address pushed to the stack against the first look-up table, which would result in an index that could be used on the second table to select the appropriate patch. The address of that patch would be written to the stack in place of the address that was stored on the stack as part of the BRK processing. When RTI was executed, the MPU would resume at the patch.

The alternative to all this rigmarole would have been to discard the PROM and burn a new one. Burning an entire PROM in those days was a slow process, and the PROMs themselves weren't cheap. Hence the use of BRK in PROM patching. Obviously, this wouldn't be necessary with an EPROM, as the E means erasable.

BTW, PROMs still are in production, although you may better know them by the term one-time programmable (OTP) EPROMs.


That's correct.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

It seems like there ought to be some really fast ones, if they have the fuses you blow to program them. I haven't found any yet though.

Look at the OTP EPROMs sold by Mouser, Digi-Key, etc. Parts in PDIP packages are available with 45 ns access time. Not fast enough to stay with a 65C816 at 20 MHz, of course, but still able to keep up at 12 MHz or so if the glue logic doesn't get in the way. A little judicious wait-stating with a PLD...

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!