QLAN-USB Adapter - working prototype...
Posted: Sun May 21, 2017 12:32 am
Hi everyone
After 18 months on and off, I have brought my 'QLAN-USB Adapter' project to a working prototype stage... Whilst its usefulness may prove limited to others, I'm quite chuffed and share it here out of sheer enthusiasm
I myself have no plans to make this a commercial offering, but will ultimately post here all the code and designs to allow anyone else to build their own...
In brief:
A small microcontroller-based device that connects to the PC via USB (as a virtual COM port), running code to speak the QLAN protocol down the original 2-wire cable, direct to a native QL (well, as many as QLAN allows). A simple but effective 'Message Queue' is implemented in both the microcontroller and mirrored in the emulated QL that manages the requests from the emulated QL's NET calls, packaging the requests (Send a packet, Read a packet, etc - Martin Head's innovative IPNet seems to do some similar 'encapsulation.') and placing them in the SER queue - from where it reads back the results on a subsequent interrupt.
Practically identical in concept to the (difficult to track-down) SerNET, but potentially faster (3-5 KB p.s. vs SerNET's 1.9 KB p.s. - with Hermes, of course) and using longer and cheaper cabling than RS-232 typically allows. My early attempts with the necessary SIm-Ser drivers and SerNET were not very promising.
Use of the Message Queue and off-loading the physical bit-banging to the uController should allow for smooth multi-tasking at the emulated QL end whilst the NET is otherwise busy - of course, the native QL's NET is operating in the same way as it always has.
Intended development will allow for TK2's FSERVE capabilities to also be accommodated and thus allow one or more native QLs to share the file/print resources available to the emulated QL. All down cheap, 2-wire cabling.
An interesting further development would be to integrate with Martin's IPNet - and potentially open-up the Internet to our humble Black Boxes...
Why?
Whilst developing an application on my PC laptop in QPC (and TextPad as the editor on Windows) to ultimately run on my QL, I got tired of transferring each update of the compiled program and data from QPC to the QL. I started-out using a serial-link and my own X-Modem-like transfer program, but that was bothersome - serial cables don't run very long and my laptop had no native COM port, unless I fitted its docking-station (and don't get me started on USB to Serial adapters...)
After investing in the terrific QL SD-Card adapter, I then used a physical SD card to get the updates across to the modded QL unit sat in my son's bedroom... As there are no SD-Card drivers currently available for QPC, that involved using Q-Emulator to copy between the QXL-WIN file used by QPC and the physical SD-Card. Oh, how tedious (no fault of Q-Em - another terrific piece of software!)
Never satisfied with 'it's working, but could be better', and having always been fascinated by the simplicity of the QLAN network, I started this project to ultimately link QPC (or any QL Emulator that can access the PC's COM ports) direct to a native QL via QLAN.
Or perhaps it was just born of procrastination at finishing the next version of my son's Scalextric lap-counter/timer that I rigged-up to Hermes on the QL.
Status:
I've got the core software running on the uController (an Arduino-like, Teensy++2.0) and as of a couple of hours ago, able to reliably send a single packet successfully to the remote QL. Sending in QLAN requires a couple of read acknowledgements per packet, so the primitive read routines also seem to work. Timing is everything
The test packets are currently built and sent/received by a fairly complex SBasic program running on QPC to implement the Message Queue handler, which will need to be rewritten in MC in due course.
I expect to complete the uController code in the next week or so and then move on the more onerous task of re-compiling the Tk2 NET-FSERVE drivers for QPC/SMSQ, but with the 'physical' NET calls patched to speak to the Message Queue handler code instead (which will do all the send/receive via the SER port.)
P.S.
I have poured over the available sources for QDOS, Minerva and Tk2 NET source code for many hours and think I have gotten to grips with it all - in due course, I will share my findings. How FSERVE does its thing is reminiscent of modern-day RPC calls and really quite clever. Thanks TT!
After 18 months on and off, I have brought my 'QLAN-USB Adapter' project to a working prototype stage... Whilst its usefulness may prove limited to others, I'm quite chuffed and share it here out of sheer enthusiasm
I myself have no plans to make this a commercial offering, but will ultimately post here all the code and designs to allow anyone else to build their own...
In brief:
A small microcontroller-based device that connects to the PC via USB (as a virtual COM port), running code to speak the QLAN protocol down the original 2-wire cable, direct to a native QL (well, as many as QLAN allows). A simple but effective 'Message Queue' is implemented in both the microcontroller and mirrored in the emulated QL that manages the requests from the emulated QL's NET calls, packaging the requests (Send a packet, Read a packet, etc - Martin Head's innovative IPNet seems to do some similar 'encapsulation.') and placing them in the SER queue - from where it reads back the results on a subsequent interrupt.
Practically identical in concept to the (difficult to track-down) SerNET, but potentially faster (3-5 KB p.s. vs SerNET's 1.9 KB p.s. - with Hermes, of course) and using longer and cheaper cabling than RS-232 typically allows. My early attempts with the necessary SIm-Ser drivers and SerNET were not very promising.
Use of the Message Queue and off-loading the physical bit-banging to the uController should allow for smooth multi-tasking at the emulated QL end whilst the NET is otherwise busy - of course, the native QL's NET is operating in the same way as it always has.
Intended development will allow for TK2's FSERVE capabilities to also be accommodated and thus allow one or more native QLs to share the file/print resources available to the emulated QL. All down cheap, 2-wire cabling.
An interesting further development would be to integrate with Martin's IPNet - and potentially open-up the Internet to our humble Black Boxes...
Why?
Whilst developing an application on my PC laptop in QPC (and TextPad as the editor on Windows) to ultimately run on my QL, I got tired of transferring each update of the compiled program and data from QPC to the QL. I started-out using a serial-link and my own X-Modem-like transfer program, but that was bothersome - serial cables don't run very long and my laptop had no native COM port, unless I fitted its docking-station (and don't get me started on USB to Serial adapters...)
After investing in the terrific QL SD-Card adapter, I then used a physical SD card to get the updates across to the modded QL unit sat in my son's bedroom... As there are no SD-Card drivers currently available for QPC, that involved using Q-Emulator to copy between the QXL-WIN file used by QPC and the physical SD-Card. Oh, how tedious (no fault of Q-Em - another terrific piece of software!)
Never satisfied with 'it's working, but could be better', and having always been fascinated by the simplicity of the QLAN network, I started this project to ultimately link QPC (or any QL Emulator that can access the PC's COM ports) direct to a native QL via QLAN.
Or perhaps it was just born of procrastination at finishing the next version of my son's Scalextric lap-counter/timer that I rigged-up to Hermes on the QL.
Status:
I've got the core software running on the uController (an Arduino-like, Teensy++2.0) and as of a couple of hours ago, able to reliably send a single packet successfully to the remote QL. Sending in QLAN requires a couple of read acknowledgements per packet, so the primitive read routines also seem to work. Timing is everything
The test packets are currently built and sent/received by a fairly complex SBasic program running on QPC to implement the Message Queue handler, which will need to be rewritten in MC in due course.
I expect to complete the uController code in the next week or so and then move on the more onerous task of re-compiling the Tk2 NET-FSERVE drivers for QPC/SMSQ, but with the 'physical' NET calls patched to speak to the Message Queue handler code instead (which will do all the send/receive via the SER port.)
P.S.
I have poured over the available sources for QDOS, Minerva and Tk2 NET source code for many hours and think I have gotten to grips with it all - in due course, I will share my findings. How FSERVE does its thing is reminiscent of modern-day RPC calls and really quite clever. Thanks TT!