Mac OS 9 Discussion > Development & Programming
Debugging ATI drivers for Mac Mini
ssp3:
Thanks, joevt, for your insight.
What do you think, what kind of compression is used here? Any idea how to decompress it, manipulate and then compress it back? I'm not a programmer, so I'm a bit lost here.
As I said before, f100 driver hangs the machine. At first I thought that since it was written for OSX, some symbols (or whatever they're called in OS9) might be missing, but no, everything seems to be present. Most imports are from Carbon Lib. One interesting export caught my attention, though - device description. Maybe that's the place to start digging?
Anyone want to join?
joevt:
The compression is exactly defined by the PEF opcodes. I suppose PEF Viewer being a viewer means it doesn't have an option to edit? The only method I tried was to convert the disassembly of a PEF to an assembly file to be compiled by MPW or CodeWarrior PowerPC assembler into a new PEF.
I used Jasik's The Debugger for disassembly and used a script to convert that to assembly. I also used DumpPEF and a script to convert that to assembly. I don't remember how well they work. Jasik's the Debugger produces inconsistent results between the two formats it creates: .list and .asm. list includes hex data and offsets for each line so it might be more useful since you can check the offsets for all the labels to find the bugs.
Other options I haven't tried:
NationalSecurityAgency/ghidra
DBJ314/dePEF-and-disarm
The MPW DumpPEF command calls the compressed data "pidata"
The pidata opcodes are listed in IOGraphics-305.14/IONDRVSupport/IOPEFInternals.h
--- Code: --- kPEFPkDataZero = 0, /* Zero fill "count" bytes. */
kPEFPkDataBlock = 1, /* Block copy "count" bytes. */
kPEFPkDataRepeat = 2, /* Repeat "count" bytes "count2"+1 times. */
kPEFPkDataRepeatBlock = 3, /* Interleaved repeated and unique data. */
kPEFPkDataRepeatZero = 4 /* Interleaved zero and unique data. */
--- End code ---
To be Mac OS X compatible, an ndrv must import only from a specific set of libraries. CarbonLib is definitely not one of them. Does it say CarbonLib somewhere in the ndrv? Maybe you could post a link to the ndrv so we know what you're looking at.
See IOGraphics-305.14/IONDRVSupport/IONDRVLibraries.cpp for the list of libraries and functions from each library.
Drivers should only use: PCILib, VideoServicesLib, NameRegistryLib, and DriverServicesLib
Apple also allowed some functions from InterfaceLib and PrivateInterfaceLib to make some of its ndrv's compatible with OS X.
Actually, IOGraphics-305.14 is for 10.5.8. If you look at IOGraphics-179.2.1 (for 10.4.11), then you see there's also some functions from the AtiUtils library which is used by the Beige G3's GPU.
XPostFacto may have some kexts that define some other libraries and functions to allow some other ndrv's to be usable. I added some libraries and functions to make my modified sixty6 ndrv usable (for video out of Power Mac 8600).
I'm not sure it's possible to create a ndrv that is compatible with OS X but not Mac OS 9?
An ndrv is suppose to have two exports:
TheDriverDescription - data
DoDriverIO - code
https://developer.apple.com/library/archive/documentation/Hardware/DeviceManagers/pci_srvcs/pci_cards_drivers/Designing_PCI_Cards_Drivers.pdf
ssp3:
Thanks for your input, joevt!
--- Quote from: joevt on April 30, 2024, 11:12:17 PM ---Maybe you could post a link to the ndrv so we know what you're looking at.
--- End quote ---
First attachment - drivers (extensions) for OS9 made out of OSX ndrvs. f63 is working in OS9, f100 is not.
Second attachment - OSX ndrvs f63 and f100 as extracted from OSX parts by ELN. From his GitHub repo.
Third attachment - PEF Viewer for OSX that I made to work standalone. Works on PPC and Intel under Rosetta.
Fourth attachment - asm and lst files of both PEFs, f63 and f100.
joevt:
What disassembler did you use? IDA? Which version?
The assembly listings show the imported libraries and functions as expected:
VideoServicesLib, NameRegistryLib, PCILib, DriverServicesLib
No unsupported libraries appear to be included. version f100 adds AbsoluteDeltaToDuration but that's not a problem since CIncludes shows that API as going back to Mac OS 8.6.
I don't see a device description, just "TheDriverDescription" as expected. The only difference in TheDriverDescription is the version number changed from 63 to 100.
Comparing the assembly listings would require renaming all the unnamed labels since they have different offsets or positions between version f63 and f100. In MPW you could create scripted menu items with command key short cuts to do the renaming of each label for you. It would work like this: select the label on the left and the label on the right. Choose a new common name for the labels. Have it verify that the new name is unused in both files, then have it rename all occurrences in the old version and the new version and re-compare. I did that with Open Firmware drivers. Open Firmware is different since the labels are order based (1,2,3,4...), rather than offset based, so that when renaming a label in Open Firmware, you could have it automatically rename all labels after that by incrementing there order number that is included in the label name thus greatly reducing the number of renames required.
Is there a modern utility to do a similar compare/rename? Does IDA have a compare binaries option? Can you change the assembly format to use order based names instead of offset based names? I suppose one could easily create a script to rename offset based labels as order based labels.
joevt:
Did you say why you wanted to use a version other than f63 with OS 9?
What does "v9 ROM file for Mini" mean?
Is there an ndrv in Open Firmware? If so, what if you remove it before booting OS 9? Or replace it with a newer version before booting OS 9?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version