The Sinclair QL Forum

Hi!
Very interesting issue...
Could be an option to set a buffer between both modules?
That way it won't depend too much from CPU cycles or Serial clock.

I don't know the architecture so probable that idea is not accurate.

Hey PrOf!

Pr0f wrote: Fri Sep 01, 2023 10:49 am I think the ZX8302 itself can run faster - as people have tried it - the issue is it provides critical timing based on the CPU clock for the baud rate for serial transmission (and if not using Hermes IPC) for the IPC on the BAUDX4 output. Also NET and Microdrive timing affected. I suspect it would happily sit on a CPU bus running a faster CPU clock though, and still have the Clock input at 7.5MHz.

My experience running the ZX8302 on the Q68's external bus (which, I believe runs around 20Mhz as Peter slows it down to suit the onboard Ethernet controller and runs it 'synchronously') suggests that the 8302 ULA is a bit picky about the bus speed versus its own clock. Either due to slew rates or perhaps some synchronous bus timing inside the ULA, triggered of it's clock.)

I am able to run the ULA at 10Mhz and higher on the Q68's external bus and still maintain compatible bus timing, but at 7.5 or 8MHz clock to the ULA, it seems to fail to latch writes in time and some reads are broken on the Q68's bus.

At 10Mhz, the ULA can read MDV cartridges written by a stock QL, but by 16Mhz, the MDV signals go out of range (unless you then slow down the MDV motor quite a bit, to compensate.)

Aside from the MDV timing incompatibility at higher ULA clock speeds, it seems to respond as expected on the bus up to 16Mhz at least. I believe I also tried running it at 20MHz, but can't recall how it handled the bus...

As the NET timings are all software controlled, we can easily workaround a faster CPU and still maintain fully compatible QLNet timings (actually, slightly 'better' given less latency at a higher CPU clock speed - the 7.5Mhz QL itself isn't actually fully timing compliant with the Sinclair standard!)

The other approach is to control the clock going to the CPU - you can use a flip/flop or two within the FPGA to gate the clock signal to the CPU such that you get a 'glitchless' clock change - then you can select between a fast and slow clock. Any access to the ZX8302 can slow the CPU clock down if needed, or if you have some compatability issue with certain software you can have a couple of new commands or just an I/O address to poke if you are not wanting to go the route of a new command - to switch between fast and slow CPU clocks.

https://www.programmersought.com/article/68545257095/

Hi,

With the 8302 chips in short supply, could an alternative to the 8302 not be developed?

Maybe thread of its own.

I adjusted the video for 10Mhz and I run at 10Mhz without a problem (other than that zx8302 runs also at 10Mhz).

Here is a benchmark

Hi,

Here is a detailed description of the 8302:

https://www.theqlforum.com/viewtopic.php?t=2553

https://www.theqlforum.com/viewtopic.php?t=2019

Pr0f wrote: Fri Sep 01, 2023 2:21 pm The other approach is to control the clock going to the CPU - you can use a flip/flop or two within the FPGA to gate the clock signal to the CPU such that you get a 'glitchless' clock change - then you can select between a fast and slow clock. Any access to the ZX8302 can slow the CPU clock down if needed, or if you have some compatability issue with certain software you can have a couple of new commands or just an I/O address to poke if you are not wanting to go the route of a new command - to switch between fast and slow CPU clocks.

https://www.programmersought.com/article/68545257095/

I think that one way to avoid "glitces" and use lower frequency to the zx8302 is to have a higher frequency as an integer multiple of the lower.
The integer ratio will allow constant phase between the 2clocks.
So if I use the MC68SEC000 at 15Mhz I maybe could use the 7.5Mhz frequency for zx8302 but then maybe with so big speed difference zx8302 will respond too late.

I think I solved it.
I just delay 1 cycle bringing the DTACK low when PCENL is low and it now seems to work ok with 10Mhz cpu/ZX8301 clock and 7.5 Mhz ZX8302 clock.
Just made the access cycle longer when talking to zx8302.

There are some problems with 7.5/10Mhz but I can't try any fix now because I had an accident and I burned either the programmer or the programming pins of the fpga and have to wait for new parts. I'm stack with the fpga running at those clocks.

That's not good news Leon - you were making some excellent progress. Still, hopefully it's easily fixable. This is an excellent project.