The Sinclair QL Forum

Thanks for your post Whopper.

Steady progress is being made on the SMSQ/E NET driver re-write to communicate with the microcontroller in-place of the 'bit-banging' routine of the original physical TK2 NET driver.

Just to clarify my own intentions with this project - to share the microcontroller code (mostly completed and already working), the NET driver code for running on an emulator (will be tested on QPC primarily), parts list and instructions for programming the uC and how to wire it all up in hardware (the trivial bit!)

One of our hardware gurus on the forum may well be able to make this available as a ready-built commercial offering in the future, whilst I continue to develop and share publicly the software/design itself for the DIY'ers among us.

More to follow...

A little update for those following this project...

On-going progress is being made with the interfacing between the microcontroller and SMSQ/E (to add-back the native NET and FSERVE/Nx_ device drivers) - should have more to report in the next few weeks.

Meanwhile, mostly out of curiosity, I picked-up a second-hand Spectrum and Interface-1 recently to compare the network timings - it has always been reported that QL to Spectrum networking only works 1-way.

I can confirm that QL to Spectrum works mostly OK, but packets from the Spectrum are unreliable. Timing traces show that the Speccy has slightly longer and sometimes variable bit-times (nominally, 11.4us rather than the QL's pretty consistent 11.2 us), along with significantly shorter 'lead' bits (3x rather than the QL's 4.5 - 5x bit times). This combination appears to hammer native QL reception.

I've since been able to adjust the microcontroller code to reliably speak to both QL and Spectrum nodes and added new debugging to facilitate further diagnosis.

Its still my intention to publish here all my findings and source code/hardware design in due course - just trying to avoid more distraction from writing the SMSQ/E driver interface...

Well, no wonder:

Both the Spectrum with I/F1 and the QL bit-bang the protocol at 87500 bps - Not an easy task for a poor Z80. It's probably at its limits.

Nice to hear you're making progress.

Tobias

Hi Martyn,

from the very beginning of my QL (and Speccy -IF1) days I loved the QLNet. Of course I now of the disadvantages but I really liked the idea to simple connect the QLs and do the data transfers. Many years I was wondering why nobody build a PC - QL interface based on the QLNET. By luck I found your project here and I am highly interested in the current status.
Are still working on it?
Would be great if you could share some details!

Thanks a lot in advance!

Best regards, Stephan

Hello Stephan

Thanks for asking...

The project has been on hold for a while, after a few false starts at developing the code needed to 'bridge' the QL NET code to the micro-controller (which is itself working fairly well.)

As it happens, I have been involved recently with another related project that is just now coming to fruition - some of the learning from that project will lend itself to pick-up the QLUB adapter thread in due course.

In summary, the QLUB adapter is a micro-controller coded with the QLAN/ZXNet protocol that communicates via it's onboard USB interface with a QL Emulator (QPC, possibly QEmulator) running on the host PC. Real QL and compatible hardware with a NET port (e.g. the QXL & the Q68 eventually) as well as Spectrum w. Int1 will then be able to communicate using their respective NET drivers over the usual two-wire cables with the emulated QL on the PC.

I expect to pick-up this project again in the New Year.

Hello Martyn,

thanks for your kind replay. Sound really good that you are going to resume the work on the project next year. I am really interested in building one of these interfaces once you have completed and released your work.

Until that I need to be patient.... unfortunately!

Best regards,

Stephan

Hi Martyn !
With your latest posts on this thread, I just became aware that you were aiming at a similar goal as I was : I use my QLs with a LCD screen (SCART input) on which I also piggybacked a Raspberry Pi (HDMI input) and I was recently wondering if I could not take advantage of this proximity to link the "net" of a QL to some GPIO pins of the Raspberry ?
Just writing eventually a driver for this special link and some linux program to mimic a QL onboard the Raspberry (only to exchange files, not a full QL emulator).
My first problem is that I lack informations on the needed (simple ?) hardware to design for the Rpi side, and I did not quite succeed reading and interpreting your sketch (a few posts above). So if I kwew what input/output voltage and loads are expected by the QL (are they documented somewhere ?), I could try to reengineer like you a link for the Rpi through its GPIO.
Besides, I found only one rather short paper about the dialog and data sending/receiving protocols ?
What other informations could you share ? Thanks a lot beforehand.
POLKa
(for the moment, I did not play with the GPIO capabilities of the Rpi, so I don't even know if what I plan would really be possible).

A Linux user mode program on the RPi will probably not suffice the real-time requirements of the QL Network - That means you will need to build a kernel driver or use the RPi bare metal if you want to connect it to the QL Network.

What I am currently planning is to connect an RPI via SPI as a slave to the QL-SD SPI interface, or/and to the Q68 I2C interface. There's drivers already available for both ends.

Tobias

Hi Polka

I'm not so familiar with the capabilities of the RPi, but worth bearing in mind that re-implementing the QL Network stack, QDOS IOSS plus the FSERVE server routines sufficiently to share files would be far from trivial.

That's one of the reasons why I opted to design the QLUB adapter and the corresponding 'bridge' between QDOS/SMSQ and the microcontroller (a Tenesy++2) on a QL emulator (QPC in my case, but might be adaptable to QEmulator or uQLX as long as they can access the Virtual COM/USB port presented by the uC.)

The hardware aspect is pretty trivial - 0/5V signal levels (active high) in to a 165-ohm load, either driving current in to the line, or effectively disconnected (tied to ground through the 165-ohm load-resistor.)

It's the opposite to other more modern one or two-wire interfaces where the line floats high and is actively brought low. The outcome of the simple QLNET design is that line-contention can only be detected when you're not driving the line (i.e. INActive/low.) The QLNET protocol only checks contention whilst transmitting the SCOUT - a 10 to 15-bit representation of the SRC/DST station numbers (depending upon version of QDOS) lasting about 600us immediately prior to each packet Header.

It has always been my intention to fully document the protocol - going beyond the description given in the TK2 manual - which will happen once I've finished the QLUB project and published a fully working version.

The protocol and hardware is surprisingly robust in practice, even with the primitive byte-additive check-summing employed (word-additive for FSERVE type packets.) The key disruptors to reliable comms that I've observed are variable timing 'jitter' depending upon RAM memory where the code is running and what seems to be very occasional 'latch-up' on the NET ports.

M.

After some good experiences with the Q68 as a bridge between QLNET and SERNET:
Could it simplify things, if the adaptor acted as a bridge to SERNET, using the existing SERNET driver on emulator side?