_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Hmm... alright. It's an approach that's more than a little clunky, but I guess it could be coaxed to work in a lot of cases. Myself, I'd be more inclined to ignore the signature byte and instead look at the LS byte of the return address on stack. It's faster, and the LS byte should be sufficiently unique to prevent one BRK from being confused with another.

Admittedly, it's an approach that could require further measures for disambiguation if you have a large number of patches to keep track of. But I expect the same is even more true for the signature-byte approach.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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

I always had the feeling that it was intended as one-patch-per-prom approach; while you could use any of the methods outlined above, ideally you'd be fixing a single bug, and probably just for testing. Then you blow a new prom. Trying to keep track of significant numbers of patches is a pain, even with versioning tools (he said, looking at version 714 of the current product build )

Neil

I think the COP case was also a matter of having lemons and making lemonade ... the "signature" byte emerging from the accident of how BRK's implementation worked in practice with the instruction set, and then the opportunities offered by a signature byte being taken account of in the creation of the COP instruction.

I notice that ONEBYTE is a logic signal inside the 6502 which detects single-byte instructions (in order to stop the PC from over-incrementing) and it fires for NOP, as you'd expect, but not for BRK.

So, internally, BRK is not a single-byte instruction - despite the original datasheet describing it as such. I think that's an error in the datasheet, because BRK behaves very like a software interrupt: it pushes the status byte, and behaves cycle-by-cycle like an NMI or IRQ. And so RTI feels like the right way to return, if one ever did, and the way that works most naturally is to regard BYTE as followed by an operand byte. We could perhaps call it a dummy operand, but we seem to have landed on calling it a signature byte - same thing to the 6502, as the 6502 ignores it.

I don't expect it would be able to use the single byte op-code process ... the second cycle of a single-byte instruction is followed by the execution of the following instruction, where the second cycle of BRK is followed by the 3rd cycle of the IRQ/NMI process. Or, at the very least, it's likely a saving of transistors to just let it do the normal PC increment at the end of the second cycle before entering the third cycle of the IRQ/NMI process. So the "signature" gets read, and is on the databus, but it's never used.

One "clean" use of the signature byte is to deliberately insert breakpoints / watchpoints in test code -- in the source, rather than over-writing a PROM -- where the signature byte may be the low address for a table of jump vectors. That is easier to use if the 64KB address space is not fully populated, so a shipping board might have 4KB of ROM but the test set-up has 8KB, which gives plenty of extra space for both the break points and the break point handling code, with only the IRQ pass-on vector and the break-point function vectors having to be in scarce RAM.

An elaboration of that is a test rig for a board that snoops the execution of a BRK and has hardware responses to the value of the signature byte when it is read in the second cycle of the BRK process.

> I don't expect it would be able to use the single byte op-code process
Right, but the internals of the 6502 are more distributed than that - the sequencer is one thing, but the bit which controls PC increment is quite complex (and time-critical) and in the case of a one-byte instruction has to inhibit the PC increment. If BRK were one byte, then ONEBYTE would be in play, and it isn't.

As I noted, this is outside of my strike zone, but I guess in those terms what I am saying is the reverse of that ... that if it had been practicable to use the ONEBYTE, then it could have been a one-byte instruction.

Taking on board the information that the circuitry controlling the PC increment is time critical, then that makes it even more plausible that it wasn't simply to economize on transistors, but that running to use the parts of the IRQ/NMI circuitries that BRK needs made running the first two cycles like the first two cycles of the JSR opcode the straightforward implementation.

Oh right, I see what you mean now. So, indeed, ONEBYTE is built by selecting exactly the opcodes ending in 8 or A. That doesn't catch any in column 0, and we can see that in fact although not all instructions in column 0 are multibyte, none of them are immediately followed by the next instruction.
https://llx.com/Neil/a2/opcodes.html

So yes, with BRK in column 0 (a good place for it) it would have taken extra work to decode ONEBYTE.

And so, the value of PC pushed is as if it were a two byte instruction, as noted. And there are no more transistors used than absolutely necessary!

Aha! The smoking gun.

At least in the 65C816 instructions, the other instructions (opcodes other than %xxxx1x00) that are specified to hold the address bus at PC+1 in the 3rd cycle (in Emulation mode) are specified to be engaged in an internal operation (data bus = IO), so I wouldn't be surprised if in the (several design evolutions back) original NMOS design, "borrowing" their circuitries for holding PC would also borrow some internal operation that don't suit the BRK.

I guess whether the signature originated as a feature or as a "feature" depends on whether at an early stage someone said "hey, doing it this way means that the byte following BRK is asserted onto the data bus in cycle 2", and someone else said, "yeah, so it does ... I don't think that's an issue ... maybe somebody can put that to a useful purpose".

Yup. (And I see BruceRMcF has posted about this as I was typing the following.)

Almost all the 1-byte instructions are in columns $8 and $A, making them easy to detect. The other 1-byte instructions, RTI, RTS and arguably BRK, would require extra logic to detect... and for RTI and RTS there's no need, because a double increment of PC can be tolerated. (RTI and RTS will overwrite PC anyway.)

None of this contradicts my (admittedly unprovable) hypothesis that the signature byte is a quirk which later got recast as a feature. IOW, BRK was originally conceived as a 1-byte instruction. But the extra logic required to make it so was later either deliberately omitted or simply never got completed because there wasn't enough time, thus making BRK a 2-byte instruction with a dummy operand... and a long history of associated confusion.

BTW I should acknowledge some inconsistency in my remarks about having to adjust the return address on stack before doing an RTI. That adjustment isn't necessary if one accepts that BRK truly is a 2-byte instruction; you'd only do it if you wanted to make BRK behave as a 1-byte instruction as per the MOS Programming Manual. Apologies to all, and thanks to Ed for PM-ing me about this.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

(Crossed in the post - mostly replying to Bruce here...)

I think quite a few of these historical adventures end up pivoting on what someone intended, and that's really difficult to know. It's true that the early datasheets tabulate BRK as a one byte instruction, but it's also true that that PC is incremented twice.

We can sometimes find out what happened, less often why.

BTW I notice that what recent investigators call ONEBYTE is annotated on the big schematic as SBI1 - I would suppose that's single-byte-instruction.

(From what I know of the internals of the 6502, I would say there's no borrowing of machinery here - there are separate mechanisms. And I'm pretty sure "internal operation" is just a WDC term for "a read access which doesn't care what it reads" or what we might call a "dummy read". It's not that anything specific is happening, it's just that the databus isn't needed in that cycle.)

But it is clear enough that people have from time to time found it useful to put a value in that dummy operand to BRK.

Another question might be: which assemblers allow or require BRK to have an operand? I get the impression that most don't. One sense in which it's a one byte instruction is that the 6502 doesn't care about the byte following the BRK.

Kowalski has it as a selectable option.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

Yeah, when I say "borrowing circuitry", it's as an umbrella. Whether a circuit is designed at the outset to be triggered in distinctive operations or it was designed for one process and then it's noticed that it can be used in another process ... I'm not making any suggestions about which one was happening.

In my mind, it's often smart, economizing design, whether "serving multiple masters" was designed from the outset or discovered along the way.