The Sinclair QL Forum

Does 'QoE Ethernet driver for Q68' imply that the driver won't work on the QL implementation of the hardware?

Dave wrote:Does 'QoE Ethernet driver for Q68' imply that the driver won't work on the QL implementation of the hardware?

I can think of a few of possible problem areas.

1. I don't know how well a 7.5MHz 68008 can keep up with reading data packets from the CP2200 controller chip.

2. The driver makes use of the Q68 hardware timer. I don't know if you are implementing something similar. The real time clock, and software loops may be able to replace the Q68 hardware timer.

3. The driver reserves 256K of RAM as a buffer for read data packets. This could easily be lowered, but I don't know how low you can go before you start getting 'out of memory' errors.
It's something you would have to play with to find a happy medium. I would not be surprised if the driver worked with a buffer of 10K, or 20K. But bear in mind that a single fragmented UDP packet can be up 65K in length.

Apart from the Q68 hardware timer issues, As far as I know, off the top of my head. All you would need to do, is to alter the addresses of the CP2200 registers in the CP2200key_in file to what ever hardware addresses you have used.

[EDIT] Also I don't know if the driver will work in QDOS/Minerva. It should, I think the only SMSQ/E specific code is in determining the Country specific language, which should default to English if the system trap fails. And the 'channels' information from the Extended environment.

Hi,

I suppose the QL QoE Ethernet driver will only be viable when the hardware is available...

Martin_Head wrote:1. I don't know how well a 7.5MHz 68008 can keep up with reading data packets from the CP2200 controller chip.

I'd expect throughput only moderately higher than QL network. But it would provide the ethernet connectivity.

Martin_Head wrote:[EDIT] Also I don't know if the driver will work in QDOS/Minerva.

This can be tested on the Q68, I just found no time yet. Q68 Minerva will need an FPGA update for the external interrupt.

Also, an implementation without highres timer could be prepared on the Q68 before actually moving to the QL.

Peter wrote: This can be tested on the Q68, I just found no time yet. Q68 Minerva will need an FPGA update for the external interrupt.

My biggest concern about QDOS/Minerva, is if It might over fill the supervisor stack. I'm not sure if SMSQ/E has a bigger supervisor stack than QDOS.

Peter wrote:Also, an implementation without highres timer could be prepared on the Q68 before actually moving to the QL.

If Dave could implement something like the Q68 hardware timer, even if it ticked at a lower speed. It would make life a lot easier. I don't want to have to try to work out different software loops for a standard QL, a Gold card, and a SuperGold card.

Martin_Head wrote: My biggest concern about QDOS/Minerva, is if It might over fill the supervisor stack. I'm not sure if SMSQ/E has a bigger supervisor stack than QDOS.

It has. Significantly. You are supposed to use not more than 64 bytes on the QDOS SV stack vs. 512 bytes on SMSQ/E.

tofro wrote:

Martin_Head wrote: My biggest concern about QDOS/Minerva, is if It might over fill the supervisor stack. I'm not sure if SMSQ/E has a bigger supervisor stack than QDOS.

It has. Significantly. You are supposed to use not more than 64 bytes on the QDOS SV stack vs. 512 bytes on SMSQ/E.

As most of the driver operates in supervisor mode. And I do a lot of subroutine calls, with MOVEM instructions to preserve registers. I'm probably breaking the 64 byte rule in places.

Martin_Head wrote:

tofro wrote:

Martin_Head wrote: My biggest concern about QDOS/Minerva, is if It might over fill the supervisor stack. I'm not sure if SMSQ/E has a bigger supervisor stack than QDOS.

It has. Significantly. You are supposed to use not more than 64 bytes on the QDOS SV stack vs. 512 bytes on SMSQ/E.

As most of the driver operates in supervisor mode. And I do a lot of subroutine calls, with MOVEM instructions to preserve registers. I'm probably breaking the 64 byte rule in places.

That can be worked around by switching to a private SV stack on driver entry. I seem to recall I've once sent you an example on how this can be done. If not, please give me a shout.

tofro wrote:

Martin_Head wrote:

tofro wrote:
It has. Significantly. You are supposed to use not more than 64 bytes on the QDOS SV stack vs. 512 bytes on SMSQ/E.

As most of the driver operates in supervisor mode. And I do a lot of subroutine calls, with MOVEM instructions to preserve registers. I'm probably breaking the 64 byte rule in places.

That can be worked around by switching to a private SV stack on driver entry. I seem to recall I've once sent you an example on how this can be done. If not, please give me a shout.

I was thinking about a dummy stack. I don't remember you sending that exampe, and I have had a quick look at my old emails. Please could you send it again. If you've got a 'tiscali' email address for me, that now dead. PM me if you want the current one.

I'm currently trying to get Domain names working in the driver, If I can only figure out how to set up my local DNS server.

tofro wrote:

Martin_Head wrote: My biggest concern about QDOS/Minerva, is if It might over fill the supervisor stack. I'm not sure if SMSQ/E has a bigger supervisor stack than QDOS.

It has. Significantly. You are supposed to use not more than 64 bytes on the QDOS SV stack vs. 512 bytes on SMSQ/E.

Interestingly, on both systems the bottom (or top, since it grows downwards) of the SV stack is at $28480, leaving $300 (or 768) bytes room above the system variables which end at $28180.
(On QDOS, you might even have some more since it uses less space for system variables, which end at $2814E).