The Sinclair QL Forum

Peter wrote:Doesn't that mean you need completely new software drivers for keyboard, sound and SER?

No. It will emulate the 8302 register behavior, but with a new back-end. USB keyboards and mice. I'm getting strong comments to include a proper sound chip also. Serial will be handed off to a DUART. So really, just PS/2 or USB to QL IO emulation, including keyrow emulation.

Dave wrote:It will emulate the 8302 register behavior, but with a new back-end. USB keyboards and mice. I'm getting strong comments to include a proper sound chip also. Serial will be handed off to a DUART. So really, just PS/2 or USB to QL IO emulation, including keyrow emulation.

This is excellent! Also the issue of sound chip is very important in my opinion.

Dave wrote:

Peter wrote:Doesn't that mean you need completely new software drivers for keyboard, sound and SER?

No. It will emulate the 8302 register behavior, but with a new back-end. USB keyboards and mice. I'm getting strong comments to include a proper sound chip also. Serial will be handed off to a DUART. So really, just PS/2 or USB to QL IO emulation, including keyrow emulation.

You said you want to attach to the QL bus by dual-port RAM, so I have no idea how how the ZX8302 could be correctly emulated. Some registers need direct coupling to the hardware, including interrupts, and not after a significant delay for a microcontroller to read/write the dual-port RAM. This looks much more suited for a PLD/FPGA than software.

If you have actually made sure the ZX8302 emulation in software will work fast enough, I don't want to spread scepticism here. But if you only had a brief look like myself, I would say it is unrealistic with the ESP32. The builtin CPU also has to handle other tasks, it would not be fully dedicated to ZX8302 hardware-emulation.

Peter wrote:

Dave wrote:

Peter wrote:Doesn't that mean you need completely new software drivers for keyboard, sound and SER?

No. It will emulate the 8302 register behavior, but with a new back-end. USB keyboards and mice. I'm getting strong comments to include a proper sound chip also. Serial will be handed off to a DUART. So really, just PS/2 or USB to QL IO emulation, including keyrow emulation.

You said you want to attach to the QL bus by dual-port RAM, so I have no idea how how the ZX8302 could be correctly emulated. Some registers need direct coupling to the hardware, including interrupts, and not after a significant delay for a microcontroller to read/write the dual-port RAM. This looks much more suited for a PLD/FPGA than software.

If you have actually made sure the ZX8302 emulation in software will work fast enough, I don't want to spread scepticism here. But if you only had a brief look like myself, I would say it is unrealistic with the ESP32. The builtin CPU also has to handle other tasks, it would not be fully dedicated to ZX8302 hardware-emulation.

I don't think he plans to emulate a full ZX8302, only provide keyboard / sound from what I've read above. Serial function is to be provided by a new serial device (so that offloads responsibility of that to a new driver and DUART chip).

Not sure about MDV and Network support ?

A lot of those dual port RAM's offer an interrupt mechanism, some using a specific 'post box' address within the RAM, and some allow an interrupt on change of any address, so it could be possible to 'mimic' the ZX8302 interrupt logic.

Peter wrote:You said you want to attach to the QL bus by dual-port RAM, so I have no idea how how the ZX8302 could be correctly emulated. Some registers need direct coupling to the hardware, including interrupts, and not after a significant delay for a microcontroller to read/write the dual-port RAM. This looks much more suited for a PLD/FPGA than software.

If you have actually made sure the ZX8302 emulation in software will work fast enough, I don't want to spread scepticism here. But if you only had a brief look like myself, I would say it is unrealistic with the ESP32. The builtin CPU also has to handle other tasks, it would not be fully dedicated to ZX8302 hardware-emulation.

Let's take an imaginary system that has a 50Hz interrupt. During this time it runs a sequence of tests for keyboard input, serial activity, etc. If we eliminate microdrives (deprecated, replaced by SD) serial (deprecated, replaced by DUART), QLNET (deprecated, replaced by serial/TCPIP pairing with Hayes presentation to OS) and sound (deprecated, replaced by sound IC) we are left with keyboard.

The fun thing with the keyboard is it's just "what keys are pressed?" .... "THESE keys are pressed!"

If we have dual port RAM between the keyboard interpreter and the CPU, it adds a layer of abstraction. The thing we need to consider is that the contents of a memory location only matter when it is read. So, a dual core 160MHz microcontroller, with one core dedicated to scanning the keyboard matrix and/or converting USB/PS2 inputs to keyboard matrix values and with the other core dedicated to copying keyboard values to the dual port RAM with correct timing, we can be assured that any keyboard scan request will be provided with the result of the previous scan/conversion.

The problem here is what happens if the data is half written into one port of DPRAM while the other port is reading, and we get an indeterminate result?

We avoid this by using the /BUSY flag on the DPRAM. Also, consider we can decode the DP RAM so a 2K device could have 1K mapped for reads and 1K mapped for writes and this would provide "I from O isolation" I don't thing people will even notice the rare occasions their keyboard input is delayed by 1/50th of a second.

Typical interrupt latency on the ESP32-D0WD is <25ns. It would probably manage 1:1 cycle timing up to 68010@30MHz, 2 cycle timing for 030 at 40MHz+, and 3 cycle timing for '030 at 40MHZ+.... Our use case is a 68SEC000 at realistically a top speed of 15MHz, possibly 18.75MHz. That limitation is by the 8302. Havig an option that lifts that to 20, 22.5 or *deep breath* 30MHz is always appealing.

I recognize your concern. That's why the DPRAM was introduced - to make responses relatively independent of CPU timing and OS requirement. The requests are null, or repeated often. The average keypress of a competent typist lasts 6 scans. Only the changes matter. At the end of the day, n-key rollover and debounce are more critical to the user experience than one (or rarely, two) cycles of no status change.

For clarity, this isn't an Issue 8 feature. I don't want to mess with the ULAs of the QL for Issue 8. It needs to be 100% compatible, and either work or not work. We've put some effort into the machine supporting multiple OS images. While we idealistically see these as different OS versions, it could just as easily be just multiple Minerva or JS4M versions, with changes for timing for QLNET and microdrives to wrok correctly at various clock speeds. That said, we understand this is a manual process, and will be looking users to work out reliable timings and to share their experiences with the community.

Pr0f wrote:I don't think he plans to emulate a full ZX8302, only provide keyboard / sound from what I've read above. Serial function is to be provided by a new serial device (so that offloads responsibility of that to a new driver and DUART chip).

Not sure about MDV and Network support ?

A lot of those dual port RAM's offer an interrupt mechanism, some using a specific 'post box' address within the RAM, and some allow an interrupt on change of any address, so it could be possible to 'mimic' the ZX8302 interrupt logic.

I know it is hard, but we can admit that microdrives have passed their prime. They had a moment (even if it was just a moment!)...

I don't deprecate features because it is just convenient or easy. It is vital to the users that functional replacements exist. I do forsee someone writing library code to make the ESP32 wifi on serial mechanism work as a transparent gateway for QLNET, some day. Microdrives have many logical replacemets. Floppies are long in the tooth, but CF has some mileage and SD will be with us for 10+ years.

Every decision is hard when your timescale reference is "the next 35 years!" How much of today's tech would have been unbelievable to us in 1984? How much of what we thing is unbelievable today will be commonplace, even outgoing or retro, in 2054?

That said, the original question and concern by Peter is valid. I am sure Nasta will chime in eventually, though it may be a while - this is a busy week for him.

Pr0f wrote:I don't think he plans to emulate a full ZX8302, only provide keyboard / sound from what I've read above. Serial function is to be provided by a new serial device (so that offloads responsibility of that to a new driver and DUART chip).

When I asked if keyboard, sound and SER need new drivers, the answer was no, so I thought original QL SER was also to be emulated.

Pr0f wrote:A lot of those dual port RAM's offer an interrupt mechanism, some using a specific 'post box' address within the RAM, and some allow an interrupt on change of any address, so it could be possible to 'mimic' the ZX8302 interrupt logic.

I read in forums that measured practical delays from external trigger to ISR handler were around 2us (at 240MHz clock) for the ESP32. But then the handler needs to do some work and needs to return before the next ISR is handled. I'm not in the details, but to emulate the ZX8302 hardware correctly under all realtime circumstances, that looks very difficult programming at least.

Dave wrote:If we have dual port RAM between the keyboard interpreter and the CPU, it adds a layer of abstraction.

I was not technically versus dual-port RAM, just questioning whether that would work without new drivers.

Peter wrote:When I asked if keyboard, sound and SER need new drivers, the answer was no, so I thought original QL SER was also to be emulated.

I am hoping that the new hardware will not require any changes for an existing OS. Remember, this isn;t applicable to Issue 8, just Issue X+.....

Peter wrote:I read in forums that measured practical delays from external trigger to ISR handler were around 2us (at 240MHz clock) for the ESP32. But then the handler needs to do some work and needs to return before the next ISR is handled. I'm not in the details, but to emulate the ZX8302 hardware correctly under all realtime circumstances, that looks very difficult programming at least.

A couple of things here: 240MHz is a legal speed for ESP32-D0WD, but I plan to run it at the default 160MHz, This is mostly for convenience, as most of the timing models for open source software assume 160MHz.

Dave wrote:If we have dual port RAM between the keyboard interpreter and the CPU, it adds a layer of abstraction.

Peter wrote:I was not technically versus dual-port RAM, just questioning whether that would work without new drivers.

The OS keyboard routines just make the same request over and over, The response happens over and over. If the response is delayed one CPU cycle and the change even is reported to a later keyboard scan cycle, it doesn't impact the OS. It just introduces 1/50th second latency to the request. Frankly, using modern keyboards the reduction in delay to detect a keypress will about cancel out the delat introduced by this proposed system.

Which is not in Issue 8. It's intended for Issue X.

Issue 8 - QL with all ULAs for 100% compatibility with all previous OS. Issue X = changes to a new IO and video system to push the system forward.

robheaton wrote:I've just ordered a WiFi modem from Simulant, looking forward to using it!

I use my personal TCP/SER configuration since 2015

Well on the QL I think you will need a BT to SER adapter for use this interface or an adapter Serial Cable.

I remember I made one or more using the schemes on Dilwyn Site

Serial ports on the QL are not standard at all.

A real TCP/IP card for the QL will be more interesting for me: It can be a new way for write new software that can connect directly on internet (IRC, client email, browsers, etc...).

Outsoft wrote:A real TCP/IP card for the QL will be more interesting for me: It can be a new way for write new software that can connect directly on internet (IRC, client email, browsers, etc...).

A real TCP/IP card is only useful if we have access to an encryption engine. It would take a QL several days to encrypt or decrypt a single packet.

The stack needs to be run on a fast external device that can handle encryption in real time. There are a few choices. I chose the ESP32 path, if only because it reduces the burden on the QL to something it can handle really well - a device independent serial stream.