Q68 serial buffers

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

Re: Q68 serial buffers

Post by janbredenbeek »

Peter wrote: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.
Overlapping disk I/O and serial I/O has always been an issue on BBQL hardware and many comms applications use ramdisk for temporary storing or at least buffering downloads.
But even when viewing simple BBS pages you might get overruns when display I/O is slow (at hi-res modes). At 38400 bps, characters come in at 76 per frame which means that your application has to write to the display at least as fast or you need a fairly big buffer so the display can keep up using XON/XOFF. Interrupts are not the issue here as they don't have to be disabled, but at 65536 colours display I/O is too slow to handle serial I/O without flow control.
It would be nice if the Q68 would have a 16-colour display mode as a compromise between colour resolution and speed ;) .

Now I'm off to spend some time trying to fix SMSQ/E's serial driver :)

Jan.


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

Re: Q68 serial buffers

Post by janbredenbeek »

janbredenbeek wrote: 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.
Found the bug. All the SER_* commands set the parameters through a Thing called 'ser_par_prt'. However, in the Q68 version it is called 'ser_prt' for some reason (because the Q68 has no PAR prt?). So the SER_* commands cannot find the Thing anymore.
Now the next challenge is to rebuild SMSQ/E (for some reason SMSQEMake crashes at line 7810 with a 'not found' error).

Jan.


User avatar
RalfR
Aurora
Posts: 870
Joined: Fri Jun 15, 2018 8:58 pm

Re: Q68 serial buffers

Post by RalfR »

janbredenbeek wrote:However, in the Q68 version it is called 'ser_prt' for some reason (because the Q68 has no PAR prt?). So the SER_* commands cannot find the Thing anymore.
Hmm, why on earth was it changed....?


4E75 7000
Derek_Stewart
Font of All Knowledge
Posts: 3901
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: Q68 serial buffers

Post by Derek_Stewart »

janbredenbeek wrote:
janbredenbeek wrote: 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.
Found the bug. All the SER_* commands set the parameters through a Thing called 'ser_par_prt'. However, in the Q68 version it is called 'ser_prt' for some reason (because the Q68 has no PAR prt?). So the SER_* commands cannot find the Thing anymore.
Now the next challenge is to rebuild SMSQ/E (for some reason SMSQEMake crashes at line 7810 with a 'not found' error).

Jan.
Hi Jan,

I would think Wolfgang Lenerz needs to look at this, as it is a change to the SMSQ/E operating system.

Sorry about the spelling mistake...


Regards,

Derek
Post Reply