Hi again!
Ok, so the combination of your screen-capture (albeit, without the LHS reference-point that would allow us to be sure of the bit position of any erroneous pixels), alongside some research of my own having now disassembled the AH Network code (comparing it to later QDOS equivalents) leads me to suspect that we are seeing the AH QL periodically start to read/sample the byte-frame just a little too 'late', because:
a) We see a significant number of single Cyan pixels when we expect just Blue - this is most likely the STOP bit sent by the QLUB being misinterpreted as the last bit (Green) of the first byte of the affected video word pair: Blue + Green = Cyan (easier to understand than to explain in words.),
and
b) Across ALL the original QDOS ROMs (AH through MG - even TB!), the Physical NET routines (Send/NT_SPCKT and Receive/NT-RPCKT Packet) are identical in ALL respects EXCEPT that in the AH Receive Packet routine, the Timing Constant used to align with bit-0 (that immediately follows the START bit) is a few cycles larger than in ALL the other QDOS ROMs (26 versus 19.) The subsequent inter-bit Timing Constant is consistent throughout all the ROMs I disassembled (=6.)
This _may_ also contribute to an explanation as to why you seem to have good comms with the Spectrum - the IO Contention observed in the Shadow ROM Net routine will, when it occurs, slightly
stretch the byte-frame sent - sometimes by as much as 2uS to
each of the first two or three bits of any affected byte - enough to upset the delicate SW loop-based timings at the receiver. And, given the Issue-5's own IO Contention when reading the ZX8302, may further exacerbate an already edge-case timing situation.
The 'stretching' at the receiver end that we see in AH could well be cancelling-out the problem
Now, given that you may not be in a position to modify the AH ROM code (though I REALLY recommend replacing with Minerva!) with the simple 2-byte adjustment to bring the Receive timing back in alignment with other versions of the OS (and the QLUB Adapter firmware), as well as the fact that this mod would
probably break your QL to Spectrum comms, the simplest adjustment would be to extend the Timing Constant "BIT0_TIME_SEND" in the QLUB firmware which defaults to '20'. I'd try small increments 21, 22 etc, until you get a reliable solid Blue display. If you see no discernible improvement by the time you get to '24', then I've probably got it completely wrong and no point pursuing that particular approach.
Of course, that would require the ability to recompile/flash the currently available source with the 'legacy' tool-chain (as was discussed previously/below.) The relevant Timing Constant can be found on line 112 of v2.1f of the provided uC source code.
...Or you could wait another week or so until I release a revised firmware with more 'sophisticated' timing routines that are 'compatible' with the latest Arduino IDE/Teensy libraries (specifically the Teensy delayMicrosecond() library.)
I'd be well chuffed if that fixes it for you, but remain open to further troubleshooting if not...
Good luck!
).
