TO DO, was Re: localtalk, pcmcia etc.
On Fri, 14 Aug 2020, Brad Boyer wrote:
> > 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 suspect that the on-board video hardware is under-performing in Linux,
especially on some Quadras. And Linux/mac68k also lacks multiple display
support.
Reverse engineering NuBus cards is another story. ISTR that NetBSD made
some progress there. But it's not high on my list of priorities because
there's any number of different cards and no way of knowing which ones are
still around.
> 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.
>
That seems out-of-scope for the Linux/mac68k project (?)
> 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.
I think SCC IOP bypass is enabled in PRAM, which means we can just leave
the ROM to manage that (or MacOS, if the user wants MacOS to boot before
Linux). And if you succeed in reviving the swim_iop driver, there would be
no need to manage the SWIM/ADB IOP bypass either, right?
> However, that also means finding the resources in the ROM that contain
> the kernel and device drivers for the IOP.
That could be useful if MacOS carries firmware updates to fix bugs in the
IOP kernels and drivers stored in the ROM. End users could extract those
resources from MacOS for use with the Linux firmware loader. I wonder
whether such bugs exist (?)
Reply to: