ND-MQ - New Network Driver for the QLUB Adapter

[martyn_hill]

I am happy to announce the first release of a native QDOS/SMSQ 'Network Driver for MQ' (ND-MQ) that provides TK2-like network support for QL Emulators running on a PC host connected to the QLUB Adapter (for background, please read https://www.qlforum.co.uk/viewtopic.php?t=3590)

The driver is 75% TK2 networking code (by T Tebby) pulled straight from the SMSQe source repository - with adjustments to the 'physical' driver to use the new 'MQSvr' THinG, which in turn communicates with the QLUB Adapter. My thanks once again to TT and the Sinclair team for an incredibly simple, but effective network design - we stand on the shoulders of giants

Thanks also to all those who provided feedback and encouragement during testing of the earlier QLUB releases...

The ND-MQ driver allows such things as SBYTES 'NETo_x'/LBYTES 'NETi_y' to transfer a binary file between the emulator and a peer QL, or even more conveniently, running TK2's FSERVE Job in the emulated QL to serve files to the peer QL - all over the standard QLNet wiring via the QLUB.

Prior to this release, it had been necessary to use an SBasic program (SendFileMQ_bas or gbejniet's Python equivalent) to communicate with the QLUB Adapter, effectively synthesising the MQ commands needed to implement the transfer. It is still possible to use the QLUB with SendFileMQ if desired, but NOT concurrent with the ND-MQ driver being active, as they both attempt to open the virtual COM Port via SERx and only the first will succeed.

For anyone lucky enough to have already purchased a pre-built QLUB Adapter from Chr$ - or, having built oneself - is keen to try out the new driver, I provide the required files (in ZIP form) and some brief notes below to get you going:

1. A revised microcontroller firmware (v2.3L): 'QLAN-USB_v23l.ino', plus corresponding pre-compiled HEX file 'QLAN-USB_v23l.ino.TEENSY2PP.hex' - use one OR the other to flash the QLUB Adapter to support the new 'synchronous mode' needed by ND-MQ.
2. The ND-MQ driver itself (v1.01): 'ndmq_v101_bin' - simply unzip and load/activate with a simple LRESPR within the emulated QL environment.
3. Some simple SBasic procedures to ease loading/managing the driver: 'loadNDMQ_bas' - note that none of these SBasic routines are actually required to use ND-MQ, after simply LRESPRing the driver binary.
4. (If FSERVE is to be used): TK2 running from ROM (or zero wait-state RAM) on the peer QL - ROM images available elsewhere, if you don't already have TK2 installed on the peer QL (why ever not?)

I also include two documents within the ZIP archive, previously shared here in the Forum that you may find helpful:
Networking the QL (Part 1).pdf
QLUB Adapter - DIY Constructors Manual v1.1.pdf

I'll be updating both docs in the coming weeks to reflect the availability of the new ND-MQ driver.

Notes:
a) Both QPC and QEmulator have been tested successfully with ND-MQ - with QEmulator slightly out-performing QPC for reasons I could share another time. I welcome feedback from anyone testing ND-MQ - especially under u/sQLux.
b) Occasionally, the QLUB can get 'out of sync' with the ND-MQ driver and the only way to restore service is to restart the emulator and re-load the driver. This may be improved in a future release.
c) Broadcast Receive (NETi_0) is NOT currently supported by ND-MQ (though SENDing a Broadcast should work). Broadcast Receive is, arguably, of limited value and will take some careful thought if it is to make it in to a future release.
d) Adapting the network 'Timing Constants' to suit the ZX Net/Spectrum requires a slightly awkward procedure, which I'll also improve in a future release - A small SBasic procedure (UpdateNET_TP, included in 'loadNDMQ_bas') can be used to achieve this today.
f) The current design is not especially 'fast', although it performs within 95%+ as compared to typical QL-to-QL network speeds - were you to analyse the NET port using a digital logic-probe, you'd notice lengthier 'Gaps' between each successive packet than between real QLs. Again, I'll aim to improve this in a subsequent release.
g) The current driver is hard-coded to communicate with the QLUB via 'SER2', though it is a trivial matter to 'patch' the binary AFTER loading but BEFORE activating by POKEing offset $8F/143d with the ASCII code for the numeric port-number to which your QLUB is attached.

e.g. if the QLUB Adapter is attached via a Virtual COM Port on the host PC to 'SER1' in the QL emulator:

ndmq_base=RESPR(6200): port_os=143
LBYTES "<device>_ndmq_v101.bin", ndmq_base
POKE ndmq_base+port_os, CODE("1")
CALL ndmq_base

The PROCedure 'loadNDMQ', included in 'loadNDMQ_bas' uses this very method. N.B. 'port_os' is highly likely to change between versions!

I have several plans for further enhancements, including adapting the microcontroller firmware for a more modern (and still available!) Teensy develpment-board to supercede the now deprecated Teensy++2.0.

Good luck and happy QL Networking!

[Derek_Stewart]

Hi Martyn,

Excellent news, this will make QLUB a great addition to a QL user who has QPC2 and a QL.

Does the driver connect to Spectrum Interface 1 as a network device?

[martyn_hill]

Thank you Derek!

Yes, just like the initial release, the QLUB Adapter with ND-MQ can indeed communicate with the Spectrum/Interface-1, albeit with very slight adjustments to the all-important 'timing-constants' (TCs). This is documented in the earlier guide and a suitable set of TCs is provided in this release also.

Just to clarify something (that may already be obvious), comms between QL and Spectrum can only take place using the more basic NET driver facilities and NOT via FSERVE, which is QDOS specific.

[Derek_Stewart]

Hi Martyn,

I will get my Spectrum and Interface 1, out to connect the QLNET up.

Just gonna used to the Spectrum syntax again...

[afx]

Hi Martin.

Great!!! That is excellent news!!!. QLNET is one of the most fun features of the QL, and your driver is a great gift for QDOS/SMSQ enthusiasts.

I have been trying to install the driver following your detailed instructions from this post but unfortunately I have not been able to get it to work. Surely I am doing something wrong.

I have the Chr$ kit and I have updated the Teensy firmware with the "teensy loader" utility. On my Windows 10 PC , the Teensy is mounted on COM3, and on QPC2 it is mapped to SER2. With LRESPR I load the driver and apparently everything is OK as the message "MQSvr v1.01 initialised OK" appears on the screen. The NET <station> instruction apparently executes without problems. With the FSERVER command, a red light on the Teensy board lights up and blinks.

The problem is: When I try to access another station (for example QL-SGC or Q68, both with FSERVE) the message "Net aborted _ incompleted" appears after a few seconds of waiting. (QLNET seems to have activity because the led on the Q68 blinks indicating activity). The same error appears when I try to access QPC2 with QLUB from another station.

Any idea what might be going on?

[martyn_hill]

Hi afx!

Glad to hear your feedback!

I have a few ideas, but before we get to them, I'd recommend first checking WITHOUT the new driver loaded (or at least without CALLing it), using the SendFileMQv22e_bas program to ensure that you do get reliable comms between the QLUB and the peer QL using the older method. This will validate such things as the timing-constants, peer NET assignment and that your Windows 10 host is allowing proper access to the virtual COM port via SER2.

Did you already have this working before trying the new driver?

I'm confident we'll get to the bottom of it very quickly, but let's start with SendFileMQ...

[afx]

Did you already have this working before trying the new driver?

Hi Martin. Thank you for your support!

Yes, I had tried file transfers with SendFileMQ few months ago and the result was satisfactory.

Now, with the new firmware and the new version of SendFileMQ I can't do the file transfer. I am trying to do a transfer from QPC2 to Q68. When sending a file from QPC2, the message "Tx Blk# 0/ 1" appears and the program stops responding. I see that apparently the program is trying to communicate with Q68 because the network activity light comes on at the time of initiating a file transfer.

Best regards.

[martyn_hill]

Hi afx!

OK, that's useful to know.

There are a number of ways we can approach trouble-shooting this setup, but let's start with some questions. Apologies in advance if some of these seem rather basic - I'm not at all doubting your abilities, but need to ask if I'm to be any help

1. What version of SendFileMQ_bas were you using when this last worked?
2. Likewise, what version of the QLUB firmware was flashed to your adapter when it worked before?
3. What QDOS ROM are you running in the SGC QL?
4. Which version of the ND-Q68 driver are you running on the Q68?
5. Were you already running Windows 10 on your host-PC when this last worked?
6. Have you tried transferring files between the SGC QL and the Q68 in the current setup?
7. What NET station numbers are you assigning your 3 nodes (SGC, Q68 and QLUB/Emulated-QL)? How confident are you that you provided the correct corresponding station number when sending/receiving via SendFileMQ?
8. How is your NET cabling arranged? Have you tried connecting only one station at a time to the QLUB? Are you confident that you haven't inadvertently created a 'loop' with your cabling (remembering that the two 'end' nodes must only have one connection each)?
9. Coming back to the QLUB, try loading the ND-MQ driver again and confirm reliable USB comms by invoking the 'GetMQStatus #<window_channel>' PROCedure that I included in the 'loadNDMQ_bas' program - do you get the diagnostic report displayed in <window_channel>? Does the reported QLUB 'Firmware version' match what you expect (i.e. "2.3l - 2022-11-10")?

That's enough for now - with the answers to these questions, we'll be better able to refine the approach to resolving the issue.

[afx]

Hi Martin.

I have verified all the points that you indicate. The wiring is correct, the ROM version that I use in my QL-SGC is Minerva and in all stations I use SMSQ/E 3.38 as operating system. The network driver version in Q68 is 3.05 (ndq68_drv_305). The QLNET network between my QL-SGC and Q68 works perfectly. On my PC I use Windows 10 with QPC2 II 5.02. The Teensy driver is mounted as COM3 on the PC, which is mapped as SER2 in QPC2.

I have reverted the teensy firmware to the previous version and I have tried the old version of SerdFileMQ, with these versions the SendFileMQ file transfer works correctly.

The versions that work in my setup are:
- SendFileMQv22 v2.2 - 2021-03-08
- Teensy firmware 2.2a - 2021-03-07


Edited:
Regarding point 9, I have verified with GetMQStatus that the firmware version that does not work in my setup is 2.3l -2022-11-10.


Cheers.

[martyn_hill]

Thank you afx

I shall compare all the changes made between firmware 2.2A and 2.3L and get back to you shortly.