The Sinclair QL Forum

I've been doing some tests with the Q68's serial port.

It's well known that it doesn't support flow control. So this means that if you receive data at, say, 38400 bps or higher, you need a buffer large enough to hold all the incoming data to give the Q68 a chance to digest it (for example to write a BBS page to the screen or save a block to SDcard). I know that the Q68 uses external interrupts to transfer incoming data from the UART to the input buffer so this shouldn't be a problem as long as the buffer is large enough.

I noticed that at 38400 bps, the Q68 could keep up with a page of ANSI-BBS graphics in QL MODE 4, but missed out in display mode 6 (512x384x65536). So I'm wondering what the size of the Q68's input buffer is under SMSQ/E.

I also noticed that the SER_BUFF command which can be used to set the buffer size in SMSQ/E is present in the Q68 version, but it always gives a 'not found' error message irrespective of the arguments I specify.
Is this a bug or a 'feature''?

Jan.

Jan,
this is an interesting topic.
may I suggest to write to QL-Users list? Wolfgang could be useful to answer this topic, but he reads only the mailing list.

Fabrizio

janbredenbeek wrote:I've been doing some tests with the Q68's serial port.

It's well known that it doesn't support flow control. So this means that if you receive data at, say, 38400 bps or higher, you need a buffer large enough to hold all the incoming data to give the Q68 a chance to digest it (for example to write a BBS page to the screen or save a block to SDcard). I know that the Q68 uses external interrupts to transfer incoming data from the UART to the input buffer so this shouldn't be a problem as long as the buffer is large enough.

I noticed that at 38400 bps, the Q68 could keep up with a page of ANSI-BBS graphics in QL MODE 4, but missed out in display mode 6 (512x384x65536). So I'm wondering what the size of the Q68's input buffer is under SMSQ/E.

I also noticed that the SER_BUFF command which can be used to set the buffer size in SMSQ/E is present in the Q68 version, but it always gives a 'not found' error message irrespective of the arguments I specify.
Is this a bug or a 'feature''?

Jan.

I haven't received any meaningful mail from that list for a couple of years. Does anyone even use it any more?

Dave,

The list has been working during the last years (and is working to this date) properly. In case you miss messages or don't even get any, unsubscribing and resubscribing could help - The frequency of messages is, however, much higher here.

Tobias

janbredenbeek wrote:So I'm wondering what the size of the Q68's input buffer is under SMSQ/E.

The hardware buffer size is 16 Bytes. SMSQ/E I don't know.

Message sent to the QL-Users list.

Of course I could find out by delving into SMSQ/E's source code. But the SER_BUFF command probably needs fixing.
Meanwhile, I'll look at Minerva to see if a backport is possible. This will require a modification to its int2 handler since the Q68 treats the external interrupt differently.

Jan.

Jan,

what is the exact SER_BUFF command you are using?
As the Q68 has only one single port it might or might not be needed to specify the port number (which is different to most other SMSQ/E platforms)

Tobias

tofro wrote:what is the exact SER_BUFF command you are using?
As the Q68 has only one single port it might or might not be needed to specify the port number (which is different to most other SMSQ/E platforms)

I tried SER_BUFF 1,80,80, SER_BUFF 80,80 and SER_BUFF 80.
But I just discovered that all SER_xxxx commands give a 'not found' error.
Looks like they cannot find the driver's linkage block somehow.

Jan.

This might also explain a couple of pcorruptions I had at >38,600 speeds, but they don't show up often.

It's important to distinguish mass storage driver issues and SER. The SMSQ/E mass storage driver can get painfully slow during write, and blocks everything else. This affects ethernet as well - software buffers can't help reliably because no interrupts are handled meanwhile. Trying with Ramdisk instead of SDHC card can give a hint.

The Q68 as a machine is definitely fast enough to handle 38400 Baud receive easily without hardware handshake. I think sooner or later the SMSQ/E mass storage driver must be fixed - either remove/replace the crappy buffering altogether, or at least make sure the system is not completely blocked.