65816 EMU Pin and WS2812B Digital LEDs

[Dr Jefyll]

Alarm Siren wrote:

the only practical use I can think of for MX is some kind of in-circuit debugger

Yeah, MX could be helpful for that. Sampling the data bus when VDA and VPA are high will usually tell you what opcode is about to be executed (exception: at the beginning of an interrupt sequence the CPU fetches an opcode then ignores it), but the opcode alone isn't enough to fully predict the cycles to come. There's no easy answer for predicting cycle variability that results from branches taken and page crossings, but at least MX can predict the variability that results from m and x. Example: LDA takes 1 additional cycle if m=0, and LDY takes 1 additional cycle if x=0.

Otherwise, it does kinda seem that MX is a solution looking for a problem.

Hm, what about the nuisance that results when you generally like to keep m=0 (ie, 16-bit accumulator) but are forced to set m=1 before accessing an 8-bit I/O device, then set m back to 0 again afterward? You could avoid the nuisance and just always leave m=0 if your hardware was smart enough to deselect the I/O device during the extra bus cycle.

You don't need MX to do this, but it might be helpful. (The non-MX approach would be to have the hardware simply look for and prevent two succesive accesses to the I/O device.)

ETA: another non-MX approach is to map the I/O device in a way that interleaves some unused locations. For example,

• address $xx0 maps to register 0 of the I/O device
  address $xx1 maps to nothing
  address $xx2 maps to register 1 of the I/O device
  address $xx3 maps to nothing
  etc

-- Jeff

[kernelthread]

Dr Jefyll wrote:

Hm, what about the nuisance that results when you generally like to keep m=0 (ie, 16-bit accumulator) but are forced to set m=1 before accessing an 8-bit I/O device, then set m back to 0 again afterward? You could avoid the nuisance and just always leave m=0 if your hardware was smart enough to deselect the I/O device during the extra bus cycle.

You don't need MX to do this, but it might be helpful. (The non-MX approach would be to have the hardware simply look for and prevent two succesive accesses to the I/O device.)

You could achieve a similar effect by arranging the memory map with I/O registers on even addresses only, with !A0 added as an extra term in generating I/O chip selects.

[Dr Jefyll]

Yes, of course you're right, kernelthread. As you were writing your post, I was editing mine. I guess it's pretty obvious I haven't had my second cup of coffee yet.

Still no resoundingly worthwhile raison d'etre for MX, though...

[BigDumbDinosaur]

Dr Jefyll wrote:

Still no resoundingly worthwhile raison d'etre for MX, though...

Just think if M/X had instead been rigged up so it was asserted when the effective address is in bank $00.  I, and I'm sure other 65C816 users, would be all over that, as it would simplify the glue logic quite a bit, especially if being done with discrete gates instead of a PLD.

[plasmo]

Returning to the original poster's point, it appears MX output has no usable function so there should not be any objections to use it to drive W2812B LED. As has been described in the original post, W2812B needs nominally 1.2uS return-to-zero pulse trains; 1/3 duty cycle for "zero" and 2/3 duty cycle for "one". Another word, pulse high of 400uS followed by pulse low of 800uS is a "zero"; and pulse high of 800uS followed by pulse low of 400uS is a "one". The tolerance is sloppy, something like +/- 150uS. Each W2812B needs 24 pulses to drive its 3 RGB LEDs, additional pulses are passed on to next LED. So assuming W65C816 is running at 14MHz, what sequence of code can generate a "0" and what sequence of code can generate "1" on the MX output?

I don't know the answer, but I have W2812B LED and I'm working on a W65C816 prototype so I can rig up the MX output to array of W1812B and drive it with the appropriate code.
BIll

[Dr Jefyll]

Sounds like a fun experiment, Bill.

BTW I think it's the E pin that was proposed (not MX).

-- Jeff

[Alarm Siren]

BigDumbDinosaur wrote:

Dr Jefyll wrote:

Still no resoundingly worthwhile raison d'etre for MX, though...

Just think if M/X had instead been rigged up so it was asserted when the effective address is in bank $00. I, and I'm sure other 65C816 users, would be all over that, as it would simplify the glue logic quite a bit, especially if being done with discrete gates instead of a PLD.

Could you please explain to me how such an output would help? I'm failing to see why that would be useful...

[BigDumbDinosaur]

Alarm Siren wrote:

BigDumbDinosaur wrote:

Just think if M/X had instead been rigged up so it was asserted when the effective address is in bank $00.  I, and I’m sure other 65C816 users, would be all over that, as it would simplify the glue logic quite a bit, especially if being done with discrete gates instead of a PLD.

Could you please explain to me how such an output would help? I’m failing to see why that would be useful...

Consider an 816 system in which ROM and I/O are in bank $00, and bank $01 and higher is all RAM.  Also, consider that ROM and I/O accesses are wait-stated because this is a high-speed system.  If the wait-state logic doesn’t recognize the difference between bank $00 and the higher banks, any access in which A0-A15 of the address would be ROM or I/O in bank $00 will result in a wait-state occurring, regardless of bank.  In banks $01 and higher, the system will be needlessly wait-stating RAM.

Also in the just-described system, recognizing bank $00 is necessary to map in ROM and I/O only when the effective address falls in bank $00.  If the decoding logic fails to account for bank $00 then ROM and I/O will mirror in every bank.

[Sheep64]

I hoped this topic would be more newbie friendly. Regardless, it has been an inadvertent survey of obscure pin usage. In particular, BigEd notes that Abort pin functionality may be completely unexplored. I am pleased to learn that 65816 EMU pin usage is quite widespread for clock selection and mode light functionality. Indeed, the major three uses of the EMU pin may not be contradictory. Specifically, it may be possible to use a 65816's EMU pin concurrently for clock selection, mode indicator light and a digital LED diagnostic channel - or any subset thereof.

Although the EMU pin is not specified as valid throughout a clock cycle, I suspect this provides a mechanism for upward compatibility. If EMU is multiplexed on two clock phases (like M/X) then it would be possible to indicate 8/16/32/64 bit operation during one bus cycle. It is genius that a 10th signal line may be derived with no additional pins and there is a pleasing symmetry in the manner that M/X and EMU could operate. Specifically, both may emit two flag bits per clock cycle. Rather than having a 4 bit or 8 bit latch retain 4 or 8 multiplexed address lines, it may be preferable to discard one or two address lines and instead latch one phase of M/X and/or EMU.

In the trivial case, I suspect that an EMU pin is wired directly to the emulation bit of the flag register and is therefore valid throughout one clock cycle. However, if you depend upon such undocumented functionality then your design may not be upward compatible. For example, if a hypothetical 65832 became available and 65816 chips were derived from the same manufacturing process then EMU pin functionality may change quite drastically. Such change may be unannounced because it remains within the published specification.

Anyhow, I recommend using WS2812B LEDs with a latch even if the latch is redundant. I don't say this as a pessimist. I say this as an optimist.

[Sheep64]

jfoucher's KimOne simulation prompted me to read the KIM-1 User Manual and this led to the startling discovery that a modulated but otherwise similar protocol to WS2812B was commonly used for magnetic storage:

Each transmitted bit begins with a 3700 hertz tone and ends with a 2400 hertz tone. "Ones" have the high to low frequency transition at one-third of the bit period. "Zeros" have the transition at two-thirds of the period.

After 23 mostly off-topic messages, no-one posted working software. I'm not impressed but I'll nudge the topic along by working from the inside of the loop:

Code: Select all

; assumes 65816 native mode upon entry and exit.
; send one bit to WS2812B chain.
; short pulse for zero and long pulse for one.

SEC
XCE
NOP
ROL A
XCE
NOP
CLC
XCE

Clock counts will be interesting - and especially so if a 65816's EMU pin is also used to select clock source. Preserving emulation mode and handling of the last bit may also be a problem. Admittedly, for many people using 65816, emulation mode is a very minor concern.

[GARTHWILSON]

Quote:

; short pulse for zero and long pulse for one.

I've been using an output bit for that on PIC microcontrollers for debugging, to show one or more bytes of interest. I got the idea from one of the electronic industry magazines' "Ideas for design" sections. There's usually a bit you can multiplex for this even on the 8-pin devices (maybe 5- and 6-pin ones too, but I've never used those). Using some given time period "t" whose length isn't critical as long as it stays consistent, I do 3t high then 3t low again to mark the start of the chain so it's easy to find on the oscilloscope, then each 0 is 1t high followed by 2t low, and each 1 is 2t high followed by 1t low, and bytes are separated by an extra 3t low time. That way, each bit starts on a schedule, so if I watch them for a while and they keep changing, they don't make the subsequent bits jitter in a way that would make them impossible to read visually. Interrupts will cause jitter too. To keep this brief, I won't go into how I deal with that.

Note however that when you go into '02-emulation mode on the '816, you will lose the high byte of the index registers and the high byte of the stack pointer.

[GARTHWILSON]

Here's a diagram to add to my post above, about using as little as a single pin to output status bytes from a microcontroller with extremely limited I/O. The pin could even be one that's being used for something else as long as you can let it go for short periods for the purpose. For example, you might have the pin driving an indicator LED and it won't hurt anything to have if flicker when you're outputting data during development; or even a pushbutton input, as long as you don't need to push the button while you're outputting the data. I've done this with PICs having as few as 8 pins (the PIC12's). There are others even in SOT-23 packages with only 5 or 6 pins (although I have not used those, so far). This is copy-and-pasted from the comments in the source code for a work project I did a few years ago. The clock speed is not important, only the relative lengths of the high and low pulses.

Code: Select all

;             ┌───────────────────────────────────────────────╖
;             │      OUTPUT STATUS  (for troubleshooting)     ║
;             ╘═══════════════════════════════════════════════╝
;
; This status reporting is only for debugging.  It's not needed in the production units.
; Reporting by serial bit stream will be on PC4.  We'll start with a 1.5ms high pulse as a start bit, followed by a 1.5ms low
;   time, and then each 0 after that will be .5ms hi + 1ms lo, and each 1 will be 1ms hi + .5ms lo, so a bit starts every 1.5ms,
;   on a schedule.  There's an extra 1.5ms low time between bytes.  Interrupts will need to be turned off temporarily to avoid
;   jitter that would make it difficult to see the pattern repeating on an analog 'scope, as well as making sure short pulses
;   don't get too long.
; To make it easier to see where the start bit of a multi-byte report is with a dual-trace 'scope, PC3 (pin 14) is pulsed low.
;
;
;      low 1.5ms to make        Start     then  ┌────────── example 01001011, or $4B ──────────┐      ┌── start next byte
;      start bit visible─┐      1.5ms     1.5ms
;                        │       high      low    0     1     0     0     1     0     1     1           0     0
;             ───────┐   V    ┌────────┐        ┌─┐   ┌───┐ ┌─┐   ┌─┐   ┌───┐ ┌─┐   ┌───┐ ┌───┐       ┌─┐   ┌─┐   ┌─ . . .
; (PC4 pin 15)───────┴────────┘        └────────┘ └───┘   └─┘ └───┘ └───┘   └─┘ └───┘   └─┘   └───────┘ └───┘ └───┘
;
; (PC3 pin 14)────────────────┐        ┌─────────────────────────────────────────────────────────────────────────────────────────
; (for triggering)            └────────┘
;                                                                                               └──┬──┘
;                             └────────┬───────┘                                                   │
;                                      └─start bit                     1.5ms extra between bytes───┘
;
;
; Since it is not always desirable for the the status report to run every time OUTPUT_STATUS is encountered in the program, it
;   will look at PC5, pin 16, which has a passive pull-up.  If the switch to ground is open, it won't report.
; If you want it to keep reporting continually, you'll have to call it from a loop.
; Byte at RAM address REPORT_ARRAY is sent first.  Bytes are sent msb-first.
; To use OUTPUT_STATUS, put the bytes you want to output in REPORT_ARRAY, and put the number of bytes to report in REPORT_COUNT.
;   REPORT_COUNT will get decremented to 0 during the reporting, so the program must re-initialize it before each call.
; ══════════ NOTE !! If you call OUTPUT_STATUS repeatedly in a loop, you must re-init REPORT_COUNT every time! ══════════

I'll leave the actual program code out since it's not 65xx, unless someone asks for it. It's in PIC assembly language with a lot of macros.

[plasmo]

Sheep64 wrote:

I hoped this topic would be more newbie friendly.

I did find a couple applications for MX pin that's user friendly, i.e. no external hardware support logic required, just hook up the device directly to MX pin.
1. Bit-bang serial transmitter.
2. Bit-bang WS2812B driver. This requires a fairly fast W65C816 because of the sub-microsecond timing requirements.
Bill

[AndersNielsen]

I managed to drive a strip of WS2812B’s with a 2mhz 6502

…and a shift reg.

https://abnielsen.com/2021/12/23/ws2812 ... on-a-6502/

[plasmo]

Got this 16x16 WS2812B panel in the mail today. Don't let anyone tell you different, size does matter!

Each LED takes 24 pulses at 800KHz, so 7.4mS to paint the 16x16 screen. It is certainly fast enough to animate. So what can I do with this? Sure, a bigger Christmas tree with blinking light; and it is big enough for Game of Life and maybe Tetris. What else? This is a $20 solution looking for a problem.
Bill