QLNET, Minerva, Tk2 and LBYTES - a curiosity...

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

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by martyn_hill »

Hi guys

@ Tobias: The Arduino has 2.5 k RAM, so I figured I could accommodate 1x Tk2 server reply packet for as long as it needs buffering and can be reclaimed ready for the next message. My idea was to use the Arduino solely at the physical layer, so each packet would be sync'd with the host in a store/forward manner, rather than carry out any real processing in lieu of the software running on QPC/SMSQ/E.

Meanwhile, my little USB Digital Analyser does a reasonable job of exposing the bit-stream and assist deciphering the source-code. We'll see!

@Rich - The SMSQ/E manual doesn't talk about the QLNET unfortunately - only SERNET - which, whilst a more obvious choice for mating a native QL with QPC, didn't prove effective in my earlier testing. I also prefer the simplicity of the QLNET hardware!

As for versions of Minerva - thanks for the offer - I can burn EPROMs with the various versions available on Dilwyn's site if it comes to that, but my suspicion is that whatever is causing the LBYTES issue with Tk2 arrived with Minerva's more 'compliant' approach over QDOS, which Tk2 was written against. Still, just a theory.

@Martin: I tested single packets too, careful to stick to 255 bytes (15 bytes simple fileheader + 240 data bytes).

What I saw on the wire was that the first response byte (0x01) from receiver to sender was never generated, so the sender (also Minerva - with or without Tk2) would keep re-sending the Scout+Net Header repeatedly. Without Tk2 on the receiver, the 0x01 acknowledge was generated as expected, and the sequence followed through as expected. Again, only seen with LBYTES - with OPEN/LOAD, the acknowledge from the receiver was generated as expected, within 40-70 us of the end of the header (and subsequent data packet) - just like when Tk2 wasn't running.

I would have suspected the different Issue boards, but the behaviour is symmetric between my Iss5 and Iss7 boards - only Tk2 on receiver running on either board seems to trigger the behaviour.

Its (almost) academic at the end of the day, as I'm testing between QLs now really just to learn enough to implement one half in the proposed USB-QLNET adapter. Would still want reliable reception at the QL (with Tk2) across the different commands.

Thanks for humoring me, so far!


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

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by martyn_hill »

...trawling again through the NET drivers, comparing Minerva source against the Tk2 source in SMSQ/E (is there another version/copy available elsewhere?), I note another key difference in how the net is managed - specifically how mismatches are handled between what was received and what was expected during the scout/header phase.

In Minerva, the sequence is restarted, looking for the next gap/scout/header - but staying very much within the same IOSS call/context.

In Tk2 on the other hand, a mismatch at any stage immediately returns NC to the IOSS (re-enabling interrupts and tidying the PC status reg enroute), and relies on subsequent IOSS calls (I guess, triggered by the scheduler) to restart the sequence from scratch.

As its most likely that the first attempt to read the gap/scout/header will 'miss', we can expect this difference in handling between Min and Tk2 to come in to play.

Time for bed...


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by tofro »

With regards to the scatter/gather algorithm used by LBYTES, this small sentence from the TK2 docs might be of importance:
If the block number received in a header is not equal to the block number required, then the header
and data block are acknowledged but ignored.
This doesn't look to me as if gather would actually work over the network with TK2.

As it appears that Tony deemed it necessary to state that fact in the TK2 docs, it might very well be that Minerva is of a different opinion here...

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
RWAP
RWAP Master
Posts: 2834
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by RWAP »

I wasn't referring to the SMSQ/e manual - but the SBASIC / SuperBASIC Reference Manual -

http://superbasic-manual.readthedocs.io ... a17-1-qnet

There is not a lot of information in there, but it would be an ideal opportunity to add some more notes once you find out anything more.

I wonder if Simon Goodwin's DIY Toolkit Flexynet (and accompanying articles) might be helpful too.


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

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by martyn_hill »

Ahh! Read to quick. I'll look there and offer anything learnt back thereafter.

And yes, read the Flexynet stuff many times and gathered a lot from it.

I now plan to try to dis-assemble Tk2, as I can't be sure the SMSQ/E sources match v2.23 that I'm currently using.

Will update again after some more digging.


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

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by martyn_hill »

...Found a ready dis-assembled version on Dilwyn's site... that'll save some time! Thanks to who-ever provided that one!


Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by Martin_Head »

Instead of making a QLNET to USB converter, what about a QLNET to Ethernet converter (Rasberry Pi?). You could then use the IP Net device driver http://www.dilwyn.me.uk/internet/IPNet.zip on the QPC2 side. All your converter would have to do, is a little reprocessing of the data packets, and deal with communicating with the QL.

Martin Head


User avatar
tofro
Font of All Knowledge
Posts: 2685
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by tofro »

Martin_Head wrote:Instead of making a QLNET to USB converter, what about a QLNET to Ethernet converter (Rasberry Pi?). You could then use the IP Net device driver http://www.dilwyn.me.uk/internet/IPNet.zip on the QPC2 side. All your converter would have to do, is a little reprocessing of the data packets, and deal with communicating with the QL.

Martin Head
Hi Martin,

I have thought about that - Would be another possibility (And actually, I think both can be achieved.). I think the main problem for the moment is being able to pick up the data properly from the wire and re-engineering the protocol.

Tobias


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by martyn_hill »

Hi Martin (and subsequently, Tobias)

Its a good alternative approach you suggest.

When I started this project about 12 months ago (yes, really!), the IP stack wasn't yet 'integrated' as well as it is today in to QDOS+Tk2 - which is what I wanted (the Tk2 file-serving capability, specifically), so was the path of least-resistance.

It would also take some careful thought as to how to 'bridge' the very distinct protocols (not just the physical bridging), which I don't currently have the understanding to execute on, whereas, simply compiling the NET + file-server driver back in to QPC/SMSQ/E and replacing the physical NET code with a layered call to the serial driver (still not trivial) and out via USB/Serial to an Arduino which would do the bit-banging on the wire (which is more my level!) still seems a reasonable approach, with less innovation required...

It was also intended more of a PoC than the modern, sophisticated solution that an Ethernet-bridge would offer.

Still, I like the idea... But baby-steps for me, I'm afraid!


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

Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...

Post by martyn_hill »

...Meanwhile, back to the problem reported in this thread - Minerva plus Tk2 NET 'incompatibility' when using LBYTES...

In parallel with adjusting the Tk2 source (found v2.23 source in Dilwyn's site from some kind soul!) - which, incidentally, looks pretty-much identical to that included in the SMSQ/E source for the NET driver specifically (this part probably hasn't evolved much over time) - I have also observed similar problems, though intermittent, when using FSERVE (contrary to my first observations). This would make sense, as the physical code of the NET driver is used equally by the file-server.

From time to time, we still see the missing 'acknowledge' from the receiver, causing the sender to repeatedly re-send scout+header, before eventually timing out. It just happens less than with a pure NET LBYTES call.

I will test one of my current theories later today - specifically that Minerva's NET implementation tidies-up after a NET 'session' (success or Not Complete) by restoring the SR register from the stack where it was saved at setup. Tk2, on the other-hand, does not save the SR register, but instead just blindly re-enables interrupts at exit, regardless of their state at time of the NET call - which is a bit naive, even if it fails to be the cause of the observed issue with LBYTES.

I'm assembling a slightly adjusted Tk2 v2.23 to mimic the SR save/restore that Minerva does. I'll post progress after (real) work today.

BTW - absolutely no disrespect to the original authors is intended - their work is amazing and designed against very different targets at the time they were developed - we stand on their shoulders!


Post Reply