Taking another shot at onboard audio on a Mac Mini G4?

[biggieshellz]

I always had Macs as a kid.  I used to hang out on the 68kMLA forum when I was in high school.  Now I do Linux driver development for 5G telecommunications SoCs.  I recently bought a Mac Mini G4 to show my kids some of what I used to play with (after a clamshell iBook started to fall apart faster than I could fix it).  It’s amazing what folks here have done to get Mac OS 9 to run on this hardware.

Anyways, it’s frustrating AF that onboard audio does not work quite right with Mac OS 9, and I was wondering if this is something I could fix.

Resources I’ve found on this:

https://github.com/torvalds/linux/tree/master/sound/aoa — this is the Linux kernel driver for this sound hardware (Toonie in our case).  It looks like there is no hardware support for setting the volume — it’s just a DAC — so any system-wide volume control would have to take place in software.

https://vintageapple.org/inside_r/pdf/Sound_1994.pdf — chapter 6 shows how to build an audio component, and what capabilities and callbacks are exposed through one.

http://macos9lives.com/smforum/index.php/topic,4682.msg36250.html — this shows which built-in component is used for the Mac Mini’s audio, and gives some basic information on how to find that within the System file.

So as far as a basic plan of attack, here’s what I’m thinking:

(1) Figure out how to extract the existing ‘awgc’ audio component from the Mac OS 9.2.2 system file (would https://github.com/fuzziqersoftware/resource_dasm be the right way to do this?)

(2) Reverse-engineer it to figure out what’s going on currently.  (Would Ghidra work, or do people have a tool they like better for classic Mac OS stuff?)

(3) Modify the audio component and put it back in the system file.

Would this be a sane way to go about it?  Has anyone else worked on this and has more information to contribute?

Thanks!

[ssp3]

Re. awgc No need to go to dasm etc. - ResEdit will do. It's in a thng resource. Actually, there are 3 items with awgc in them. But, doesn't the sound manager extension have to be modified too?
Another useful tool for fixing things is Resorcerer.

* Pics are from 9.0.4

[biggieshellz]

Thanks, that's helpful.  So how do I map from the 'thng' resource to the code that implements the component?  Is there an ID or something that I can follow?

[ssp3]

The IDs are right in front of you, in all 3 pics. -20493, -20490, -20489, -16563 etc. 
How are they mapped I don't know. Just poke around 'til you find out. Or read the manual.
Or maybe someone more knowledgable than me will chime in.

[smilesdavis]

while we are at it, implement Steinberg M.ROS into mac os 9

[biggieshellz]

OK, I actually opened up the System file in Resorcerer, and for thng -20489, it says "the template for thng -20489 describes more data than has actually been found in this resource".  And it's listed as [PACK 63,23].  Under the PACK resources in the System file, I don't see 63 or 23.  Does anyone know what this refers to or how to find it?

[IIO]

(Would Ghidra work, or do people have a tool they like better for classic Mac OS stuff?)

has no PPC support & is most likely a total overkill here.

a simple debugger like macsbug will probably do. it is an INIT and will end up in your /system folder/extensions, and to disable it you just remove it and reboot.

but let´s first see if resedit and browsing the ASCII representation is enough to fix it.

Does anyone know what this refers to or how to find it?

from the wording it only means that the template could visually show you more than what is there.

i have never seen this message and have no idea if it can be safely ignored.

you might also see this message when the resource is wrong or empty or a resource´s  content or format uses a wrong resource class name, but who knows.

[robespierre]

The notes in Resorcerer about "[PACK 63,23]" are letting you know that the resource's ID (-20489) is in a special range reserved for "owned" resources. This is explained on page 16 of the Resorcerer manual, and on page 109 of Inside Macintosh Volume I.

Except that, the ID -20489 is not in that range as the books define it. [PACK 63,23] should be ID -4105. I would not put too much importance on this PACK business, it looks completely spurious. (PACK resources are used by the Package Manager for collections of common routines that are loaded on demand by _Packn traps. For example, the Binary/Decimal Conversion Package or the Transcendental Functions package. There doesn't seem to be any _Pack63 trap.)

[ssp3]

Also worth noting is that, if you are going to go at Sound Manager extension or anything else that has PPC code in data fork, you will need some tool that can pull it apart in a meaningful way.

[biggieshellz]

OK, so for -20489, there's an 'nift' resource of the same number that's a PEF file that I can look at in Ghidra.  There's also an nlib -20919 that's I2SAudioPlugin that looks more promising.  FWIW, Ghidra seems to do OK with PEF files and PowerPC assembly.

For those of you who suggested MacsBug, I have a few questions.  (1) is it possible to use MacsBug early enough in the boot flow to step through when one of these sound components gets loaded?  And (2) how do I go about finding where the sound component was loaded so I can set a breakpoint in one of the handler functions?  For instance, let's say I wanted to set a breakpoint that would be hit when an application plays a sound, or (on my clamshell iBook where this works) when I mute the sound or change the volume.  Can I go off of a symbol name, for instance?  Or are components loaded at a particular location in memory?

[ssp3]

I think you dropped into MacsBug by holding control key at the start-up, but I might be mistaken.
You can also try the attached extensions, but they are pretty old, so there is no guarantee that they will work on 9.2.2


http://macos9lives.com/smforum/index.php?topic=3565.0

https://wiki.preterhuman.net/Tips_and_Tricks_for_MacsBug

MacsBug Reference and Debugging Guide:
https://manualzz.com/download/44810039

https://vintageapple.org/macbooks/pdf/Debugging_Macintosh_Software_with_MacsBug_1991.pdf

Nice collection of books:
https://vintageapple.org/macprogramming/

The attached document is either in old Word 5 (?) format or rich text.

[biggieshellz]

A bit more progress on this.

I've attached two photos.  The first one is the audio GPIOs -- I will cross-correlate these with the Linux driver to see which is which.  The second one is the I2S sound.

Edit: the hex in the audio GPIOs is ASCII, and says "headphone-detect", "headphone-mute", and "amp-mute", respectively.

Also, I'm able to use ELN's AudExtR from this forum (Sound Manager with the code moved to the resource fork) in combination with MacsBug and BreakBefore to enter the debugger as the extension is loaded.  However, it looks like there is a bunch of relocation that's done before any of the code is executed.  Does anyone know how to figure out where the individual resources within the extension will be loaded, so I can set breakpoints?

[biggieshellz]

A bit more progress on this.  I've been using Ghidra to look at the individual drivers within AudExtR.  I ran into an issue opening a few of the resources, and ended up submitting a fix to Ghidra for opening PEF files: https://github.com/NationalSecurityAgency/ghidra/pull/5178

The trick to using Ghidra for Mac OS 9 PPC is this.  Use https://github.com/fuzziqersoftware/resource_dasm to split out the resources.  Then drag them into the Ghidra project and pick the 32-bit PowerPC for Mac OS X option.  What this does is tell Ghidra that r2 (which always points to the TOC) will never change.  Then, from the Register Manager window, pick r2, and double-click the first mapping and set it to apply everywhere, from addresses 0x0 to 0xffffffff.  Then re-analyze.  This allows Ghidra to figure out the strings.

As far as the calling convention and MacsBug, page 1-43 of https://vintageapple.org/inside_r/pdf/PPC_System_Software_1994.pdf is super helpful.  The parameters are passed through registers, and for pointer parameters, you can view memory at those addresses to see what was passed in or out.

[teroyk]

MacNosy and The Debugger might be useful tools for you:
http://www.jasik.com/index.html
Programmer visited this forum some years ago:
http://macos9lives.com/smforum/index.php/topic,3565.msg45312.html#msg45312

[biggieshellz]

MacNosy and The Debugger might be useful tools for you:
http://www.jasik.com/index.html
Programmer visited this forum some years ago:
http://macos9lives.com/smforum/index.php/topic,3565.msg45312.html#msg45312

I'd love to try it, but $100 seems really steep -- that's more than I paid for the Mac Mini!  And the note from macnosy says "The only lost feature may be the ability to debug INITs," which is what I'm trying to do.

[ssp3]

You've mentioned in your first post that you work for some commercial(?) entity. Don't they have IDA in their toolbox? It deals with Mac's PPC code in data fork quite nicely.

[biggieshellz]

You've mentioned in your first post that you work for some commercial(?) entity. Don't they have IDA in their toolbox? It deals with Mac's PPC code in data fork quite nicely.

To contribute to own-time open source, I had to sign a form that says I'm not allowed to use company resources (even my email address) for it.  And anyway, only one team has access to that tool, and I'd have to follow up with them to get access to the license server and make sure I'm not using the licenses at the same time they need it.

[ssp3]

There are official Win/Mac free or demo versions available. Not sure about Linux, though.

[biggieshellz]

As far as IDA, the free versions only support x64/x86.  The home version, which does support PowerPC, is $200.  And Ghidra seems to be working fine for my purposes anyway.

Does anyone happen to have source code for any Mac OS 9 audio component driver, just so I would have a framework to hack something together rather than modifying an existing driver?

[rvense]

I'd imagine Apple themselves might have published something like that, but I don't know which SDK exactly to go looking in.