Direct reg access / misc. tips

[GTBecker]

Even with external hardware, the speed is not instantaneous, and if two quadrature events are too closely spaced, they still will not be resolved into separate events. It is just that external hardware can operate several orders of magnitude faster than anything on the ZX hardware.

An edge is, by definition, instantaneous; in our realm, it _is_ an instant.

[spamiam]

Even with external hardware, the speed is not instantaneous, and if two quadrature events are too closely spaced, they still will not be resolved into separate events. It is just that external hardware can operate several orders of magnitude faster than anything on the ZX hardware.

An edge is, by definition, instantaneous; in our realm, it _is_ an instant.

I think you are missing my point! The processing of ANY edge by ANY hardware is not instantaneous. If two edges are too close together, by the time hardware manages to latch the both states after the first has changed, the second may already have changed too.

This reaction speed (which we are not calling latency, maybe "propagation delay" can be used), is not infinitely small (probably at least 10's of nS), so the issue of closely spaced encoder transitions is still present even with external hardware. But the speed of the hardware might be able to be considered "instantaneous" compared to ZX speeds.

So, how closely can the ZX hardware track encoder transitions? I hope we will see!

-Tony

[dkinzer]

Can inline assembly be inserted?

Inline assembly language is not supported and probably never will be for ZX models that store the user code in an external EEPROM (as all current models do).

[GTBecker]

... by the time hardware manages to latch both states after the first has changed, the second may already have changed too.

> ... after the first has changed...

After? That's an incorrect expression, I believe; don't you mean "when the first changes", in present tense?

Hardware latches do not continually test and wait for an event and then act - like sequential instruction-based software does. An edge-triggered latch is designed to operate precisely _when_ the edge occurs - at the very same moment - _simultaneously_. In my designs it is the gate-directed quadrature edge that actually does the latching; the quadrature edge _is_ the event signal in an asynchronous logic circuit that latches the state. Latching doesn't occur after the edge is detected; the edge _causes_ the latch. This can be done with synchronous logic, too, more slowly.

Are there propagation delays and capacitances in physical hardware implementations? Sure, and today they limit the performance of silicon logic to about 1GHz (TTL) or 7GHz (ECL) or so. I agree that simple hardware might have difficulty separating two edges that are 10nS apart or less, so don't expect simple quadrature logic to work above about 100MHz.

That's a very long way from where we are, and immaterial to discussions about 16kHz counting, Tony, isn't it?

[GTBecker]

I'm still wondering what is the fastest direct quad decoding anyone's reached...

I guess no one has a specific answer for you, so here's a ballpark guess.

The tightest simple loop that does anything (so it can be measured) is, I think:

Code: Select all

sub Main()
 call putpin(25, 1)
 do
  register.portd = register.portd xor &h80 'toggle red
 loop
end sub

That runs at ~29.2kHz, or ~34µS/loop, on a ZX-24a. I believe the interrupt response time is on the order of 50-75uS, so I think the likely best interrupt rate will be about 15kHz, doing nothing. Quarter that (two interrupts, two edges each) and you're in the range of 3-4kHz, doing nothing. With some decisions and counting you might be near 2kHz or so, 4-edge quadrature rate. A 512-edge encoder will produce that rate at about 4RPS, if my guessing is correct.

[pjc30943]

A 512-edge encoder will produce that rate at about 4RPS, if my guessing is correct.

Very close...before I posted I decoded about 3rps.

[spamiam]

That's a very long way from where we are, and immaterial to discussions about 16kHz counting, Tony, isn't it?

Yes it is. But since you were being very precise about terminology, and separating of latency vs other timing issues, and used the word "instantaneous", I had to object a little.

"Instantaneous" is a mathematical and philosophical term. "Fast" is a real world term, and then it needs to be quantified. Special hardware and ZX implementations have the exact same issues. To paraphrase Bill Clinton, it depends on how fast "Fast" is!

It sounds as if the propagation delay for latching the two channels is just about identical in the hardware decoders, so they do the latching simultaneously. It sounds as if they will resolve signal timing differences very very tightly. How soon AFTER the latch pin activates that the latch occurs is a little less tight.

In the ZX, by reading all 8 bits of a port all at once, you can effectively have simultaneous readings of both signals, effectively latching them. How sooon after a latch interrupt pin activates that the latch occurs, is even less tight.

-Tony

[GTBecker]

...by reading all 8 bits of a port all at once, you can effectively have simultaneous readings of both signals, effectively latching them.

An ideal would be if the processor latched some I/O on an interrupt edge, much like ICP latches a count. That could preserve the quadrature state for examination by interrupt handler code. It'd need to be done in the AVR silicon, though.