65816 EMU Pin and WS2812B Digital LEDs

[Sheep64]

I'm disappointed that very few people use a 65816's MX or EMU pin. I presume that Bill Mensch is more disappointed.

The MX pin provides a 65816's two modal 8/16 bits during each clock phase and is intended to extend functionality, for example, during 16 bit I/O. The EMU pin provides emulation/native status and may be used within a privilege system. At the very least, 65816 enthusiasts should consider adding a turbo light to their systems.

A more advanced use involves WS2812 LEDs (sometime sold at a 3x inflated price under the NeoPixel brand). These lights presumably use a analog servo style capacitor and comparator arrangement to derive Morse code type data from a self clocking signal. They can be daisy-chained into arrangements exceeding 1000 lights. However, they are quite bright given that they are intended for signage and the RGB or RGBW lights typically draw 20mA per section.

WS2812 protocol is very simple. One byte per channel is sent most significant bit first. There is no padding byte for any variant and the order of each channel varies although green, red, blue may be the most common variant; possibly to aid heat dissipation of the gallium green and gallium blue channels.

A zero bit is represent by a pulse which is shorter than 350ns. A one bit is represented by a pulse which is longer than 700ns. In either case, a cycle shorter than 900ns should not occur because one device within the daisy-chain may be conveying a long pulse to the next device. The shift register chain (which may exceed 32000 bits) is set live after a period of inactivity. Different variants have an inactivity period which ranges from 6000ns to 50000ns. Inactivity presumably sets a 256 cycle PWM duty which is run from an internal oscillator. In different applications, it may be beneficial to shift out one byte, three bytes, four bytes or the entire chain before shifting falls into the dormant state.

With masked interrupts, appropriate NOP cycles and a latch for EMU pin validity, it is possible to repeatedly clear or set emulation mode within a 65816. If one or more WS2812 LEDs are daisy-chained to the 65816's EMU pin, appropriate RGB data can be shifted to the programmable LEDs. By this mechanism, it is possible to send debug information or general purpose status to a short chain of WS2812 lights.

If you have a large quantity of WS2812 LEDs, it is possible to skip transfer via the EMU pin. Instead, apply the double 8*8 binary matrix transpose and drive up to eight chains concurrently. 6502/65816 is particularly suited to this task given that the transpose may require less than five clock cycles per bit. However, if you have a very small quantity of WS2812 lights, functionality specific to 65816 provides a relatively transparent output channel.

[drogon]

Sheep64 wrote:

I'm disappointed that very few people use a 65816's MX or EMU pin. I presume that Bill Mensch is more disappointed.

The MX pin provides a 65816's two modal 8/16 bits during each clock phase and is intended to extend functionality, for example, during 16 bit I/O. The EMU pin provides emulation/native status and may be used within a privilege system. At the very least, 65816 enthusiasts should consider adding a turbo light to their systems.

I use the E output pin to drive an LED in my Ruby '816 boards. I have wired it so that in native '816 mode it's off and in emulation mode it's on. So ON for Emulation. My OS runs in emulation mode, so at power on, it's a 65C02, so it's up to applications to switch to native mode, if they need to. The main reason for this is that I run a lot of 65C02 code so they "just work" - e.g. BBC Basic, Comal, EhBASIC, etc. ...

It's sort of handy and a nice indicator, but I've not really considered it for anything other than a bit of bling.

As for LED control - the WS2801 controller is much easier to interface with - clock + data rather than nanoseconds timings for the ws2812's ...

-Gordon

[BigDumbDinosaur]

Sheep64 wrote:

The MX pin provides a 65816's two modal 8/16 bits during each clock phase and is intended to extend functionality, for example, during 16 bit I/O.

I've yet to think of a good use for M/X. That it is a multiplexed signal makes it a pain in the *** to use. It's bad enough that A16-A23 are muxed on D0-D7. I can't see bothering with yet another muxed signal with no obvious (to me) value. What WDC should have done is make that pin a bank $00 signal, which would be vastly more useful.

Speaking of seldom- or unused pins, VPB is one of them. That it goes low during cycles 7 and 8 of an interrupt acknowledgement sequence makes it handy to tell hardware when any interrupt is being serviced. Such a feature could be used for temporary privilege escalation, for example. Or it could be used to make a change to the memory map. Or it could be wired to an LED to make it blink when interrupts are being serviced. Or...

drogon wrote:

I use the E output pin to drive an LED in my Ruby '816 boards. I have wired it so that in native '816 mode it's off and in emulation mode it's on.

Funny how great(?) minds think alike. My under-construction POC V2.0 unit has the same configuration.

Quote:

My OS runs in emulation mode...

In contrast, I don't use emulation mode at all. However, starting with POC V2.0, should a memory fault be detected during POST, the MPU will be switched back to emulation mode and halted with STP. That will cause the emulation mode indicator to be continuously illuminated to indicate a "machine check exception."

[Dr Jefyll]

In some contexts, the 65816's E output pin can be a handy way to tell the Outside World, "I'm done initialization now."

That's how I used E as part of this project: Ultra-minimal 3-wire Interface boots up 65xx CPU's The interface works by taking over the CPU clock and data bus (using only 3 wires!). But after RAM is loaded with the desired contents, you typically need a way to switch to a normal clock source, ignoring the 3-wire and using a free-running oscillator instead.

An output port pin from a VIA would be one way to switch the clock source, but on an '816 computer the E output is probably unused, and you might as well use that instead.

The bootup begins by resetting the CPU, and the E output conveniently responds by going high. E being high deselects the oscillator in favor of the clock supplied by the 3-wire. Emulation Mode is entirely adequate for the bootup process, so all goes smoothly and eventually RAM will be initialized and your program will begin execution.

And, at or near the beginning of your program is the XCE instruction that causes E to go low. Up until now you've been single-stepping, albeit at fairly high speed. But when the clock mux switches over, you'll take off like a slingshot!

-- Jeff

[Alarm Siren]

BigDumbDinosaur wrote:

Speaking of seldom- or unused pins, VPB is one of them. That it goes low during cycles 7 and 8 of an interrupt acknowledgement sequence makes it handy to tell hardware when any interrupt is being serviced. Such a feature could be used for temporary privilege escalation, for example.

The project is currently on hold, but I was working on a MMU/Security coprocessor for 65C02 which used the VPB output to switch into Kernel mode and to "force" some of the MMU memory banks into Kernel space. On the subject of disused pins, it also uses the SOB pin to reply status info about the MMU in response to certain NOP instructions. If I ever get this project finished, I would like to make a 65816 version too, but that will obviously have to be quite different - it would definitely need to use E, (because it sniffs the bus for privileged instructions which vary depending on whether you're in Emulation or Native modes).

[fachat]

Also IIRC the 816 is lacking SOB, right?

[Alarm Siren]

fachat wrote:

Also IIRC the 816 is lacking SOB, right?

Yes, so the 65816 version would need a different route for the "Sideband Data" as my notes refer to it. Equally the whole design would be quite different though, I would suspect, for example: it wouldn't be necessary to have the NOOP and NMI generator as per the 65C02 design, as the same effect could be achieved with the 65816's native ABORTB input.


Another idea: If you have a system always intended to run in Native mode, aside from some initial boot-up code, you could use the E pin to swap out the boot ROM for RAM (or a different ROM) and/or use E to trigger a faster system clock. You could even use the Native-to-Emulation edge on E to force a reset of the system (or an NMI/ABORT which puts the system back into Native mode as quickly as possible), if you wanted to really enforce that native-mode-only design.

[BigDumbDinosaur]

Alarm Siren wrote:

Another idea: If you have a system always intended to run in Native mode, aside from some initial boot-up code, you could use the E pin to swap out the boot ROM for RAM (or a different ROM) and/or use E to trigger a faster system clock. You could even use the Native-to-Emulation edge on E to force a reset of the system (or an NMI/ABORT which puts the system back into Native mode as quickly as possible), if you wanted to really enforce that native-mode-only design.

Using ABORT is a bit tricky, timing-wise.  Going by what is said in the 65C816’s data sheet, ABORT should be held low for one clock cycle only, which suggests that whatever is driving ABORT would be a sort of state machine and would have to monitor both VDA and VPA to differentiate between an opcode fetch and a read or write of memory or I/O.  It would make for some interesting and challenging glue logic design.

I will note that asserting ABORT does not cause the 816 to actually abort an instruction.  What it does is prevent an instruction from making any computational changes to registers or, if correctly timed in the case of R-M-W instructions, memory.  Hence use of ABORT alone is ineffective in preventing the execution of privileged or "dangerous" instructions—STP falls into the latter category.  System logic would have to sample the data bus when VDA && VPA is true to detect such instructions and then take action, such as changing the instruction to a NOP or WDM, followed by asserting ABORT to trigger actions that would terminate the process trying to use the "illegal" instruction.

Where ABORT would be of best use would be in dealing with the case of the 65C816 placing an address on the bus that points to off-limits or non-existent memory, e.g., a page fault.  Even there, ABORT could get you into trouble.  For example, if the stack is pointed to non-existent memory, resulting in a page fault and ABORT being asserted, the MPU will try to push PB, PC and SR to the non-existent memory, causing a second page fault and ABORT being asserted again.  The 816 will auger in due to continuous page-faulting.  So the glue logic would have to figure out how to prevent such a sequence from happening.

[Alarm Siren]

BigDumbDinosaur wrote:

System logic would have to sample the data bus when VDA && VPA is true to detect such instructions and then take action, such as changing the instruction to a NOP or WDM, followed by asserting ABORT to trigger actions that would terminate the process trying to use the "illegal" instruction.

This is exactly what the aforementioned MMU/Security coprocessor project does for 65C02. It is constantly sniffing the bus for "dangerous" instruction opcodes whilst SYNC is high. If it sees one whilst in User mode, it overrides it and forces a NOP on to the bus then triggers an NMI.

As 65C02 does not have Abort, the copro can't directly do memory protection, so instead it relies on simply mapping out areas of RAM that the user-mode software shouldn't be able to access. When something triggers Kernel mode, the MMU swaps two of the MMU bank registers to Kernel Mode shadow registers, so that Kernel mode always has a known MMU state that cannot be affected by user mode software.

Anyway, to address the main point of your larger post, yes I know ABORT is tricky, really it was just a thought/aside. Having said that, if its only being used to stop from going back into emulation mode, I think it would actually be fairly simple to work with. You don't need to worry about page/memory issues, the ABORT pulse can be generated by feeding E into a positive-edge-detector, and your ABORT handler could (potentially) be as simple as

Code: Select all

XCE
RTI

EDIT: The code would also need to increment the saved return address past the original offending XCE instruction, or it would get stuck in a loop.

[BigEd]

It sounds to me likely that no-one here has used ABORT in a real system - would that be right? If the best we have is careful reading of the documentation, on past experience that's likely not to be quite enough to go by - it's enough advice to decide to steer clear of ABORT if we're cautious, but not enough to tell us how it might be used in practice, without some experimentation.

[BigDumbDinosaur]

BigEd wrote:

It sounds to me likely that no-one here has used ABORT in a real system - would that be right?

Apparently so.  Some years ago, I was in contact with Bill Mensch about ABORTB and what exactly were its effects.  At the time, he said I was only the second or third person who had ever inquired about ABORTB.  It was in that “conversation” (via E-mail) that I learned that what was being aborted was computational change to registers or, if a R-M-W instruction, memory.  All steps of the "aborted" instruction are carried out, and the 816 doesn’t acknowledge the abort interrupt until the instruction has finished, same as with any other interrupt.

Quote:

If the best we have is careful reading of the documentation, on past experience that’s likely not to be quite enough to go by - it’s enough advice to decide to steer clear of ABORT if we’re cautious, but not enough to tell us how it might be used in practice, without some experimentation.

If one is to experiment with ABORTB then one needs a feature in the circuit that can toggle ABORTB at specific times during an instruction cycle.  I’ve identified those times as being during the opcode fetch, for reasons previously described, or when the 816 places an address on the bus for the purpose of fetching or storing data.  In the case of a R-M-W instruction, such as INC or TSB, the latter occurs several times, since the sequence is read, internal operation, write, with MLB going low after the effective address has been emitted (starting at cycle 4).  Conceptually, the “point of no return” in a R-M-W instruction is reached when MLB is asserted, as at that time, a read will occur.  If the read generates a page fault, an abort must occur in the same cycle.  Otherwise, the time to assert ABORTB will have come and gone.

The circuit that would be in control of ABORT would have to latch so only a single toggle of ABORT can occur, even in the face of multiple abortable conditions.  Once the abort vector has been taken and appropriate code executed the latch can be cleared.

[Alarm Siren]

BigDumbDinosaur wrote:

Apparently so. Some years ago, I was in contact with Bill Mensch about ABORT and what exactly were its effects. At the time, he said I was only the second or third person who had ever inquired about ABORT. It was in that "conversation" (via E-mail) that I learned that what was being aborted was computational changes to registers and memory, not the instruction itself. All steps of the "aborted" instruction are carried out, and the 816 doesn't acknowledge the abort interrupt until the instruction has finished, same as with any other interrupt.

I believe all of this behaviour is documented in the 65816 datasheet? Though, of course, I suppose it may not have done so at the time of your conversation with Mr Mensch.

BigDumbDinosaur wrote:

If one is to experiment with ABORT then one needs a feature in the circuit that can toggle ABORT at specific times during an instruction cycle. I've identified those times as being during the opcode fetch, for reasons previously described, or when the 816 places an address on the bus for the purpose of fetching or storing data. In the case of a R-M-W instruction, such as INC or TSB, the latter occurs several times, since the sequence is read, (read) and write. Ergo the circuit that would be in control of ABORT would have to latch so only a single toggle of ABORT can occur. Once the abort vector has been taken and appropriate code executed the latch can be cleared.

I may be incorrect, but from my memory of past readings of the datasheet, it is implied that certain instructions which can access multiple memory locations cannot be safely aborted after certain point in their execution, specifcally after one address is read or written but before another, different one is. This means if you're using ABORT for memory protection / pages, that second address on those specific instructions could cause some serious headaches. I'll have to have another dive and see if I can find what I am remembering again...

[kernelthread]

BigDumbDinosaur wrote:

Apparently so. Some years ago, I was in contact with Bill Mensch about ABORT and what exactly were its effects. At the time, he said I was only the second or third person who had ever inquired about ABORT. It was in that "conversation" (via E-mail) that I learned that what was being aborted was computational changes to registers and memory, not the instruction itself. All steps of the "aborted" instruction are carried out, and the 816 doesn't acknowledge the abort interrupt until the instruction has finished, same as with any other interrupt.

From that description it sounds like the return address saved for the abort would be the instruction after the aborted one. That would make it quite tricky (well, impossible really) to fix up the fault and retry the instruction, unless your external logic also captured either the address of the last opcode fetch or the actual opcode fetched.

[BigDumbDinosaur]

Alarm Siren wrote:

I believe all of this behaviour is documented in the 65816 datasheet? Though, of course, I suppose it may not have done so at the time of your conversation with Mr Mensch.

Back when I inquired, the data sheet didn’t make it clear.  WDC’s data sheets have varied in quality over the years and in some cases, have had outright errors.  In the current data sheet, something that is not mentioned at all is ABORT cannot prevent STP or WAI from doing what they do, which is internally halt the clock until an interrupt (reset in the case of STP) occurs.  WAI would not be much of a problem to handle (any hardware interrupt will clear it), but STP would be a real problem.

Quote:

I may be incorrect, but from my memory of past readings of the datasheet, it is implied that certain instructions which can access multiple memory locations cannot be safely aborted after certain point in their execution...

That is correct and is specific to R-M-W instructions.  If logic is watching for a memory fault or illegal access it should take action during the R cycle of the R-M-W instruction and immediately toggle ABORT.  The data sheet implies it is possible to safely "abort" the instruction during the M cycle, but if there is a fault with touching the data at the address being modified, it would be safer to "abort" during the R cycle.

kernelthread wrote:

From that description it sounds like the return address saved for the abort would be the instruction after the aborted one.

No sir.  When the MPU acknowledges ABORT the RTI address that is pushed is that of the aborted instruction’s opcode.  Assuming the abort handler doesn’t mess with stack contents, an RTI will take the 816 back to the "aborted" instruction, and that instruction will be again executed.

[Alarm Siren]

You're right, the datasheet does not mention that ABORT cannot stop the effects of WAI or STP.
That says to me that the ABORT pin really is only for enabling a memory protection/paging system, and nothing else. Any attempt to introduce security/privilege levels must necessarily include opcode sniffing for and removal of (at least) the STP opcode, or user-mode software can bring the whole show to a halt regardless of anything you're attached to ABORT.


Going way, way back to the OT: Whilst I have given a few potential uses for E, the only practical use I can think of for MX is some kind of in-circuit debugger, to help in decoding the opcodes as they fly past. In most cases you could probably figure out what's going on by observing VDA and VPA, but that takes a bit more guess work and can only be done after the next instruction starts - MX would allow you to decode in real time.