Q68 serial buffers

The Thor, Aurora, Q40, Q60 & Q68 etc. are discussed here.
User avatar
janbredenbeek
Gold Card
Posts: 332
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Q68 serial buffers

Postby janbredenbeek » Thu Jun 20, 2019 11:21 pm

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.


bixio60
Chuggy Microdrive
Posts: 50
Joined: Sun May 04, 2014 7:05 am

Re: Q68 serial buffers

Postby bixio60 » Sat Jun 22, 2019 3:52 pm

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.


User avatar
Dave
SandySuperQDave
Posts: 2415
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Q68 serial buffers

Postby Dave » Sat Jun 22, 2019 6:11 pm

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


User avatar
tofro
QL Wafer Drive
Posts: 1605
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Q68 serial buffers

Postby tofro » Sat Jun 22, 2019 6:34 pm

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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
Peter
Aurora
Posts: 850
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 serial buffers

Postby Peter » Sat Jun 22, 2019 7:02 pm

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.


User avatar
janbredenbeek
Gold Card
Posts: 332
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Q68 serial buffers

Postby janbredenbeek » Sat Jun 22, 2019 8:40 pm

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.


User avatar
tofro
QL Wafer Drive
Posts: 1605
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Q68 serial buffers

Postby tofro » Sat Jun 22, 2019 9:48 pm

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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
janbredenbeek
Gold Card
Posts: 332
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Q68 serial buffers

Postby janbredenbeek » Sat Jun 22, 2019 10:14 pm

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.


User avatar
Dave
SandySuperQDave
Posts: 2415
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Q68 serial buffers

Postby Dave » Sat Jun 22, 2019 11:05 pm

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


User avatar
Peter
Aurora
Posts: 850
Joined: Sat Jan 22, 2011 8:47 am

Re: Q68 serial buffers

Postby Peter » Sun Jun 23, 2019 9:39 pm

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.



Who is online

Users browsing this forum: No registered users and 1 guest