QLNET, Minerva, Tk2 and LBYTES - a curiosity...
Posted: Mon Oct 10, 2016 9:22 pm
Hi everyone!
Question: Has anyone come across LBYTES consistently failing on a QL running Minerva + TK2 ?
I've found ways around it for my purposes, but think I've uncovered an incompatibility with this combination that I've never seen written before.
Curiously, aside from the above, I've found the N/W to run quite reliably...
Setup:
QL1 - Issue 7, custom SRAM memory expansion, plus NVRAM holding Tk2 plus other goodies.
QL2 - Issue 5, custom SRAM exp, shadowing internal DRAM and also made (partially) non-volatile to hold various goodies.
Background:
So, for some time now, I have been exploring the QLNET functionality, with the (ultimate) aim of building a small USB to QLNET interface to link QPC/laptop to a BBQL - with Tk2's fileserver capability. Before anyone gets too excited, the end-goal is still some way off...
After many hours pouring over the Minerva and SMSQ/E source code (that still has Tk2 source embedded in it for the N/W and MDV), with the Tk2 description of the QLNET protocol as a (vague) guide, I then moved to testing a pair of QLs (the second resurrected, with a custom-built memory expansion, shadowing the internal DRAM, which was flaky. Quite proud of that hardware project, actually...) and 'sniffing' the network by hooking-up a cheapo USB Digital Analyser between them.
To drive the test, I was using SBYTES/LBYTES of one display to the other.
After loads of permutations (really, loads...), I discovered that without Tk2 loaded on the destination (LBYTES) QL, the N/W worked flawlessly (within its limits).
The moment Tk2 was loaded on the destination QL, nothing would pass. Didn't matter which version of Tk2 (tried 2.13, 2.20, 2.23 and 2.26) and whether or not Tk2 was loaded on the source (SBYTES) QL.
Didn't matter which direction, either (QL1 to QL2 or vice-versa).
However, I could LOAD and OPEN 'neti_x' and pretty much everything else I've tried so far, and they would work. Only when LBYTES was used at the destination running Tk2 on Minerva would it fail.
I tried MGUK + Tk2 and that didn't seem to be a problem, even for LBYTES, so I'm guessing that there is some incompatibility specifically between Minerva and Tk2 whenever the LBYTES (ok, "fs.load" to be precise) is invoked.
The only fundamental difference I could find between Tk2 and Minerva's N/W source was the way the SCOUT is prepared (shouldn't matter as the timings are still very similar and the scout is skipped once detected) and how interrupts are disabled/re-enabled at set-up/close-down of the N/W activity.
As LBYTES/fs.load does something funky with that scatter-load idea (not especially relevant for a pure serial interface like the N/W), which I think involves disabling interrupts as well, I reckon its in there somewhere.
Or I could be wrong.
Just thought to share, anyways.
Question: Has anyone come across LBYTES consistently failing on a QL running Minerva + TK2 ?
I've found ways around it for my purposes, but think I've uncovered an incompatibility with this combination that I've never seen written before.
Curiously, aside from the above, I've found the N/W to run quite reliably...
Setup:
QL1 - Issue 7, custom SRAM memory expansion, plus NVRAM holding Tk2 plus other goodies.
QL2 - Issue 5, custom SRAM exp, shadowing internal DRAM and also made (partially) non-volatile to hold various goodies.
Background:
So, for some time now, I have been exploring the QLNET functionality, with the (ultimate) aim of building a small USB to QLNET interface to link QPC/laptop to a BBQL - with Tk2's fileserver capability. Before anyone gets too excited, the end-goal is still some way off...
After many hours pouring over the Minerva and SMSQ/E source code (that still has Tk2 source embedded in it for the N/W and MDV), with the Tk2 description of the QLNET protocol as a (vague) guide, I then moved to testing a pair of QLs (the second resurrected, with a custom-built memory expansion, shadowing the internal DRAM, which was flaky. Quite proud of that hardware project, actually...) and 'sniffing' the network by hooking-up a cheapo USB Digital Analyser between them.
To drive the test, I was using SBYTES/LBYTES of one display to the other.
After loads of permutations (really, loads...), I discovered that without Tk2 loaded on the destination (LBYTES) QL, the N/W worked flawlessly (within its limits).
The moment Tk2 was loaded on the destination QL, nothing would pass. Didn't matter which version of Tk2 (tried 2.13, 2.20, 2.23 and 2.26) and whether or not Tk2 was loaded on the source (SBYTES) QL.
Didn't matter which direction, either (QL1 to QL2 or vice-versa).
However, I could LOAD and OPEN 'neti_x' and pretty much everything else I've tried so far, and they would work. Only when LBYTES was used at the destination running Tk2 on Minerva would it fail.
I tried MGUK + Tk2 and that didn't seem to be a problem, even for LBYTES, so I'm guessing that there is some incompatibility specifically between Minerva and Tk2 whenever the LBYTES (ok, "fs.load" to be precise) is invoked.
The only fundamental difference I could find between Tk2 and Minerva's N/W source was the way the SCOUT is prepared (shouldn't matter as the timings are still very similar and the scout is skipped once detected) and how interrupts are disabled/re-enabled at set-up/close-down of the N/W activity.
As LBYTES/fs.load does something funky with that scatter-load idea (not especially relevant for a pure serial interface like the N/W), which I think involves disabling interrupts as well, I reckon its in there somewhere.
Or I could be wrong.
Just thought to share, anyways.