The Sinclair QL Forum

martyn_hill wrote:
BTW - given recent experience re-working the QNET driver around Q68's hardware-timer, I can say that any 8302 replacement should have a high precision timer included - it would make any further QNET driver development soooo much easier...

Imminent release of a new SMSQ/E for Q68 with QNET driver implemented ??? The timing would be perfect for one of my project!

François

See, this is what I was saying... The protocol of QLNET is simple, but the timing is critical. Martyn, I will email you and we can discuss this off-forum. I do understand you're a busy person so anticipate you may not give me much time.

Happy to help where I can...

martyn_hill wrote:BTW - given recent experience re-working the QNET driver around Q68's hardware-timer, I can say that any 8302 replacement should have a high precision timer included - it would make any further QNET driver development soooo much easier...

A high-precision timer is also helpful for other tasks, where the 50 Hz timer does not provide sufficient granularity. (And sorry for not yet finding time to update the Q68 manual). I'd recommend it for a future hardware like a 8302 replacement, or a new CPU board, too.

However, while the timing measurements are very accurate, code execution from SDRAM on the Q68 can be delayed during video access by several microseconds. (This is because video data is transferred in bursts to increase performance.) So unfortunately, the QLNET implementation on the Q68 was not as straightforward as it seems. Some code and data needed to be moved to SRAM.

I was talking about that in passing with Nasta. He was saying maybe a 20 KHz high precision timer would be useful.

I think it might be easier from a hardware perspective to have a 32,768 Hz timer, and if that is too fast simply /2 for 16384 Hz.

Currently, I'm at the point where it makes no sense to replace just the 8049, and it is actually easier to replace the 8302 AND 8049, if only because the connection between them is so janky. The remaining problem is the awful yet relatively simple way the OS accesses the 8302 to process IO. I just need to emulate that on the OS-visible side and do what I like behind the scenes. Which might mean half way decent internal serial ports - except the motherboard design pretty much forces that the two receives serial channels are combined before going to the 8049, which.... *shakes head* ... so I am just figuring if there's a way to get around that without having a bunch of jumper wires all over the place. The hardware that was included (1488/1489) is good for at least 115Kbaud.

Dave wrote:I think it might be easier from a hardware perspective to have a 32,768 Hz timer, and if that is too fast simply /2 for 16384 Hz.

That frequency would be of restricted use, e.g. it is too slow to generate network timings. If there are enough registers available, I'd recommend the CPU clock (Pin 25 of the ZX8302) as counter source.

In which case, there would be many speeds to choose from. 20MHz. 24MHz. 40MHz. 66MHz.

It would be sensible to maintain compatibility so there can be fewer versions of SMSQ. I recall the high precision timer in the Q68 is 40MHz. I don't know if that just happened to be the clock of the Q68, or if there was a specific reason you chose that, but 25ns is a nice time interval because it is so easily countable to get "real" times.

I am a bit surprised it's not 10MHz, gives a longer total period, and I think 100ns should be precise enough

Dave wrote:I recall the high precision timer in the Q68 is 40MHz. I don't know if that just happened to be the clock of the Q68, or if there was a specific reason you chose that, but 25ns is a nice time interval because it is so easily countable to get "real" times.

I was also considering a clock tick of 100 ns which is independent from the CPU for easier portability to other (future) machines. But counting in CPU clocks is a nice way to measure instruction timings, and 25 ns easily fits 100 ns. So I decided to keep it that simple.

In practice, recalculation for a different timer is a primitive factor - unlike instruction/memory/cache dependent timings. So I wouldn't give exact compatibility too much attention. We don't expect a lot of future QL hardware with highres timers. As long as the granularity is sufficient, I think you are fine.