Re: QLNET, Minerva, Tk2 and LBYTES - a curiosity...
Posted: Tue Oct 11, 2016 11:41 pm
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!
@ 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!