ND-MQ - New Network Driver for the QLUB Adapter

[Peter]

Great job Martyn!

(Didn't login for a while... still in shock about the ruined forum layout.)

[Derek_Stewart]

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?

Hi,

According the QLUB sales message: viewtopic.php?t=4233

The supplied transistor has to be fiitted reversed to the PCB silkscreen... PCB error?

If the transistor is fitted as PCB silkscreen, maybe this could explain the problem.

[Chr$]

It was absolutely not a PCB error. The transistor error was mine entirely. The silk screen on the PCB refers to a different transistor to the one I use(d) (BCE the other way round).

I've installed the new stuff on both my QLUB devices and look forward to trying it all out. I just need to run my 30ft cable through the house to the original QL!

Thanks Martyn.

[martyn_hill]

Hi again afx!

Well, I'm stumped (so far...) - if, as I currently suspect, the issue with the updated QLUB firmware in your setup is the set of default timing-constants, there is really only one difference of any substance between the firmware that works for you (v2.2A) and the latest (v2.3L) - but in itself that shouldn't be enough to upset the transmission.

Could you check and confirm whether or not the default timing-constants that appear in the DATA statements towards the very end of your working copy of SendFileMQ_v22_bas match the following (i.e. you didn't make changes to the copy you downloaded from the Forum to get it to work for you):

Code: Select all

...
8630 REMark *** Net Profiles allow the Timing Constants to be dynamically updated (as of QLUB v2.2a)
8640 REMark *** 0: Suited for QL
8650 DATA "00C8","4E20","0032","01DB","0BB8","0006","01F4","1388","00C8","0000","008C","00B4","9C40","0500","010E","00B4"
...

If they don't match, could you share your working set of timing-constants?

The value that I adjusted slightly between the two versions of the firmware was 'NDT_ESCT' - 01E5 (v2.3L) and 01DB (v2.2A) - a difference of only 10 us to the overall length of the SCOUT.

Meanwhile, I tested successfully the latest QLUB firmware against my Q68 with the last published ND-Q68 driver, v3.06 . The only difference in timing-constants between the ND-Q68 driver version you are using (v3.05) and v3,06 is in NDT_RDLY. I'll try again tomorrow with the older v3.05 and see if I can break my setup Alternatively, you might want to try downloading v3.06 from Dilwyn's site and trying that on your Q68.

My SGC QL is currently poorly, so I haven't yet tested the new QLUB firmware against that QL, but it works so far against 3 other QLs (Issue 6 & 7 boards) as well as a Spectrum (once the second set of timing-constants is uploaded to the QLUB.)

Good luck

[martyn_hill]

Good morning Peter!

Great job Martyn!

Thanks! I'll be happier once I start to get feedback from other QL'ers confirming that the new firmware/driver also works for them

[martyn_hill]

Morning Chris!

I've installed the new stuff on both my QLUB devices and look forward to trying it all out. I just need to run my 30ft cable through the house to the original QL!

Good luck!

Once you do get a chance to test-out the new stuff, I'd love to hear what combination of QL/ROMs etc it does (or does not) seem to work with. I'd like to start compiling a report, something like:

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

• The QDOS and TK2 ROM version (if fitted) and hardware (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. whether self-built, microcontroller varaint, using MK's PCB design etc

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

[martyn_hill]

Good morning Derek!

The supplied transistor has to be fiitted reversed to the PCB silkscreen... PCB error? If the transistor is fitted as PCB silkscreen, maybe this could explain the problem.

I considered this in afx's case, up until he confirmed that the same setup worked before, just with the earlier QLUB firmware version. I think we are hitting the nuances of different setups requiring small deviations from the standard timings to work reliably

[Derek_Stewart]

Hi Martyn,

I have 17 QLUB PCBs to make, sent very kindly from Chr$, just got to find time to make them and get a suitable case,wither 3D Printed or a commerial case.

I am a little pressed for time, with other projects, but I will get these done as soon as I can.

[martyn_hill]

Hi Derek!

Hi Martyn, I have 17 QLUB PCBs to make, sent very kindly from Chr$, just got to find time to make them and get a suitable case,wither 3D Printed or a commerial case.

That sounds like a great plan!

On a related topic (and whilst awaiting further community feedback on the new driver) I am currently reviewing the available options for an updated microcontroller. I myself have both a Teensy v3.6 and, on order, a v4.0. As well as the respective life-cycle and general availability of these devices, I am also taking in to consideration Marcel's existing QLUB PCB design.

The cloned Teensy ++2.0 is still available it seems from our Chinese friends, but I can't see this lasting long and with my plans (shhh!) for further enhancing the QLUB in to the future, a modern, more capable 32-bit uC seems the way to go.

All but the v4.0 have a larger footprint that would be clumsy to fit in the current PCB and all except the now defunct v3.5 are no longer 5V tolerant, which therefore requires some level-shifting.

My current preference is the Teensy v4.0 - it could still fit the existing PCB design, although several of the original DIL sockets would no longer be populated as the 4.0 is actually smaller than the ++2.0. Which just leaves the level-shifting to consider.

Anyone here have thoughts on this matter? A simple R1+R2 divider on NET input to the uC, or would the approach that Peter took with the Q68 work here too? If I'm not mistaken, Net output should still work fine, via the existing PNP transistor driving the NET output...

Meanwhile, back to troubleshooting with our early-adopters of the ND-MQ driver and firmware

[Derek_Stewart]

HI Martyn,

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.