Using the QIMSI-QL Link
-
- Aurora
- Posts: 946
- Joined: Sat Oct 25, 2014 9:53 am
Re: Using the QIMSI-QL Link
Hi Peter
It's perhaps more accurate to say that QDOS inhibits IO ops on a _channel_ whilst that same channel is pending on a prior operation to complete.
As the regular SERial device driver limits one open channel to a given port at any given time, the need for the dual channel arises for certain use cases.
As for whether this is the actual reason for the SERNet driver insisting on the split SRX/SRX device, that's more speculative - without visibility of the source code, I can only make assumptions (and one of the reasons why I developed the QLUB...)
Anyhow, back on topic
It's perhaps more accurate to say that QDOS inhibits IO ops on a _channel_ whilst that same channel is pending on a prior operation to complete.
As the regular SERial device driver limits one open channel to a given port at any given time, the need for the dual channel arises for certain use cases.
As for whether this is the actual reason for the SERNet driver insisting on the split SRX/SRX device, that's more speculative - without visibility of the source code, I can only make assumptions (and one of the reasons why I developed the QLUB...)
Anyhow, back on topic
Re: Using the QIMSI-QL Link
Is it possible to write a driver allowing more channels, or is this restriction imposed by the OS structure?martyn_hill wrote: ↑Sat Oct 14, 2023 5:07 pm As the regular SERial device driver limits one open channel to a given port at any given time, the need for the dual channel arises for certain use cases.
Re: Using the QIMSI-QL Link
You could possibly open a large amount of channels to the same hardware (UART, for example) - You'd need, however, some sort of criteria (an address, for example) on the receiving end to be able to identify what belongs to where. An ethernet driver is a perfect example for that.Peter wrote: ↑Sat Oct 14, 2023 5:43 pmIs it possible to write a driver allowing more channels, or is this restriction imposed by the OS structure?martyn_hill wrote: ↑Sat Oct 14, 2023 5:07 pm As the regular SERial device driver limits one open channel to a given port at any given time, the need for the dual channel arises for certain use cases.
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
-
- Aurora
- Posts: 946
- Joined: Sat Oct 25, 2014 9:53 am
Re: Using the QIMSI-QL Link
Hi Peter
It just so happens that the default QDOS (and probably SMSQe) SER driver checks whether the given port-number already has a channel open to it and rejects a subsequent channel-open call if so.
How many channels (only one or many) that can be opened to a given logical device is entirely down to the device-driver to determine, QDOS doesn't care - at least for 'simple' devices (beyond its maximum concurrent allocation of channel tables.)
It just so happens that the default QDOS (and probably SMSQe) SER driver checks whether the given port-number already has a channel open to it and rejects a subsequent channel-open call if so.
Re: Using the QIMSI-QL Link
Not in this case. There is only one reading and one writing channel, not several reading channels.
- janbredenbeek
- Super Gold Card
- Posts: 637
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
- Contact:
Re: Using the QIMSI-QL Link
Here is a new version of the driver using SRX1 and STX1 device names, which actually do the same thing. There is no check whether an application tries to write to a SRX device and vice versa.
I've tested this with SerNET insofar that invoking a SNET_START command now doesn't report an error. I haven't tried actual data transfers yet (need first to solder a serial cable to QIMSI, which I rather do not want to try at this late hour).
You need to run SMSQ/E to load SerNET since it refuses to load on Minerva (well, maybe it could be tricked by temporarily changing the QDOS version returned...)
Jan
I've tested this with SerNET insofar that invoking a SNET_START command now doesn't report an error. I haven't tried actual data transfers yet (need first to solder a serial cable to QIMSI, which I rather do not want to try at this late hour).
You need to run SMSQ/E to load SerNET since it refuses to load on Minerva (well, maybe it could be tricked by temporarily changing the QDOS version returned...)
Jan
- Attachments
-
- qimsi_fifo.zip
- (1.94 KiB) Downloaded 183 times
- janbredenbeek
- Super Gold Card
- Posts: 637
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
- Contact:
Re: Using the QIMSI-QL Link
Sending and receiving on one SER channel is perfectly possible as long as you don't keep hogging the channel with infinite timeouts (as terminal emulators have already shown 30+ years ago).martyn_hill wrote: ↑Sat Oct 14, 2023 5:07 pm As the regular SERial device driver limits one open channel to a given port at any given time, the need for the dual channel arises for certain use cases.
As for whether this is the actual reason for the SERNet driver insisting on the split SRX/SRX device, that's more speculative - without visibility of the source code, I can only make assumptions (and one of the reasons why I developed the QLUB...)
Apart from that, I can imagine that there is a valid reason to keep access to a serial port limited to one job at a time.
-
- Font of All Knowledge
- Posts: 4029
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Using the QIMSI-QL Link
Hi Jan,
I have fitted the 3 pin header to my QIMSI, just need to connect up a Sernet cable to Q68.
I have fitted the 3 pin header to my QIMSI, just need to connect up a Sernet cable to Q68.
Regards,
Derek
Derek
Re: Using the QIMSI-QL Link
Many thanks!janbredenbeek wrote: ↑Sat Oct 14, 2023 10:01 pm Here is a new version of the driver using SRX1 and STX1 device names, which actually do the same thing. There is no check whether an application tries to write to a SRX device and vice versa.
I can confirm that SERNET works now, and FSERVE works on top. The Q68 getting a file or directory from the QL appears fast, although this involves the bitwise write access to the ROM port.
The other direction (QL reading from Q68) is painfully slow, probably due to the fact that the driver does not (and can not) use receive interrupts. Probably at least a polled interrupt service routine is needed to resume receive operation after blocking. (It is late and I might be wrong.)
By the way, I think it would be better to use SRX4 and STX4, so there is no confusion with the QL's two ports and Hermes' extra port. SER4 should also be a valid device name for normal serial port operation.
- janbredenbeek
- Super Gold Card
- Posts: 637
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
- Contact:
Re: Using the QIMSI-QL Link
I might speed this up a bit by unrolling the loop, as discussed by mail.
It has probably to do with the speed at which the QL can digest data from the fifo. 115200 bps means 288 bytes per 20ms, since the fifo is 512 bytes it should be emptied every frame interrupt. Writing to a physical device will stall interrupts for some time so should be avoided, only RAMdisk is safe.The other direction (QL reading from Q68) is painfully slow, probably due to the fact that the driver does not (and can not) use receive interrupts. Probably at least a polled interrupt service routine is needed to resume receive operation after blocking. (It is late and I might be wrong.)
Also keep in mind that there is no hardware flow control. This shouldn't be a problem if data is sent in packets (I'm not sure how long they are in SERnet, probably 256 bytes like 'ordinary' QLNet?).
An extra interrupt handler would have to read bytes from the fifo and store them in an even larger buffer (like in SMSQ/E) but the higher layers still have to be able to digest the data fast enough, else you will have the same problem if the large buffer eventually overflows.
The current version of the driver doesn't check the overrun bit, maybe a PEEK will show it? Will reading a byte from the receive fifo reset it?
Allright, will change that.By the way, I think it would be better to use SRX4 and STX4, so there is no confusion with the QL's two ports and Hermes' extra port. SER4 should also be a valid device name for normal serial port operation.
Jan