On Nov 10, 2007, at 3:21 PM, nubus-pmac-users-request@lists.sourceforge.net wrote:





Alex Kenis wrote:
Anyway, if anyone who has worked on this before can point me to the
missing info that they would need for the sound chip, etc... let me know
because I will be probing the hardware calls with a decompiler over the
next few days, and it would be easier to know what to look for rather
than just looking for trends, which is my current plan.

AFAIK nobody did anything serious with the Singer sound chip yet. So
you're on your own here. I can provide some test drivers, based on any
findings about the chip...

The floppy controller is supposed to be a SWIM-II chip.
It has been discussed on the list some time ago:
http://article.gmane.org/gmane.linux.ports.ppc.nubus-pmac.users/232
http://article.gmane.org/gmane.linux.ports.ppc.nubus-pmac.users/239

Cheers,

  Florian




If you have any work to send over, that would be great.

I have made a little progress... but not much.  I copied my 1400's ROM into RAM and used a few proggies to scope it out.  The basic low-level sound control and video drivers are of course in the ROM, and I found their base addresses as well as the base addresses of most of the other functions..  I had not looked into the floppy too much, but that is a ROM driver too...BUT... if I recall, Apple replaced the ROM based driver for the 1400 with an extension because of an error in the original driver, so maybe I can look at that to see if it is a stand-alone, or if it is calling a bunch of ROM routines with some patches.

Also, it most assuredly does not use true DMA for the audio... originally i thought originally that perhaps the Whitney chip opened a channel to the PBX mem controller that bypassed it by something like the Texas Instrument's mailbox register interrupt like a DSP does, or something like that, but I am not sure.  The PNX chip just seems to do it's job without OS interference , but i think that I stumbled upon the address for the buffering audio... i only hope that it is not tied in too closely with MacOS' memory management... and I found a few snippits of a failed HURD port from a few years back that have some relevant info and reference a vitual DMA address for PPC nubus performas and powerbooks... or something like that, so I'll be looking through those. I thought that maybe the ASCO chip had some kind of onboard buffer, but apparently it does not from the looks of the data sheets.  I am going to tinker with the mklinux and 68k code a bit and see if I can make anything happen, and see if their ECSC chip driver is any good, and compare the format to the 68k 2.6 kernel CSC driver.

I also soured the circuit board for a floppy controller, but only found the controller for the floppy's power supply and the logic chip that switches off the media bay's power during the MacOS sleep-swapping of the bay module, but the apple notes state:

"The floppy disk drive for the PowerBook 1400 computer is a 1.4 MB drive identical to those in previous PowerBook computers. The floppy disk controller is a standard 82078 IC. The floppy disk drive for the PowerBook 1400 computer has a special signal, DISK_IN_PLACE, that indicates to the driver software whether a disk is present in the drive."

From what I can tell, it is on pin 11 of the floppy drive connector, which sends a low signal (I assume that is just a hardware voltage signal, and no software control is needed)  to the Babon IC to let it know if it should look for a drive and (from Apple tech notes) provide an interrupt to let the system software send a power on signal through the power manager (I assume the Motorola SC428006PV) to switch on media bay voltage, and to scan for a drive.  IF all of that is in order, then I assume that is where the software takes over, and if the IC is really a standard 82078 (which is a wildly popular Intel chip) then the I/O windows need to be identified, and then a standard C language driver (as is already in the 2.6 tree) can be used for the chip running in non-DMA mode (nodma or "virtual DMA for Intel
" to buffer into virtual memory instead of DMA) , and (maybe) forget about the Apple SWIM stuff:  

http://www.intel.com/design/archives/periphrl/docs/29047403.pdf  

and here is Qemu's 82078 emulator:

 http://src.vmindex.org/xen_3.0.4/xref/src/tools/ioemu/hw/fdc.c  

The 82078 support has always been a bit twitchy though.  Alan Cox did much of the floppy work, so there is probably a ton of info under a google search with his name.

On the MacOS side, I saw when scoping the ROM that their general .Sony driver is used on the PB, and i believe that the vMac and SheepShaver people have done C rewrites of them, and have the code available, although it uses the ROM dumper to move the toolbox into memory space and then calls it as needed within MacOS, so I am not sure that is useful.  ARDI executer on the other hand, i think they ditched the ROM idea and just re-created the macintosh toolbox, but I have never seen their code.