QLUB Adapter - Initial Release...

Nagging hardware related question? Post here!
Post Reply
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QLUB Adapter - Initial Release...

Post by martyn_hill »

Good morning Marcel!

That's great feedback, thank you!

Yes, SendFileMQ includes a variable 'netSelf%' set near the top of the listing for my setup. Adjust as needed...

Now you remind me, I too use the Minerva variant of EDLINe$ on SMSQ/SBASIC rather than the original DIYTK version - if I remember correctly when I first switched to SBASIC many years ago, the relevant SMS IO Trap preserves slightly different registers than QDOS and the Minerva version better matches this.

Thanks for spotting this - I'll update the docs to point it out for others who may follow.

BTW - with the MOSFET approach, are you able to leave the cct connected to the Network whilst the adapter is disconnected from the PC host and the other connected stations still communicate OK?

I'm really enthused by the uptake of the solution so far - there's nothing more encouraging for further development effort than hearing that others find it useful!
Last edited by martyn_hill on Mon Jan 18, 2021 4:23 pm, edited 2 times in total.


User avatar
Peter
QL Wafer Drive
Posts: 1953
Joined: Sat Jan 22, 2011 8:47 am

Re: QLUB Adapter - Initial Release...

Post by Peter »

martyn_hill wrote:BTW - with the MOSFET approach, are you able to leave the cct connected to the Network whilst the adapter is disconnected from the PC host and the other connected stations still communicate OK?
In theory not, because the MOSFET's body diode clamps toward 0V when the supply is 0V. Similar issue as Q68, just that USB standby supply from the PC could keep this circuit supplied with minimal loss when the PC is off. Sorry for not mentioning this when coming up with MOSFETs.


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: QLUB Adapter - Initial Release...

Post by mk79 »

martyn_hill wrote:Now you remind me, I too use the Minerva variant of EDLINe$ on SMSQ/SBASIC rather than the original DIYTK version - if I remember correctly when I first switched to SBASIC many years ago, the relevant SMS IO Trap preserves slightly different registers than QDOS and the Minerva version better matches this.
Maybe next time supply the required extensions ;) Took me a while to dig them out (and look for any "NOT_L" extension before I spotted the extension here in the thread!) and then probably another halve to an hour to check why SMSQ/E kept crashing. Or rather curiously often it didn't crash right away but returned with an "Insufficient memory" error on a simple IF line.
BTW - with the MOSFET approach, are you able to leave the cct connected to the Network whilst the adapter is disconnected from the PC host and the other connected stations still communicate OK?
Oh, well spottet. I'm too lazy to connect more computers, but according to my scope a connected unpowered adapter lowers the NET level from about 4V to 3V. I don't care about that, but probably important for a general solution.

Cheers, Marcel


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QLUB Adapter - Initial Release...

Post by martyn_hill »

All good feedback, Marcel - thanks!

I'll add such comments/ideas in to the next release as well as to draw-out the additional guidance that is currently only documented in the REMarks in SendFileMQ itself.

Meanwhile - anyone here fancy trying this out on uQLx and feeding back here? All my own Unix hosts are all FreeBSD based and I haven't yet gotten uQLx running correctly in FreeBSD...

M.


Maskenlos
Over Heated PSU
Posts: 138
Joined: Sat Nov 03, 2018 12:14 pm

Re: QLUB Adapter - Initial Release...

Post by Maskenlos »

Hi Martyn,

I have uQLx running and will try it out. But still waiting for my Teensy board :-(.

Cheers,

Stephan


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QLUB Adapter - Initial Release...

Post by martyn_hill »

Hi Stephan!
Maskenlos wrote:I have uQLx running and will try it out. But still waiting for my Teensy board :-(.
That's terrirfic! I'll be ready to work with you once your Teensy arrives :-)


gbejniet
ROM Dongle
Posts: 21
Joined: Sun Feb 02, 2020 10:21 pm

Re: QLUB Adapter - Initial Release...

Post by gbejniet »

OK, I’ve built my version of this and it… almost works!! :)

I’ve ported sendfilemq to Python (as you do) and pretty much have it sending text files to the device. On the receiving QL I am spooling the output to the screen.

The result is heavily corrupted, only occasionally acking packets, I assume when the checksum is a false positive. Maybe about 20-25% of bytes are corrupt. A frequent corruption is the swap of bit 7 for bit 6, so for example r to φ, a to Ã, o to λ, etc. This isn’t universal though, my first thought was, ah, we have a timing problem, but there seems to be more to it than that maybe.

I have wiggled resistors and so on.

Writing to a Spectrum in the same way produces a much better result, with only very occasional corruption. I’ve seen these two machines, the Spectrum and the QL, send and receive reliably from each other before.

I’m changing “peerType” where necessary, although I can see that value itself doesn’t make its way to the Teensy, just the change in header format.

I wonder what this can be? I did order and use a ZTX510 specifically because being an absolute beginner around this kind of thing I didn’t want to go off piste in any way.

I’m 99% convinced I flashed QLAN-USB_v21f.ino_IDE180_TDv135.hex successfully, after reading the above, although I’d previously built from source, unless the above looks like the result you get if you build with the current toolchain. In which case I will quadruple check.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QLUB Adapter - Initial Release...

Post by martyn_hill »

Hi!

That's great - thanks for sharing your results!

I'm going to make a few assumptions - feel free to correct me.
a) You are running your Python'd SendFileMQ adaptation directly on the USB host connected to the Adapter. Furthermore, the adaptations are functionally identical to the provided SuperBasic program - if this was the culprit, you'll likely not get anything out of the adapter, so its a reasonable assumption for now...
b) You've matched as far as possible the passive/transistor circuitry as documented
c) You are pretty sure that the peer QL's NET and cabling is working TODAY (as opposed to 'last time I tried in 1984')
d) You've taken a few minutes to read the pertinent sections in the 'Networking the QL' document provided - especially:
1.3. Connecting Stations
1.6. Trouble-shooting QNET problems
e) You purchased a genuine or truly compatible Teensy ++2.0 dev board. I'm lead to believe that there are some nasty clones out there...

I have some targeted questions - we might return to these later:
Q1. Issue 5 or 6/7 of the QL PCB
Q2. QDOS/Minerva ROM version
Q3. Whether TK2 is loaded (and running from ROM or zero-wait-state RAM) and it's version
Q4. Would you care to share your Python adaption of SendFileMQ for me to review?

There are a few ways we can approach troubleshooting, depending upon what's available to you and your time/appetite:

1. Ideally - if you have a digital logic analyser available, we should look at the trace of the NET line - I use a simple and cheap unit I purchased from 'Hobby Components' in the UK, under the name "USB 8CH 24MHz 8 Channel Logic Analyser" see here:

https://hobbycomponents.com/testing/243 ... c-analyser

It's based on the quite common FX2 Logic Analyser chip-set and 'Sigrok' driver and supported by the Digital Logic Analyser application 'Pulse View', itself available here:

https://sigrok.org/wiki/Downloads

As an added bonus, if you have fitted the Teensy to a breadboard, it is a simple job to wire up all 8 digital pins (including the NET port itself) in to USB digital analyser (I'll share the relevant Teensy pin-numbers) and capture a bunch of other useful timing diagnostic signals that the firmware helpfully provides during transmission.

2. Without such a device, then we can infer quite a bit of useful info by choosing precisely what we send down the wire - during testing, until I get a more or less reliable comms, I use a MODE 8 solid BLUE QL display file (32kB) as a sample test-file transmission. As you appear to be running outside an emulator, I attach a file containing such a file. Why Blue? We shall see...
BLUE_scr.zip
(228 Bytes) Downloaded 85 times
No need to worry about QL file-headers when unzipping - its a pure binary file.

3. In any case, depending upon your timezone and access to Zoom or similar, I'd be happy to spare an hour or so (family-time permitting) over the weekend to walk-through some ideas with you 'in-person.' If you're sufficiently interested to devote some time to it this weekend, just PM me and we can arrange something.

My guess right now (always dangerous without all the data...) - the correct firmware (v2.1f) IS flashed OK (you'd get nothing at all at the peer QL if you used v2.1e), your Python adaptation is functionally sound BUT either:
- the Teensy board is out of spec or
- your peer QL timing is wonky (esp. if an Issue 5.)
- or has poor electrical connections at the NET ports.

Looking forward to helping you get this working :-)


gbejniet
ROM Dongle
Posts: 21
Joined: Sun Feb 02, 2020 10:21 pm

Re: QLUB Adapter - Initial Release...

Post by gbejniet »

First of all, thank you for so much help and detail here. A few responses:

a) Correct - as far as I can tell it is closely transliterated Python that does the same job and runs on this host
b) I believe so - all freshly ordered, all Rs are the values stated and tolerance 1%, transistor at least claims to be a ZTX 510
c) As far as I can tell - I ran tests between this QL and a Spectrum Interface 1 in both directions in the last couple of weeks. The cable is new and from a popular supplier of retro-computing gear.
d) Have read the appropriate parts and the one part that might apply - this is an Issue 5 board (AH ROM) so that could be a factor. Might that also affect QL/Spectrum networking though? I didn’t see an issue with that
e) To be honest this is the bit I am most suspicious I have done - I tried to filter out the obvious cowboys and drop shippers, but if it starts to look like it’s a bad board I will stop being a tightwad and go straight to the manufacturer.

Q1. Issue 5
Q2. AH
Q3. No TK2
Q4. Ah ha ha, I’m not quite sure I’m ready for a code review yet… Let me clean it up a bit and in the process if for whatever reason it solves the problem then I shall close my mouth and go away

I am certainly open to trying the logic analyser approach if we don’t determine from the above that what I have now is unworkable.

I think my next step might be to check and re-check everything, including trying your blue file to look for particular artifacts, before I take up any more of your time on it.

Again, huge thanks for this ingenious project.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QLUB Adapter - Initial Release...

Post by martyn_hill »

OK, so its been a long while since I played with the QL network with such an old QDOS version and without TK2.

I'll test here with AH and see if the bit-timings are any different than under TK2.

I'm intrigued by your report of QL to Spectrum working reliably - Daniele reported something similar - and yet I have never gotten reliable comms between the two until I tweaked the Shadow ROM in the Interface 1 itself (there are at least 3 bugs in the networking code in the v2 Shadow ROM) . Very curious...

I'm sure we'll get to the bottom of this one!

As for the significance of the solid blue display image as a test file, as long as some packets get through, the colour and placement of any erroneous pixels that render at the destination QL end (usng LBYTES 'neti_<sourceStationID>', 131072) can give very immediate visual clues as to the timing mismatch.

In particular:
a) if you see any Magenta pixels rendered or periodic Red pixels (especially as the first pixel every four columns), or if you see any FLASHing whatsoever, these symptoms typically indicate that the sender is 'too fast' or the receiver 'too slow', with the final 'STOP' bit being read instead as the final bit of the respective 'Red/Blue' or 'Green/Flash' video word.
b) Alternatively, if you spot Red pixels as the last of each four columns, this would indicate that the START bit was read twice by a receiver running too fast or the sender is too slow.
c) The more random the mix of the above symptoms, the more likely that IO contention is taking place - Issue 5 boards (with the ZX8302 sitting as it does on the bus shared with video-DRAM) are prone to this. You might also observe a diagonal region of corrupt-colour pixels steadily 'move' from top right down to bottom left of the display as the packets arrive and fill down the screen.

[EDIT} It's when troubleshooting such mistiming issues that the rather 'loose' error checking implemented by the Sinclair Network protocol actually comes-in handy (simple byte-additive check-summing) - Were the error-checking at all robust, you would get barely any visible evidence of the corrupt packets as they would be discarded long before reaching the display... One area for an enhanced protocol that i have been investigating involves the use of modulo-255 Fletcher-16 checksums - almost as easy to compute but significantly more robust. Anyways, a story for a future Network article... [/EDIT]

Anyway, let us know how you get on and I'll share my own results with AH later this week.


Post Reply