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.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

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

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

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

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).

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Also IIRC the 816 is lacking SOB, right?

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

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.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

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

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


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.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

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.

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

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.



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...

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

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.

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

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.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.