Not sure the best place to post this, so here it is...

I was tripped up recently in my Ruby 6502 SBC when using WAI.

WAI is great - I use it to communicate with my host processor (ATmega) which pulls BE low to grab the 6502 bus and then pings back with an IRQ to get the 6502 going again. (I detect WAI on the host by reading the Rdy line)

Enter NMI... NMI during WAI kick-starts the 6502 and it vectors off to the NMI vector, runs the NMI code and returns to the WAI. Great! Except when the 6502 is held in /BE mode, then it reads whatever comes off the tri-stated input data lines, ends up in never never land ...

So just mentioning this in-case anyone else starts to see unpredictable behaviour if using this scenario (WAI with /BE) in the vague hope a google, etc. search lands them here. The upshot is that letting the 6502 run when BE is low is not a good thing, and it will run if it gets an NMI or IRQ while BE is held low during WAI with nothing external also holding Rdy low.

So now when I detect Rdy low, I immediately pull it low to force the 6502 to halt for the duration, but it's introducing latency into my NMI code, so working on a plan B, however it does work. Host lets BE go high, then lets Rdy go high, 6502 immediately vectors off to do the NMI (if an NMI happened), then returns to the WAI where it finds IRQ low so carries on at the next instruction.

Cheers,

-Gordon

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

You should be able to avoid this behavior by disabling IRQs immediately before executing the WAI instruction. When an IRQ or NMI hits, the MPU will restart at the instruction immediately following WAI and will not take the IRQ or NMI vector.

Code:

;alternate usage of WAI instruction
;
         sei                   ;disable IRQs
         wai                   ;halt MPU & WAIt for IRQ or NMI
         nop                   ;execution continues here upon IRQ or NMI...
                               ;IRQ or NMI vector is not taken

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

Yes, RDY needs to be qualified by BE. The bidirectionality of the RDY pin can be a bit of a pain in this respect.

To restore your NMI latency, you'll need to make your coprocessor notice /NMI being asserted and voluntarily release the bus.

I do. Actually, I don't, but since I never enable the IRQ interrupt anywhere, it's the same thing. I'm taking full advantage of the zero latency interrupt thingy.

But you've got me thinking now and I may need to do some more tests - however - the net effect is the same - if the 6502 wakes up (unexpectedly due to NMI) while the host has BE pulled low then it's going to come to no good whatsoever. I'm fairly confident that the NMI is taken via it's vector though - it's being generated by a timer on a 6522 and if you don't read the bottom byte of the counter then it doesn't fire again (in free running mode) and it keeps on going...

I'm using BE as I have an area of shared RAM that I use between the 6502 and the host for comms - serial, etc. so right now the scenario is that I poll on the host for Rdy going low (WAI executed), then pull Rdy low, then pull BE low, then do the transaction, release BE then Rdy then wait for the next Rdy low. If an NMI comes in while I have Rdy pulled low then it's "remembered" until it goes high, then taken. (There is only one NMI source and if it's not serviced then it stops, so easy to tell if it's ever missed) Latency might be an issue if it were something other than a little hobby/vanity project but I'm happy that it just keeps on counting.

Cheers,

-Gordon

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

It's not that tricky to manage though - the host is an ATmega, so at power-up, I put the pin into output mode and set it low. Then change it to input mode to listen for Rdy being pulled low by the 6502 and at that point, I just change the pin to output mode and the previously set 0 output is remembered. I didn't need to pull it low by the ATmega until I started to fiddle with NMI though.

(The Rdy pin has a 3k3 pull-up)

Cheers,

-Gordon

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

Older topic here, but I have a question.



If you use SEI, then the IRQ interrupt vector won't be taken, but an NMI interrupt will jump to the NMI vector still, correct?

Also, since I'm here talking about it, on the 65816 datasheet (can't find it on the 6502 datasheet), there is a 'cycle by cycle' section [ screenshots below ]. For the WAI command, there is a 'setup time' between the processor seeing the WAI command, and then doing it's thing to shut down and bring RDY low. But while it's doing that, if NMI falls, wouldn't it automatically jump to the NMI vector when it's done with it's WAI command stuff? As in, in the 2 cycles between the processor seeing WAI and having RDY go low, an NMI would make the processor keep going and it might (or might not) just simply *toggle* the RDY line. Am I right here?



Thoughts?

Thank you.

Chad

My understanding is that it takes 1-2 cycles for the IRQ or NMI to make its way through to the point that it can cause an interrupt sequence on the next instruction fetch cycle. I suspect this is metastability protection, and I'd guess that it also takes that time to unblock WAI's second cycle. Then I'd expect the NMI sequence will occur on the next instruction fetch, as would an IRQ sequence if the interrupt disable bit was clear.

A few months ago I took some oscilloscope traces of this sort of thing, showing IRQ, RDY, PHI2, and SYNC I think. I'll see if I can find that thread and link it. Edit: here: viewtopic.php?f=4&t=7732 The scope trace in my second post show the details. But not what happens if an interrupt happens in the early stages of WAI. I do have a test rig that I could use quite easily to analyse that, deliberately triggering interrupts at various points relative to the WAI instruction.

That link was super excellent. It seems Gordon was having this issue I'm talking about, at least I believe that's what is going on.

If anyone else has more info I'd love to hear it. Right now I'm going to assume that a falling NMI between the 6502 reading WAI and driving RDY low will still cause it to jump to the NMI vector. But what does RDY look like? Does it stay high, or does it toggle within a half-cycle? Or does it stay low for a cycle or two?

Thank you George!

Chad

Here are the results of some tests using my Arduino rig. This was executing the sequence:


I triggered NMI in the middle of both phases of the clock, covering a few cycles either side of the WAI instruction. All samples and signal transitions take place halfway through the high or low phase.

Case 1 - NMI occured early enough to be processed before the WAI instruction (one and a half cycles before the WAI instruction's SYNC cycle):


Case 2 - one half cycle later; now WAI executes, and NMI is picked up a little later:


Case 3 - NMI occurs during low phase of WAI cycle 2 - this is the earliest it can occur while still seeing RDY go low at least for half a cycle:


Case 4 - NMI occurs several cycles after WAI, during the high phase of the clock:


Case 5 - NMI occurs one half-cycle later again, during the low phase of the clock:


In my notes above, I'm guessing where WAI's cycle 3 is because it's no different than cycle 2 as far as the external signals look. But I'm assuming cycle 2 is the only one that can repeat.

Overall, I think that as for any other instruction, if NMI occurs one-and-a-half clock cycles before the instruction's SYNC cycle, then the NMI sequence happens instead of the instruction, and the instruction waits until after the NMI handler has run. If NMI occurs later than that, then the instruction begins as usual.

In WAI's case, it looks like with an NMI that's early enough, RDY doesn't go low at all - however, I am only sampling it halfway through the high or low periods of the clock, I'm not watching for edges, and it's possible that it dips briefly then goes up again, e.g. on the rising edge of the PHI2 clock. I'm pretty sure I did observe this in my oscilloscope traces in the other post.

In general for WAI, after cycle 2 and RDY has gone low, then after an interrupt, on the next falling edge of the clock RDY will go high again, then cycle 2 will execute one more time, then cycle 3, then the WAI instruction has finished, and the interrupt interrupts the following instruction (if it's not masked). After the RTI control returns to that next instruction.

Note the edge case that it's possible for NMI to happen before RDY goes low, yet still have RDY go low for half a cycle.

Wow George, that is a VERY detailed response. Thank you so much for that!

Like you said, it *can* go low, but it also *can* stay high, depending on when it falls. Also, as you said, it could possibly toggle in between a half-cycle, but still, it's interesting to see this behavior.

Ok, good to know! I'm rethinking my plans using NMI and WAI together. Thank you George. I hope this data is useful to some other folks out there!

Chad

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

Hi Garth, I meant to ask but forgot - what was this tester you were using, did you publish the details anywhere?

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