Here’s another WDC datasheet gotcha. On page 43 of the 65c816 datasheet, we see “COP latches” as number 16 in the list but what does this mean? Does anyone have any theories?
Those numbered items refer to the “Notes” column on the previous pages, but number 16 isn’t associated with anything…
The datasheet does keep changing, but it’s always confusing, ambiguous, misleading…
My best guess would be that some external circuitry is being described - COP was intended as a coprocessor callout, so the hypothesised coprocessor will need to be watching the instruction stream and might ideally capture the operand byte which follows the opcode. (The x87 did something similar, I think. It’s not so easy to cope with all cases.)
Edit to add:
I don’t know of any hardware systems which used COP. It is useful in emulators to call out to emulator facilities.
Elsewhere I wrote this
On the usefulness of 65816 as a 65C02 alternative
Certainly some hobby projects have used the 816, as did some back-in-the-day accelerators for 6502 systems. But as a choice for the main CPU, I only know of Apple IIgs, and Acorn’s Communicator.
The Super Nintendo Entertainment System (Super Famicom in Japan and possibly the European market) used a Ricoh 5A22 clone of the 65C816. It has a 65816-compatible core along with some peripheral devices and a bus-mapped math coprocessor for integer multiply and divide.
Ah, of course! I tend to concentrate on computers, but consoles are also a big market, sometimes bigger…
Approximately 49.1 million Super NES consoles were sold worldwide, with 23.35 million of those units sold in the Americas and 17.17 million in Japan. Although it could not quite repeat the success of the NES, which sold 61.91 million units worldwide, the Super NES was the best-selling console of its era.
The hardware multiplier/divider is triggered by writing to registers and not COP, so I don’t think we’re going to get very far there:
https://problemkaputt.de/fullsnes.htm#snesmathsmultiplydivide
Note (16) does appear in the table. It’s on p.42, item 22j but not in the Notes column. Rather, it’s in the Address Bus column (third from right). The entry actually says 0,S-3 (16). I’m not knowledgable about the 6502 family so I won’t speculate about what this means.
Good catch! I believe it means that COP latches the state of the status register, and then pushes it to the stack.
Ah, my guess was quite wrong. It leaves me a little baffled - the datasheet, going back to 2004, has a section which covers BRK and COP, with the footnote therefore intending to distinguish between the two. “COP Latches” and therefore “BRK doesn’t or hasn’t Latches”. It’s against the pushing of P, the processor status byte. I can’t think how BRK and COP might differ in their pushing of P.
Relevant snippet from “Table 6-7 Instruction Operation”:
Relevant footnotes:
- Special case for aborting instruction. This is the last cycle which may be aborted or the Status, PBR or DBRregisters will be updated.
- Subtract 1 cycle for 6502 emulation mode (E=1).
- RWB remains high during Reset.
- COP Latches.
Possibly we’d get some useful insights by posting over on 6502.org
I checked Bruce’s Tutorial and it didn’t enlighten me on this question.
I’m definetely out of my depth here (regarding the W65C816S), but could it be that “latch” refers to the data latch register? Meaning, P becomes available on the data bus (D0-D7)?
Hmm, that would give a hypothetical co-processor a visibility of the machine mode: 8 or 16 bit for accumulator and for index registers, and decimal mode. It would also need to sensitive to the E pin, which signals emulation mode. Such visibility could be important… so it’s a good thought. (Although I think I’m arguing again for an external latch - the P is necessarily on the databus as it’s being pushed in that cycle.)
I think, with BRK, P is available on the internal data bus – in the block schematic to the right of the data latch, but doesn’t propagate to the outside. In order to become available on the bus, we’d need to, well, latch this latch.
(The modifications required for COP are insignificant and cheap, while there’s definitely some use for this. So, arguably, you could come up with the idea of designing it this way.)
(BTW I’m wrong, in the sense that M and X are already visible on the MX output pin)
Hmm, if P is pushed, as it surely is, so it can be written to the stack, it must be visible externally. I can’t see any story where BRK and COP really have to differ, so this two-word footnote is a real puzzler for me.
Are you sure about this? While the data bus buffer register is always connected to the internal data bus on the 6502 (and the data latch register is connected to the address bus), on the W65C816S the internal data bus appears to be totally isolated from the outside. As far as I can tell, data has to go through the data latch (and the bank registers) in order to become available in the data/data-bank/address-buffer and thus on the external bus.
TBH I’m reluctant to read too much into the block diagram - WDC are so very unreliable when it comes to getting the details right.
I’ve asked over on 6502…
We might need a logical analyzer to be sure of the bus behavior. Maybe the coprocessor needs to see the status register through the system control pins, and the latching has to happen a little bit before the next instruction for the data to be on the pins in time. And perhaps since BRK is for software interrupts, and the BRK handler can just examine the status register with software, it doesn’t need to be on the pins as fast.
Here’s a comparison of the W65C816S and the mos6502 (NMOS) with highlighting of the relevant parts:
(I guess, while the WDC datasheets are certainly flawed, they can’t be that wrong…)
So, in my interpretation, on the 6502, P (SR) would indeed become available on the data bus as soon as it is pushed on the internal data bus, but on the W65C816S, access to the internal data bus is controlled by the data latch. Where the latch is only used to store input on the 6502, it is now used in both directions. I think, besides which vector is used, whether this latch is triggered or not is the crucial difference between BRK and COP.
Oh, so the 6502 didn’t have that data latch predecode? BRK was on the 6502 and COP wasn’t, so your interpretation does seem to make more sense than the latching being in regards to the system control pins.
Moreover, Bill Mensch seems to be quite specific about the use of “latch”: most often (if not always), it’s about what’s available on the bus.
Provided the block diagrams are somewhat correct, the difference is even more dramatic, as for the processor status register. On the 6502, there is no 8-bit connection to the internal data bus, there isn’t any from the P register to the internal bus, at all. This is all unidirectional. Rather, it connects to the instruction decoding circuitry and this to the other registers, and this is all bit-serial. (So P shouldn’t become visible during BRK, either, if not for any other registers or the ALU, while used for transfer to the stack.) I’m not sure, though, if this isn’t an oversimplification.
But all the “interrupts” both hardware and software, surely push P. So the value of P must appear on the external databus, to be written to RAM.
Now, on the 6502, there is no P register in the datapath, but the various bits of P are able to pull down the precharged bus so the constructed value of P can go out for a PHP.
(Also, the 6502 does have predecode logic. It’s there on the chip and in the schematic. If it didn’t make it to the block diagram, that’s another thing!)
