ND-MQ - New Network Driver for the QLUB Adapter

[martyn_hill]

Hi afx!

A) When I use SMSQ/E on my QL-SGC as a client and QPC2-QLUB as a server, there are several problems (I can't copy files, I can't run programs from server). However, when I use Minerva on my QL-SGC as a client EVERYTHING works fine!

That is bizarre. I have yet to try running SMSQe on my SGC-equipped QL (its running Minerva 1.98) - I'll have a go at that combination soon.

B) When I use SMSQ/E as a client (from Q68 or from QPC2) and I load an SBasic program from the server, the response time increases a lot (possibly those 20 seconds that you comment). BUT when I do the same operation from the QL with Minerva as client that problem doesn't happen.

I hadn't seen that behaviour (yet) from either of Q68 (SMSQe v3.32) nor QPC (SMSQe v3.37). The only problems I continue to see (until I track down the fault) are with files of certain filelengths - but not generically across all files...

Given Stephan's observation regarding his GC QL (but not SGC), I'm now wondering if some refinement of Timing Constants may be needed for your setup that might improve the 'speed' with SMSQe as client (actually, the number of retries needed), but as far as I can tell, the default TCs should prove reliable for SGC and Q68... I'll look again once I've tracked-down this elusive 'filelength' bug!

Thanks for providing the full configuration details! I'll add these to my compiled list, ready for a doc update in the coming weeks.

QDOS version: Minerva / TK2: I don't know the version (How could I find out?) / SGC ROM: 2.49.

With the TK2 in the replacement SGC ROM, the SGC ROM version is the indicator of TK2 version (v2.49 - the latest and same as mine and most others.)

MK's PCB design, assembled by Chr$. I don't know the Teensy version (How could I find out?)

If this was Chr$'s build of the adapter, he might know the variant of the Atmel chip used in the Teensy dev-board he supplied you - its printed quite small on the IC itself and is either the '1286 or '1287. I'm not expecting any issues with either, but I personally test with the original 1286 variant.

Good luck!

[Chr$]

If this was Chr$'s build of the adapter, he might know the variant of the Atmel chip used in the Teensy dev-board he supplied you - its printed quite small on the IC itself and is either the '1286 or '1287. I'm not expecting any issues with either, but I personally test with the original 1286 variant.

Good luck!

The 2 I have left both have 1286 Atmel chips, so it's very likely they were all that type (I only had about 8 or 9).

[Maskenlos]

When I use SMSQ/E on my QL-SGC as a client and QPC2-QLUB as a server, there are several problems (I can't copy files, I can't run programs from server). However, when I use Minerva on my QL-SGC as a client EVERYTHING works fine!

I just tried SMSQ/E 3.37 on my GC QL at client side and it appears that I have to use the Minerva Tool "Nettime_bas" to adjust the timing constants to get a stable connection. My values are:

Write loop timing constant: 32
Delay TO read loop: 60
Read loop timing constant: 33

You may try this. Only change in small steps! After each change I loaded a screen file. It is easy to see the improvements.

Stephan

Find the tool here: viewtopic.php?t=3590&start=90

[Derek_Stewart]

If this was Chr$'s build of the adapter, he might know the variant of the Atmel chip used in the Teensy dev-board he supplied you - its printed quite small on the IC itself and is either the '1286 or '1287. I'm not expecting any issues with either, but I personally test with the original 1286 variant.

Good luck!

The 2 I have left both have 1286 Atmel chips, so it's very likely they were all that type (I only had about 8 or 9).

Hi,

I have 5 Tneensy ++2, which they all feature the AT90USB1286

The discontinued PJRC Teensy ++2 does not have a AT90USB1287 fitted, this looks to be a different board, called a AT90USBKEY supplied by Microchip.

The AT90USB1287 has a USB OTG interface, and the AT90USB1286 has a USB Host Interface, so I would say that the only difference is the way the AT90USB1287 programmed. Only an uneducated guess.

However, I can get the Tneensy ++2 with AT90USB1286 easily.

[martyn_hill]

Hi Derek!

I have 5 Tneensy ++2, which they all feature the AT90USB1286. The discontinued PJRC Teensy ++2 does not have a AT90USB1287 fitted, this looks to be a different board, called a AT90USBKEY supplied by Microchip. However, I can get the Tneensy ++2 with AT90USB1286 easily.

That's good to know! Looks like we'll have a reasonable supply for new QLUB users - giving me time to develop around a newer microcontroller for a future version of the QLUB

[martyn_hill]

Well, after countless hours trawling through the ND-MQ code and the QLUB firmware, compiling several debug versions of each as well as sniffing USB packets with Wireshark, I'm happy to report that the cause of the 'bizarre file-length issue' (tm) reported earlier has been found!

Just to recap, attempts to read files on the emulated QL/QLUB from a remote FSERVE'ing QL of certain file sizes would fail and also cause the QLUB to stop responding, requiring it to be reconnected and the emulated QL restarted before service was restored.

Turns out the issue is a long-standing flaw in the QLUB firmware (i.e. from the very first release!) that has only surfaced now and for which I've found a simple workaround, ready for the next release.

I say 'flaw', the actual issue appears to lie in how USB buffers are managed inside the Atmel microcontroller, resulting in packets that _exactly_ fill the (multiple) 64-byte internal buffers being stacked-up until the the USB stack is effectively re-initialised. The Serial.send_now() function I use to flush the USB buffers after each NET packet is recieved seems to get confused if the buffers are completely full and doesn't do what it's documented to... Simply detecting the situation in the QLUB firmware before calling Serial.send_now() and padding a single extra byte to the event-stream is enough to workaround the issue. I've raised this on the Teensy Forum, but for now we have a solution.

Fortunately, I seem to be the only one who has (knowingly) hit the problem, which is just as well, and I can return to the planned enhancements to the driver - and to continue to assist any users still struggling to get the QLUB working reliably in their various configurations.

More to follow.

[martyn_hill]

Hi again afx!

A) When I use SMSQ/E on my QL-SGC as a client and QPC2-QLUB as a server, there are several problems (I can't copy files, I can't run programs from server). However, when I use Minerva on my QL-SGC as a client EVERYTHING works fine!

So, I've experimented now with SMSQe on my SGC equipped QL (which usual just runs Minerva 1.98).

I too notice poor reliability when SMSQe is running versus Minerva. Given that they'll likely be running slightly different versions of the TK2 Network code, this is possibly understandable.

Anyhow, I was able to get rock-solid performance from SMSQe on the SGC-equipped QL after making a tiny tweak to one of the Timing Constants at the QL end. You can use the method Stephan mentioned (the simple SBasic Utility 'nettime_bas' from the SGC Source distribution - I've attached it here for convenience).

The default values for these three most critical Timing Constants (on an SGC) are:

Code: Select all

ndt_send: 31
ndt_rdly: 27
ndt_rbit: 14

By changing ndt_rbit from its default of 14 to 15, I was able to LBYTES 32k SCR images using FSERVE in both directions between QLUB and SGC/QL (SMSQe) without issue.

Of course, changing TCs like this could be done at either end of the link (QL or QLUB) - increasing ndt_rbit or decreasing ndt_send respectively - but you can start to drive yourself insane remembering which one has been changed, only to find that it works for one pair of connections, but not for another (if, that is, like me you link several QLs/Spectrums/QXL etc), so aim to change TCs on only the 'outlier' node where possible to align with the other(s) - and document what you changed - and don't forget to let us know here so I can update my 'QLUB compatibility' report!

BTW, if you (or anyone else reading) also has access to (a licensed) QemuLator, the overall performance/reliability working with QLUB is noticeably better. It's NOT an indictment of QPC - just down to some differences in how the SER Ports are managed within the two emulators and which happens to have a positive impact on the latency of communication with the QLUB from QemuLator. Along with s/uQLx, they are all brilliant emulators...

[afx]

Hi Maskenlos, Matin.

Perfect! Changing the time constants, with the nettime_bas utility, now the systems are much more robust and reliable in the QL-SGC station with SMSQ/e. I have applied the change suggested by Martin, ndt_rbit from 14 to 15.

Thank you very much!

[FrancoisLanciault]

BTW, if you (or anyone else reading) also has access to (a licensed) QemuLator, the overall performance/reliability working with QLUB is noticeably better. It's NOT an indictment of QPC - just down to some differences in how the SER Ports are managed within the two emulators and which happens to have a positive impact on the latency of communication with the QLUB from QemuLator. Along with s/uQLx, they are all brilliant emulators...

Would the QLUB works with the MAC version of Qemulator ?

Still possible to buy the hardware ?

François

[martyn_hill]

Bonjour Francois!

Would the QLUB works with the MAC version of Qemulator ?

I don't know if the Mac version of QemuLator gives the same access to the SERial ports from inside the emulator, nor whether whether there is a Virtual COM Port driver for Mac to connect with the USB port of the QLUB Adapter. But, I strongly suspect it will work just as well on that platform...

I'd love to hear about your success or otherwise and would be happy to do what I can to help make such a configuration work...

Still possible to buy the hardware ?

I understand that Derek plans to construct some more based on Marcel's PCB design, but he is a very busy fellow!

If you have a small solderless breadboard to hand, can purchase the Teensy ++2.0 dev board and a purchase a few, inexpensive components, its pretty straightforard to construct one yourself. My own QLUB Adapter still sits on the same solderless breadboard I constructed 3 years ago!