Maybe. But as long as we do not understand the mechanism, how blocking on receive data does resume at all when more data arrives, I'm sceptical. The behaviour is just too slow to be explained by performance issues, considering the SGC hardware. You will see yourself, after you soldered your serial adaptor.janbredenbeek wrote: ↑Sat Oct 14, 2023 11:57 pm It has probably to do with the speed at which the QL can digest data from the fifo.
Normally a device interrupt, or at least a polling/timer interrupt is required to trigger resume. (In general for a multitasking OS - not just for the QL). Fact is, the QL somehow does resume receive, otherwise SERNET wouldn't work at all. We better find out how.
Yes. That is what I mainly had in mind when designing the hardware FIFOs.janbredenbeek wrote: ↑Sat Oct 14, 2023 11:57 pm 115200 bps means 288 bytes per 20ms, since the fifo is 512 bytes it should be emptied every frame interrupt.
Firstly: In out use case, it works well for the Q68, with just 16 Bytes receive FIFO. That FIFO would certainly overrun during the storage operation with disabled interrupts. I guess it does not matter for SERNET, because data is written to storage after being received, and not during receive. The handshake probaly continues afterwards.janbredenbeek wrote: ↑Sat Oct 14, 2023 11:57 pm Writing to a physical device will stall interrupts for some time so should be avoided, only RAMdisk is safe.
Secondly: I can add 16 KB receive FIFO if that makes you feel better. The coprocessor can easily do that in software for 115 kBaud.
First we need to see if buffer overrun is the problem at all. The hardware FIFO is just as fast as a software buffer would be. A software buffer is not really needed as long as hardware FIFO size is sufficient for the intended protocol.janbredenbeek wrote: ↑Sat Oct 14, 2023 11:57 pm 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.
But it is needed that receive resumes relatively fast after blocking, and an interrupt could provide that.
No, there will never be an overrun on the QL side for the SER port use, as my MiniQ68 program never feeds more data into the FIFO than room available. But I should add an overrun indication, maybe a blinking LED or so.janbredenbeek wrote: ↑Sat Oct 14, 2023 11:57 pm The current version of the driver doesn't check the overrun bit, maybe a PEEK will show it?
All the best
Peter