6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Tue May 07, 2024 2:19 pm

All times are UTC




Post new topic Reply to topic  [ 34 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Sat Oct 02, 2021 1:04 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3354
Location: Ontario, Canada
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. :P :idea:

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

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


Last edited by Dr Jefyll on Sat Oct 02, 2021 1:29 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
PostPosted: Sat Oct 02, 2021 1:28 pm 
Offline

Joined: Wed Jun 23, 2021 8:02 am
Posts: 165
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. :P :idea:

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.


Top
 Profile  
Reply with quote  
PostPosted: Sat Oct 02, 2021 1:40 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3354
Location: Ontario, Canada
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. :roll:

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

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Oct 03, 2021 2:07 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8176
Location: Midwestern USA
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.

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Oct 03, 2021 3:29 pm 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1076
Location: Albuquerque NM USA
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


Top
 Profile  
Reply with quote  
PostPosted: Sun Oct 03, 2021 3:58 pm 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3354
Location: Ontario, Canada
Sounds like a fun experiment, Bill.

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

-- Jeff

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Oct 03, 2021 8:02 pm 
Offline
User avatar

Joined: Tue Oct 25, 2016 8:56 pm
Posts: 360
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...

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 04, 2021 2:05 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8176
Location: Midwestern USA
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.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Oct 11, 2021 9:37 am 
Offline
User avatar

Joined: Tue Aug 11, 2020 3:45 am
Posts: 311
Location: A magnetic field
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.

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 11, 2021 5:17 pm 
Offline
User avatar

Joined: Tue Aug 11, 2020 3:45 am
Posts: 311
Location: A magnetic field
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:

Aug 1976 KIM-1 User Manual, Appendix E: Tape Format wrote:
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:
; 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.

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Nov 11, 2021 7:14 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8432
Location: Southern California
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.

_________________
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?


Top
 Profile  
Reply with quote  
PostPosted: Tue Nov 30, 2021 12:34 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8432
Location: Southern California
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:
;             ┌───────────────────────────────────────────────╖
;             │      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.

_________________
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?


Top
 Profile  
Reply with quote  
PostPosted: Tue Dec 21, 2021 7:08 pm 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1076
Location: Albuquerque NM USA
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


Top
 Profile  
Reply with quote  
PostPosted: Sun Dec 26, 2021 8:37 pm 
Offline
User avatar

Joined: Sun Dec 26, 2021 8:27 pm
Posts: 182
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/

_________________
---
New new new new new video out! Serial Bootloader for my 65uino
Also, check out: I2C on a 6502 Single Board Computer
and Complete hardware overview of my 6502 SBC R1 :)


Top
 Profile  
Reply with quote  
PostPosted: Wed Dec 29, 2021 4:11 am 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1076
Location: Albuquerque NM USA
Got this 16x16 WS2812B panel in the mail today. Don't let anyone tell you different, size does matter! :lol:

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


Attachments:
DSC_67111228.jpg
DSC_67111228.jpg [ 1.28 MiB | Viewed 854 times ]
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 34 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: Google [Bot] and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: