Return to Answer

Yes, that has been done many times. After all, and at first sight, it seems like a really nifty supervisor call type of instruction. Looking closely it does involve quite some address juggling. So much so that more performance-aware developers usually preferred to use JSR calls instead, as their return address can be used directly with less stack mangling as well (*2).

Sure, valid point - still, to understand why things have been made the way they are, it's always a good idea to keep in mind that the 6502 wasn't developed with a general purpose computer in mind, but embedded use. The whole point was to make a very cheap CPU and support it with (for that time) quite complex and versatile I/O companion chips (e.g. 653x type).

Yes, that has been done many times. After all, and at first sight, it seems like a really nifty SuperVisor Call type of instruction. Looking closely it does involve quite some address juggling. So much so that more performance-aware developers usually preferred to use JSR calls instead, as their return address can be used directly with less stack mangling as well (*2).

Sure, valid point - still, to understand why things have been made the way they are, it's always a good idea to keep in mind that the 6502 wasn't developed with a general purpose computer in mind, but embedded use. The whole point was to make a very cheap CPU and support it with (for that time) quite complex and versatile I/O companion chips integrating several previous separate components into one (e.g. 653x type).

It is quite well and in depth documented in the corresponding MCS 6500 Microcomputer Family Programming Manual of January 1976 (and all follow ups). Check page 144 and after for description, reasoning and examples.

I'd say it was quite intentional. With the 6500 being designed as an extrem low cost CPU, it was what could be achieved with a bare minimum in additional circuitry. So instead of setting up a separate vector the IRQ was used - in fact, BRK processing is even used to make IRQ/NMI/RES happen.

Part of this is as well the increment by two, as that's the default behaviour of a 6502 instructions, as all take two cycles at least. Single byte instructions need to explicite disable the increment during the second cycle. Since BRK isn't a normal instruction, intended to be executed in a regular sequence and situation, adding that correction wouldn't make any difference.

BRK was never intended to be more than a debugging aid. A use that never comes up in regular use, thus it's rather cumbersome detection and the need to readjust PC as well did not do much harm. In fact, being a debugging tool, readjusting the PC to the original instruction address and replacing the instruction overwritten (*1) had to be done anyway.

Yes, that has been done many of times. After all, and at first sight, it seams like a really nifty super visor call type of instruction. Looking close it does involve quite some address juggling. So much, that more performance aware developers usually preferred to use JSR calls instead, as their return address can be used direct with less stack mangling as well (*2).

Sure, valid point - still to understand why things have been made the way they are, it's always a good idea to keep in mind that the 6502 wasn't developed with a general purpose computer in mind, but embedded use. The whole point was to make a very cheap CPU and support it with (for that time) quite complex and versatile I/O companion chips (e.g. 653x type).

It is documented quite well and in depth in the corresponding MCS 6500 Microcomputer Family Programming Manual of January 1976 (and all follow ups). Check page 144 and after for description, reasoning and examples.

I'd say it was quite intentional. With the 6500 being designed as an extremely low cost CPU, it was what could be achieved with a bare minimum in additional circuitry. So instead of setting up a separate vector the IRQ vector was used - in fact, BRK processing is even used to make IRQ/NMI/RES happen.

The increment by two is part of this too, as that's the default behaviour of 6502 instructions, as all take two cycles at least. Single byte instructions need to explicitly disable the increment during the second cycle. Since BRK isn't a normal instruction, intended to be executed in a regular sequence and situation, adding that correction wouldn't make any difference.

BRK was never intended to be more than a debugging aid. A use that never comes up in regular use, thus its rather cumbersome detection and the need to readjust PC as well did not do much harm. In fact, being a debugging tool, readjusting the PC to the original instruction address and replacing the instruction overwritten (*1) had to be done anyway.

Yes, that has been done many times. After all, and at first sight, it seems like a really nifty supervisor call type of instruction. Looking closely it does involve quite some address juggling. So much so that more performance-aware developers usually preferred to use JSR calls instead, as their return address can be used directly with less stack mangling as well (*2).

Sure, valid point - still, to understand why things have been made the way they are, it's always a good idea to keep in mind that the 6502 wasn't developed with a general purpose computer in mind, but embedded use. The whole point was to make a very cheap CPU and support it with (for that time) quite complex and versatile I/O companion chips (e.g. 653x type).

I'd say it was quite intentional. With the 6500 being designed as an extrem low cost CPU, it was what could be archived with a bare minimum in additional circuitry. So instead of setting up a separate vector the IRQ was used - in fact, BRK processing is even used to make IRQ/NMI/RES happen.

I'd say it was quite intentional. With the 6500 being designed as an extrem low cost CPU, it was what could be achieved with a bare minimum in additional circuitry. So instead of setting up a separate vector the IRQ was used - in fact, BRK processing is even used to make IRQ/NMI/RES happen.