Re: TO DO, was Re: localtalk, pcmcia etc.
On Sat, Aug 15, 2020 at 10:52:08AM +1000, Finn Thain wrote:
> On Fri, 14 Aug 2020, Brad Boyer wrote:
> >
> > 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.
Multiple display support shouldn't be too difficult, but I think we
should do that by having real video drivers rather than just using
macfb. It would be similar to the way offb works for PCI PowerMacs,
where there is both a generic driver and individual drivers for
each of the onboard chips as well as the various common PCI cards.
> 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.
It's worth writing drivers for the official Apple cards if nothing else.
However, they're all pretty lacking in capability. But it would make it
easy to throw in two or three Toby cards and have multiple displays.
> > 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 (?)
True, but I was still planning on looking into it. I have tons of
ADB input devices (keyboards, mice, trackballs, joysticks, gamepads,
drawing tablets, and even a barcode scanner). I was hoping to get some
of them beyond the basic keyboard and mouse support working. Having
them on a regular PC would be amusing.
> > 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?
Yes, but that's just because it's the ROM that loads the initial kernel
and drivers to be able to check for keyboard input during boot or to be
able to boot from a floppy. I suppose we can just tell people to manage
the serial switch setting in MacOS, but that seems clumsy. I'm pretty
sure the MacOS reloads it all during boot.
> > 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 (?)
I wouldn't be surprised. It's also quite likely that the Q900/Q950 ROM
has a newer version of them than the IIfx. I haven't checked. It might
be easier to find them in the system software than in the ROM. I know
where they should be and how to look for them there. There's a unique
resource type for them, according to the information I have.
Brad Boyer
flar@allandria.com
Reply to: