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.