6502.org

The original motivating idea was not exactly what came out as the challenge: it was to have a routine which detects that a port is connected to something interesting as opposed to something else. An interesting connection will be pretty active on all pins. If the port isn't connected to something interesting, I don't want the main program to run, so the loop should not exit. The loop is running much faster than expected changes on the port: let's say we get at least 10 samples per pulse, for a not-especially-tightly-coded loop.

In this original scenario, it's not especially important if any transitions are missed, but I don't expect to miss any.

To make it a short and simple challenge (something which is fun) I added in the idea of waiting for two transitions. Waiting for one transition is too easy; counting to ten is too hard.

So, please have fun, and don't feel a need to tie down a specification.

Right, I think it was implicit in the original spec that the signals would be slow enough to make a software routine viable, otherwise a software routine would not have been requested. For faster signals you could build hardware that performs a similar function, and the corresponding software would just reset it, then watch for its status. Having written a software routine, you can then analyse it to see how fast it runs and whether that's fast enough in practice.

As for detecting ten transitions… cracks knuckles Obviously this is bigger and significantly slower than a routine which detects only two transitions per bit. It suffers slightly from the fact that TSB/TRB do not have indexed addressing modes, so I had to replace one TSB with an ORA/STA pair. I count exactly 200 cycles per sample; at 8MHz that is 25µs, so fmax of the input signals would be 20kHz.

More speed could be obtained by unrolling the inner loop, which would remove 46 cycles of loop overhead and permit using TSB again, at the expense of code size. I think that brings the total down to 120 cycles per loop, so that's significantly faster.

Another alternative approach, which saves ZP space now that there are more transitions than port bits, is to keep an individual counter per bit: Timing analysis is more difficult here because the loop body is no longer branch-free. But this example can be used to test for an arbitrary number of transitions on all bits, up to the capacity of a byte. A simpler version could simply count the total number of bit transitions.

I'm sensing that you may have an actual real-life use case for this code? If I'm right, and it's not for a top-secret defense project, when are you gonna spill the beans to us?

Well, it's turned out that my idea probably has no traction, for other reasons... but it's in the context of PiTubeDirect, where a Raspberry Pi sits on a 6502 bus and emulates an 8 bit peripheral. The GPU is running a tight loop to interpret and respond to device accesses. I thought it might be a useful safety feature to check that we are on a bus and not just connected to some other system, such as might happen if someone put the wrong SD card into their Pi, or had their Pi connected to an FPGA but with a different design loaded. But one of the usual supported situations has the Pi behind a bus interface which doesn't pass through all the bus traffic, so in that case the bus looks quiet anyhow. Detecting a busy bus is no longer a useful tactic.

Thanks for sharing! That was a fun little adventure, useful or not.

(I couldn't help but notice that hoglet was lurking during some of the thread activity)

With a WDC 6502, you can use SEI : WAI, and then IRQ has no latency at all as it just resumes execution.

BVC takes 3 cycles on a taken branch. WAI takes 3 cycles to set up, then resumes normal execution as soon as an IRQ arrives. With I set, the interrupt handler is not entered and the usual overhead does not exist. So the performance is at worst similar, and you don't have to give up having a reliable V flag for arithmetic.

Ok! Thats interesting. I never used the WAI since it was a WDC instruction, but for new designs that would make sense unless you need the IRQ for something else.

Thinking about it, the sync pulse would not be active if you use the WAI... so the flip-flops would not be transmitting and no IRQ signal would reach the mpu. It may work off the clock, but the IRQ would only trigger for one clock. Maybe its enough?

I believe /NMI is edge sensitive, but /IRQ is not - normally it would be sampled on a SYNC cycle. I think a single full cycle of IRQ is enough to wake up from WAI, though.

That's a good idea for an experiment!

Yes, I'm pretty sure that's right (although I'm not sure where /IRQ is sampled). /NMI can't be level sensitive, or it would interrupt its own handler before the source could be acknowledged. /IRQ doesn't have that problem, as interrupts are disabled while the handler is running. Instead, it has to be level sensitive, because another source might request an interrupt while the handler for the first is running, and you don't want to miss that.

Some Commodore 64 games used this behaviour of /NMI to protect again 'freezer' cartridges. These cartridges would assert /NMI and enable their ROM so they could handle it, then save the entire machine state to a file. That file can then be used to restart the game at the point it was frozen, bypassing any copy protection in its loader.

But what if the game triggers an NMI itself and never acknowledges it? The /NMI line will stay asserted, so when the cartridge tries to assert it again, nothing happens. The game might crash, because it now has the freezer's ROM in memory instead of its own code or data, but the freezer never gets to run.