Re: localtalk, was Re: pcmcia ethernet card support for m68k?
On Fri, Aug 14, 2020 at 08:43:00AM +1000, Finn Thain wrote:
> On Wed, 12 Aug 2020, Brad Boyer wrote:
> >
> > 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.
I think most if not all of the PowerMac models have real DMA engines
anyway. That might avoid the problem entirely. There's already some
code for DBDMA on PCI PowerMacs in pmac_zilog, but it is apparently
unfinished. At least some of the NuBus PowerMacs have a DMA engine,
but with less capability.
> > 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).
It's worth looking, but Apple must have had a way around that.
> 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).
That's probably true. We have so much on the list already. I know there
were several other things I wanted to check out first. I have a wide
variety of video cards with various accelerator capabilities, plus a
couple NuBus DMA cards that should allow doing accelerated video even
on the early video cards without any extra logic beyond the basics. I
had hoped to work on the ADB drivers as well. It would be great to get
full ADB support working on the iMate which could potentially be used
to have real ADB support on anything with a USB port. The company that
made it has given hardware information for some of their other
peripherals, but I haven't tried asking for iMate documentation.
I was also hoping to get some enhancements for the IOP core to fully
re-initialize the IOP kernel which should allow us to manage the
bypass mode directly. However, that also means finding the resources
in the ROM that contain the kernel and device drivers for the IOP. I
don't fancy writing a new IOP kernel from scratch. I was working on
updating the swim_iop driver, but I still haven't finished fixing it
for the new block device layer.
Brad Boyer
flar@allandria.com
Reply to: