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

Re: pcmcia ethernet card support for m68k?



On Wed, Aug 12, 2020 at 01:25:16PM +1200, Michael Schmitz wrote:
> 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.

Yes, I just looked at the SCC/ESCC manual and there is definitely an
address search function in SDLC mode. It seems like it should work. I
have to imagine Apple made sure it did. I've seen too many large node
count LocalTalk networks to believe anything else.

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

I think that sort of logic was restricted to special PDMA windows or
interfaces explicitly put into PDMA mode (like SCSI DMA on the IIfx).
It would still have to be tested to be sure.

We've certainly disassembled other parts of the code to do stuff. I
remember spending hours in MacsBug disassembling ROM code years ago.
That's how we confirmed some details on the IIfx hardware.

	Brad Boyer
	flar@allandria.com


Reply to: