Using the QIMSI-QL Link

[martyn_hill]

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

[Peter]

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.

Is it possible to write a driver allowing more channels, or is this restriction imposed by the OS structure?

[tofro]

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.

Is it possible to write a driver allowing more channels, or is this restriction imposed by the OS structure?

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.

[martyn_hill]

Hi Peter

Is it possible to write a driver allowing more channels, or is this restriction imposed by the OS structure?

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.

[Peter]

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.

Not in this case. There is only one reading and one writing channel, not several reading channels.

[janbredenbeek]

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

[janbredenbeek]

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...)

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).
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.

[Derek_Stewart]

Hi Jan,

I have fitted the 3 pin header to my QIMSI, just need to connect up a Sernet cable to Q68.

[Peter]

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.

Many thanks!

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]

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.

I might speed this up a bit by unrolling the loop, as discussed by mail.

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.)

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.
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?

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.

Allright, will change that.

Jan