Re: localtalk, was Re: pcmcia ethernet card support for m68k?
On Wed, 12 Aug 2020, Brad Boyer wrote:
> On Thu, Aug 13, 2020 at 11:51:57AM +1000, Finn Thain wrote:
> > This 26 ms interval will cause missed timer interrupts and system
> > clock drift, unless the timer interrupt was polled too. (We could
> > probably poll all of the VIA 1 interrupt sources for the duration of
> > the packet, but not with Egret hardware because of delays in that
> > interrupt handler.)
>
> That will make for a really messy driver, but it could be done with some
> careful thought. It could also be made conditional on m68k so that a ppc
> based system wouldn't need it, since it can figure out how much real
> time passed between timer interrupts with the timebase.
>
I would imagine that this 26 ms would be spent in interrupt context in the
pmac_zilog driver. This may or may not impact the timekeeping on
powermacs. I don't know how interrupt priorities work on those platforms.
> > Another consideration is raised in tech note TB 570. It says, "system
> > services like AppleTalk require that interrupts not be disabled for
> > much more than 1/1000th of a second usually. This means if you are
> > doing something large during your interrupt routine (when all
> > interrupts may be turned off), you could delay the AppleTalk interrupt
> > so long that data gets lost."
> >
> > I think this is quite feasible for the majority of systems. A minority
> > might drop some packets depending on hardware configuration, etc.
>
> It sounds like the first step might be to audit all the other common
> drivers to see which ones are disabling interrupts too long. I know we
> do quite a bit of that.
>
SCSI transfers happen either at IPL 2 or IPL 7. These days we use PDMA
everywhere except for PSC machines (which should be using DMA but Linux
drivers don't support it) and certain rare SCSI targets which can't keep
up. Limiting scatter/gather segments to 1024 B should meet the timing
constraint.
It's possible that the floppy driver disables interrupts for too long. But
apart from that, 1 ms seems quite feasible (at least until multiple
controllers become busy).
BTW, feasibility is one thing but actually implementing Localtalk support
is another. DMA support for PSC machines and framebuffer acceleration are
probably more important features than Localtalk. And I see debugging as
more important than adding features. So more volunteers are needed (as
always).
Reply to: