The Sinclair QL Forum

Martin_Head wrote: Something that has been nagging at the back of my mind, is that I may be crashing the supervisor stack, by over filling it with subroutine calls. I think there are only 64 bytes available on the supervisor stack. I am pretty sure I have done this before on this project.

Like tofro said, the supervisor stack has room for 768 bytes so you shouldn't overflow that quickly unless you put a lot of data on it.
It might be an interrupt issue. Does the CP2200 use its own interrupt level or is it shared with the other L2 interrupts?
I've done a quick peek into the serial controller which uses the L2 interrupt but doesn't set the external interrupt bit in the interrupt register, hence you can't use the external interrupt list but have to modify the L2 interrupt vector to put your own code in front of it to get serial I/O working in Minerva.

janbredenbeek wrote:

Martin_Head wrote: Something that has been nagging at the back of my mind, is that I may be crashing the supervisor stack, by over filling it with subroutine calls. I think there are only 64 bytes available on the supervisor stack. I am pretty sure I have done this before on this project.

Like tofro said, the supervisor stack has room for 768 bytes so you shouldn't overflow that quickly unless you put a lot of data on it.
It might be an interrupt issue. Does the CP2200 use its own interrupt level or is it shared with the other L2 interrupts?
I've done a quick peek into the serial controller which uses the L2 interrupt but doesn't set the external interrupt bit in the interrupt register, hence you can't use the external interrupt list but have to modify the L2 interrupt vector to put your own code in front of it to get serial I/O working in Minerva.

I should have said, I am talking about an interrupt routine that I think may be crashing the supervisor stack. The drivers interrupt routine is linked into both the hardware interrupt, and the 50/60Hz interrupt. And the CP2200 uses a normal level 2 interrupt.

I tried looking through the code yesterday, counting how much of the stack was being used. If I counted correctly, at one point I hit 72 bytes. I would like to keep this to below 64, so the driver could possibly work in QDOS/Minerva as well.

I was also looking at the Wireshark dumps that I have for when the lockups occurred, to see if it would give me any clues of where to look. I don't know if it's significant, but I saw 4 points in the middle of transmission where the driver hung for about 24 seconds, then resumed. So I don't know if something is getting stuck in a loop. But it seems to be random.

If you experience one of these 'hangs', try waiting 2 or 3 minutes to see if it recovers.

FrancoisLanciault wrote:Hi Martin,

I have successfully installed your driver to my Q68. When started, everything initialize correctly. I am able to ping other computers on my local network and ping the Q68 from them.

However I have not been successful of communicating with QPC on my laptop. I am pretty sure it is because of the 23 layers of firewalls my company has installed on it. As a matter of fact, it won’t even respond to ping request from the Q68 or any other computers.

As it is a company computer (and the only windows computers I have) there is probably not much I can do. But, just in case, what setting should I look for ?

François

I found another old and slow laptop. After cloning my QPC installation on it I can confirm everything works. No issues so far. Thank you!

janbredenbeek wrote:I've done a quick peek into the serial controller which uses the L2 interrupt but doesn't set the external interrupt bit in the interrupt register, hence you can't use the external interrupt list but have to modify the L2 interrupt vector to put your own code in front of it to get serial I/O working in Minerva.

Is there a serial driver for Q68 Minerva at all?

Peter wrote: Is there a serial driver for Q68 Minerva at all?

Not yet but I've done some research.
Backporting the driver from SMSQ/E is not easy since it depends on the Thing framework.
The best solution would be to replace the IPC code from Minerva with a new interrupt handler (possibly including the keyboard driver so the extension ROM area would be free again).
Anyone interested?

I was also considering to write a SER driver independent from SMSQ/E, partially based on my experiences with a Qx0 PAR driver long ago.
Probably I'd have looked at your own SER driver, which was for a specific UART, if I remember correctly.
It is unlikely that I'll have time for that in the coming months, but in general I'm interested in Q68 Minerva and the more complete/elegant the implementation is, the better.

The SER issue is somewhat related to this thread, as a working ethernet driver under Minerva would make it less dependant on SER to get some connectivity.

Peter wrote:I was also considering to write a SER driver independent from SMSQ/E, partially based on my experiences with a Qx0 PAR driver long ago.
Probably I'd have looked at your own SER driver, which was for a specific UART, if I remember correctly.

This was written for the 6850 UART. It was limited in that it doesn't have its own clock, as I used the BAUDX4 clock from the 8302 (which limited the maximum speed to 4800 bps).
One could leave the high-level (queue handling) part of the Minerva driver as it is and only rewrite the interrupt-level routines. On the downside, this doesn't change the rather small queue sizes (81 bytes). And the pointer to the linkage block has to be stored somewhere (perhaps SV_SER2C as there is no SER2 port anymore?). And the BAUD setting trap has to be modified.

janbredenbeek wrote:This was written for the 6850 UART.

Still the best I have found as an SMSQ/E-independent example, and by the way many thanks for publishing it! It should not be too hard to adapt the low level portions to the Q68.
Of course, a direct Q68 SER integration into Minerva would be even better, but that's beyond my skills, at least in a reasonable time frame. Sorry Martin for going off-topic a little.

Here is Version 0.25 of the driver. I have been trying to fix the random bad packet problems, And yesterday I threw my test programs at it, and saw no problems. So I thought I would post it.

Tried it again this morning just before posting, and I got the odd bad packet, with the same test programs I used yesterday. But I thought I would post it anyway, as I have fixed some problems, and there's a lot less bad packets than the last version had.

janbredenbeek wrote:I was able to successfully run QBOX as Telnet server on the Q68. Couldn't get QLTerm to work as Telnet client though,

Hi Jan, Did you try to investigate why QLTerm would not work? Is it a missing feature, or bug I need to find.