ND-MQ - New Network Driver for the QLUB Adapter

[martyn_hill]

I biought 4 Teensy ++2.0 from Aliexpress, took a few weeks to arrive. I can get more... I was looking at making a integetrated PCB with AT90USB1286-MU on the QLUB PCB, only done the schematic. So still work in progress.

Nice!

[martyn_hill]

OK, friends

So, feeling somewhat daft, I have now identified the cause of the issue that afx and Stephan have reported when testing the new QLUB firmware/ND-MQ driver

Attached is an updated ZIP archive, containing a revised version of the firmware - v2.3M. Everything else, as before (including the new driver.)

Please download this version and re-flash your QLUB adapter. You should be good to go without any further hacking of timing-constants and what-not...

For anyone remotely interested, during my various 'refinements' since the last release, I had experimented with using a feature of the microcontroller to assist in the detection of the START bit (as I pushed the QLUB to about 5x the standard NET bit-rate.) This involved adding an additional link between PORTD-0 (NET-In) and PORTC-7, which I had duly added to my breadboarded QLUB - and had completely forgotten about since!

In v2.3M, I have simply reverted to the former method (cf 'recvByte' vs 'recvByteICP'), which works perfectly well - at least for the usual NET bit-rates, and thus no longer requiring that extra link-wire which would be a chore for the average user to have to make.

Thanks afx and Stephan for your patience!

[Maskenlos]

Hi Martyn,

thanks for the updated Firmware. I can confirm its working now, here on my "old" QL which we discussed yesterday.
Only a quick check, but loading files in both directions with fserve is possible.

Enjoy the weekend!

Stephan

[martyn_hill]

That's good news, Stephan! Thanks for sharing

[afx]

Hi Martin.

I have tried the new firmware version and now everything works fine.

The use is very easy, load the driver with LRESPR and everything works fine as "plug and play". I have tested QLnet from QPC2 in client mode without any incident, I can copy files and run executable programs located on Q68 or QL-SGC as servers. It's great!

(I've had some issue loading SBasic programs from the server and also some problems when QPC2 acts as a server, but I need to test it with more patience next week. By the way, I couldn't find the version 3.06 of the network driver for Q68 on Dilwyn's site. Is there another place where I can download it?)

Matin, as we have said, great job! and thank you very much for the support.

Best regards.

[martyn_hill]

Hi afx!

I have tried the new firmware version and now everything works fine.

Marvelous! Thanks for the feedback.

(I've had some issue loading SBasic programs from the server and also some problems when QPC2 acts as a server, but I need to test it with more patience next week.

That is curious - my own testing was successful running FSERVE at either end and, whilst I focussed on binary file copying thus far, LOADing also worked OK.

That said, QDOS LOADing and SAVEing is a more complicated process than, say LBYTES/SBYTES as the IO TRAP is called multiple times with keys for IOB.FLINE as well as (curiously) IOB.POS, resulting in many more Client/Server packets being transmitted for a given size of file. This could be the cause of the problem you have observed if, say, packet transmission is slightly flaky - it would hit LOAD/SAVE harder than L/SBYTES...

I'll experiment some more myself.

By the way, I couldn't find the version 3.06 of the network driver for Q68 on Dilwyn's site. Is there another place where I can download it?)

My bad - sorry - I had released a number of versions of the ND-Q68 driver 'privately' over the years since first releasing v3.05 and thought I saw v3.06 on Dilwyn's site. But you are quite right, that one is v3.05. Its barely any different from v3.06, so you're not missing anything there. (I am actually up to v3.18 today and will be publishing a revised version of ND-Q68 in a few weeks. The changes are mostly to accommodate faster bit-rates - up to 8x the QL std is working so far...)

As a favour (but no hurry), could I ask you to help me compile your results according to the list I shared previously, namely:

• PC-host OS/QL Emulator, relevant configuration etc

• The QDOS/TK2/(S)GC ROM versions and hardware - QL board Issue, GC/SGC or other expansion fitted- on the Peer QL

• - If a Q68, the version of the ND-Q68 driver in use

• Details about the QLUB Adapter - e.g. Firmware version, whether self-built, microcontroller variant, using MK's PCB design etc

• What, if any, Timing-Constants needed to be adjusted to make each connection work

This is to help me ultimately update the documentation, listing all the 'known working' configurations that have been tried to-date to help new users identify what should work for them...

[martyn_hill]

Good morning everyone!

Following afx's report of some peculiarities with LOADing files and FSERVE running on the host PC emulator with the QLUB, I spent the weekend conducting some more thorough testing and have identified a really bizarre issue that only shows itself when transferring files of very particular sizes.

I have yet to find the cause, but so as to avoid frustration by anyone already using the new driver until I can fix it, I'm sharing the symptoms here. Its very odd, so bear with me...

Transferring any file via the FSERVE method that has a file size of ((89-92) + N x 64) bytes results in failure to complete (reporting "Network aborted" then "transmission error" after a timeout of around 20seconds.)

It doesn't matter which of LOAD, LBYTES or OPEN/INPUT is used - only the filesize itself, and files of all other sizes do not seem to be affected.

Like I said, very odd behaviour.

Ill be working on this during the evenings over the week ahead and will update this thread again in due course.

[afx]

Hi Martin.

In my setup I have discovered the following interesting issues, possibly useful in your investigation of the problem.

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!

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.

The data of my setup that you have requested are the following:

- PC-host OS/QL Emulator, relevant configuration etc

PC Windos 10 / QPC2 5.02. (Without any relevant features).

- The QDOS/TK2/(S)GC ROM versions and hardware

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

- QL board Issue, GC/SGC or other expansion fitted- on the Peer QL

QL Issue 6, SGC, QL-SD (MK edition), SerMouse, Hermes.

- If a Q68, the version of the ND-Q68 driver in use

ND-Q68 v3.05.

- Details about the QLUB Adapter - e.g. Firmware version, whether self-built, microcontroller variant, using MK's PCB design etc

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

-What, if any, Timing-Constants needed to be adjusted to make each connection work

I haven't adjusted the Timing-Constant values, I use the predefined ones in your software.


Best regards,

[Maskenlos]

Hi all,

just to share my findings. To get it working with my GoldCard QL I needed to adjust the parameter "ESCT" (GC SCOUT) from "01E5" to "020D". This can be don with the file loadNDMQ_bas from Martyn.

I also can confirm that it is working with uQLx.

Stephan

[martyn_hill]

Hi Stephan!

just to share my findings. To get it working with my GoldCard QL I needed to adjust the parameter "ESCT" (GC SCOUT) from "01E5" to "020D". This can be don with the file loadNDMQ_bas from Martyn. I also can confirm that it is working with uQLx.

Thanks for the feedback - glad its now working with your GC and with uQLx!

Just keep an eye on that bizarre 'filelength' issue that I posted below and am still hunting-down