Q68 QoE Ethernet Driver

[tofro]

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).

Yep that's interesting. My statement above is just a quote from the manuals - There's reasons to believe the authors of the Technical guide were simply more cautious. Actually, I see no reason why the supervisor stack would need to be located in the system variables (and be limited to the area available there). It could be moved to anywhere, as you're not supposed to access it directly anyhow. (But have no idea whether SMSQ/E actually moves it or not or if that's even needed.)

[janbredenbeek]

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).

Yep that's interesting. My statement above is just a quote from the manuals - There's reasons to believe the authors of the Technical guide were simply more cautious. Actually, I see no reason why the supervisor stack would need to be located in the system variables (and be limited to the area available there). It could be moved to anywhere, as you're not supposed to access it directly anyhow. (But have no idea whether SMSQ/E actually moves it or not or if that's even needed.)

Current versions of Minerva assume that the SSP lies within the same 32K segment as the system variables. Which is AFAIK the only way to determine the address of the system variables if you want dual screens and cannot store a pointer somewhere in system RAM (like SMSQ/E does).
That said, I do not see any problem in expanding the SV stack by moving up the tables that come after it (you would have to do it on startup though as the Common Heap cannot be moved once in use). On SMSQ/E it could be as big as hundreds of K since the area below 1MB is only used for system variables and tables and slave blocks (which are of little use nowadays).

[Dave]

I have a rather massive quantity of 8Kx8 SRAMs, and can throw one on the card to give it its own private memory area for the stack.

I can provide a ticker, and have provided for that. All I need is a target frequency for the ticker. I can divide it from the CPU clock or ethernet clock, or something else if it is available at the CPU socket.

It might be an idea to gate the ticker off the link light so if there is no cable inserted the QL is not slowed by the service routine? Or is that silly?

[Martin_Head]

I can provide a ticker, and have provided for that. All I need is a target frequency for the ticker. I can divide it from the CPU clock or ethernet clock, or something else if it is available at the CPU socket.

Currently, I think the shortest delay that I am using the Q68 hardware timer is for 500uS.

[Dave]

Ok. That's 2kHz. I can do that. Obviously it's not going to be 50% duty cycle. I need to go off and think a little to do it correctly. As a code defined ticker it can be altered later.

The ticker is an interrupt. What level interrupt should it be?

[Peter]

If you plan to support the 68008, a 2 kHz interrupt is probably not a good idea as it causes significant overhead for such a slow CPU.
The only thing that needs better than 20 ms granularity is PING. There are other places in the current driver code, but in principle 500µs are not needed to get the CP2200 work properly. (My own TCP/IP driver only uses the 50 Hz interrupt and the ethernet interrupt.)
Any chance to provide a counter register instead of an interrupt?

[Dave]

A counter would be easy to implement. The choice of signals available at the CPU socket are quite limited, though.

[Martin_Head]

Ok. That's 2kHz. I can do that. Obviously it's not going to be 50% duty cycle. I need to go off and think a little to do it correctly. As a code defined ticker it can be altered later.

The ticker is an interrupt. What level interrupt should it be?

There are quite a few places in my driver where I disable interrupts. I'm not certain without ploughing through the code, But I'm pretty sure that I use the Q68 hardware timer while interrupts are disabled.

Personally I would say use the 20MHz CP2200 clock, or the 68008 7.5Mhz clock to increment a counter that's always running like the Q68. (I assume that the 7.5Mhz clock is available when using (S)Gold card, and It is always running)

It might be an idea to gate the ticker off the link light so if there is no cable inserted the QL is not slowed by the service routine? Or is that silly?

If the counter stopped when there is no network connection, could cause problems with my driver. Especially during CP2200 initialization when the CP2200 is reset. Also a high speed free running counter might be useful for other purposes.

As for my background service routine, 50 times a second it reads a CP2200 register to see if any packets have arrived, and just exits if there are not any to deal with.

[Derek_Stewart]

Hi,

Could the Network card have a hardware clock on the board to syncrohise the timings.

Or maybe make the Network interface look the same as the Q68 interface, so that the driver could have minimal changes.

[Dave]

From the driver point of view, the ethernet peripheral will work identically* to the Q68 - only slower. I'm going to count the CPU clock, because then the interface will scale well with CPU clock. I'll need to do a little work with the logic analyzer to make sure I get the interrupts right.

The schematic is be easy to produce - the only complexity is that it sits in the CPU socket so there are a lot of restrictions on the layout. The expansion card version will be a lot easier to produce.

* The IO address will be different.