[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: pcmcia ethernet card support for m68k?



Hi Finn,

On 12/08/20 12:45 PM, Finn Thain wrote:
On Wed, 12 Aug 2020, Michael Schmitz wrote:

Depends on the interrupt priority levels - if the SCC can preempt other
interrupt handlers, and you do nothing but acknowledge the interrupt and
copy bytes to a buffer, this might be worth a try.
Is there overhead in monitoring packets for node addresses? If so, any
node on the network would consume CPU of every other node whenever it
transmits... if true, it begs for IOP offload (or DMA).

As far as I recall, the SCC can be programmed to only respond to a specific node address in synchronous mode. Packets destined to other nodes are just passed through.

But it's over 20 years since I last looked at the SCC databook, so I may be mistaken. My comments were based on that above assumption.


Protocol handling and moving buffer data to network buffers would be
left to a task queue, to run when a packet has been fully received.

Today's kernels are a lot smarter with locks than 20 years ago when this
would have been impossible.

How large are the data packets involved? Is there a pseudo-DMA address
window for the SCC data port to used optimized access (moveml)? Does SCC
access force a bus delay, or can the SCC be accessed at full rate?

Good questions. But I'm not going to dive into leaked source code or
disassembled drivers to find answers. I might dig out the relevant books
and tech notes though.

I didn't expect you to trawl through disassembly or leaked code - I just thought someone might remember.

The bit about bus delay should be possible to figure out from timing access to the SCC data port and compare to RAM access. That might already decide the issue.

(and no, not suggesting you do that, either ... Just in case someone feels like a little kernel hacking for fun, if not profit)

Cheers,

    Michael



Reply to: