Nested TRAP #3 I/O calls in SMSQ/E...
Posted: Wed Jan 24, 2018 1:53 pm
Hi everyone
Further to the on-going development of the QLAN to USB Bridge adapter (for emulators such as QPC), I am in the thick of researching how best to implement the calls to the Serial driver in SMSQ/E from _inside_ the (physical) NET IO driver. (and onwards to the microcontroller's USB/virtual COM Port.)
In principal, the design requires that prepared packets that were destined for the NET port, triggered by a NET I/O Trap #3 Access-layer call, jumping to what was the physical NET driver, but are now to be redirected to the SER driver for queuing to the SER/COM port.
I've read elsewhere about challenges in this area - whereby one Trap #3 call inside another upsets the OS - and have studied Martin Head's approach with his excellent IPNet suite (he calls the actual I/O vectors for the IP driver as extracted from the driver def/linkage block in place of Trap #3) and wonder what approach to adopt for this use-case.
I see two options and would welcome comment or alternatives, thus:
1. Adopt the approach of IPNet - extract the SER driver I/O vectors (test/fetch/putbyte) and call these directly, or
2. Stack the (NET) Channel ID, load A0 with the ID of an open STX Channel and Trap #3 with zero Timeout in D3 (to avoid the IOSS Retry getting tied in a knot upon ERR.NC)
Input most welcome!
Further to the on-going development of the QLAN to USB Bridge adapter (for emulators such as QPC), I am in the thick of researching how best to implement the calls to the Serial driver in SMSQ/E from _inside_ the (physical) NET IO driver. (and onwards to the microcontroller's USB/virtual COM Port.)
In principal, the design requires that prepared packets that were destined for the NET port, triggered by a NET I/O Trap #3 Access-layer call, jumping to what was the physical NET driver, but are now to be redirected to the SER driver for queuing to the SER/COM port.
I've read elsewhere about challenges in this area - whereby one Trap #3 call inside another upsets the OS - and have studied Martin Head's approach with his excellent IPNet suite (he calls the actual I/O vectors for the IP driver as extracted from the driver def/linkage block in place of Trap #3) and wonder what approach to adopt for this use-case.
I see two options and would welcome comment or alternatives, thus:
1. Adopt the approach of IPNet - extract the SER driver I/O vectors (test/fetch/putbyte) and call these directly, or
2. Stack the (NET) Channel ID, load A0 with the ID of an open STX Channel and Trap #3 with zero Timeout in D3 (to avoid the IOSS Retry getting tied in a knot upon ERR.NC)
Input most welcome!