• Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.

Gray NDRV solution!

65a said:
Ok, I started from scratch because things got cluttered, and my OF illiteracy didn't help :). I'm using a ROM with just the Apollo pef, no OF code beyond what is needed for the 9200 emacs.

It turns out AAPL,gray-value is sort of a red herring. In the Apollo_A and Apollo_B nodes, it does set the color for gray screens (so, party on!). but it is not necessary for resolution setting, the Apollo NDRV does that. It is still possible it has an alpha channel and this solves things, but seems less likely to me.

The Apollo NDRV can set all of the eMac resolutions on its own, without a gray screen. There is a big catch which caused some of my confusion. In OS 9, you have to open the monitors control panel, which will show color depth "millions" selected. You can use the arrow keys here, and any change will gray screen. Keep using the arrows, and 256 will work. Then any resolution will work as expected.

So the gray screen, at least on this machine, has to do with not setting modes, but with color depth. Still hacking on this, it's a weird problem.
Click to expand...
So... what's causing the Monitors CP to go to the gray screen for the Thousands option? Is it attempting to use the wrong ndrv at first?
 
Gray screen is used for display color depth transitions so that you don't get weird colors during the transition.
The CLUT/gamma table is turned gray so that all depths show the same gray color.
 
@adespoton it's definitely the correct NDRV. Booting a ROM without it creates a tiny screen with a fixed resolution, and a ghost display (external). With it installed the display is full screen, and the appropriate resolutions and depths are visible. But I'm not sure the state of depth matches the displayed depth...I need to test an image or something, but it doesn't look very dithered at boot, but setting other than 256 causes the screen.

@joevt interesting, then I guess the question is why it doesn't go away. Do you know if that's client or device side? If the former, maybe it can be patched, if the latter, maybe it's expecting a done signal or another call that OS X makes and OS9 doesn't...
 
joevt said:
Your repository is a fork that is behind the upstream fork. I made a pull request to the upstream fork (just ROMs - no resource forks).
Click to expand...
Yeah; I need to commit to my fork first; I've gathered a few now, but have a bunch to go.
So far: New World 1.1, 1.1.2, 1.4, 1.6, 3.0, 3.5, 3.6, (new one: 3.9), 5.2.1, 6.1, 7.5.1, 8.3.1, 8.4, 10.2.1.
This time, they're all OSXZipped with the resource forks attached. It'll take me a while to grab the rest of them, as I don't have the other installers that contain them immediately handy.
Are there any you guys would like sooner rather than later, such as 8.6 through 10.1.1?
https://docs.google.com/spreadsheets/d/1wB2HnysPp63fezUzfgpk0JX_b7bXvmAg6-Dk7QDyKPY/ contains a column identifying where each of the ROMs can be found, so it should be relatively simple to extract the ones you want assuming you've got the CD or image that contains it.
 
65a said:
@joevt interesting, then I guess the question is why it doesn't go away. Do you know if that's client or device side? If the former, maybe it can be patched, if the latter, maybe it's expecting a done signal or another call that OS X makes and OS9 doesn't...
Click to expand...
You can try finding Apple's NDRV sample code "GDX 950717". Search for it on an older Apple Developer CD.
Dev.CD/Development Kits/Hardware/PCI Driver Development Kit /• Samples/Driver Samples/Video samples/GDX 950717

It's missing stuff that exists in more modern NDRV for Mac OS X (EDID/DDC/?) but it may be useful.
https://github.com/joevt/dingusppc/tree/master/thirdparty/Apple/GDX

I'm using it as the base for my DingusVideoPCI driver.
https://github.com/joevt/dingusppc/tree/master/devices/video/ndrv/dingusvideopci
 
@joevt thanks, I will take a look!

I started to tear down the eMac to check for any cap issues or battery bombs before I spend more time on it. The good news is that I can only find one questionable cap, and the battery was not blown, so this project will continue once I clean it and put an SSD into it.

I did some experiments. The two AAPL,gray-values are both used, and have a bitwise relationship. The _A one appears to be subtracted or OR'd with the Parent one. I still think this is sort of a red herring, as messing around to get the last or first bits zero'd or FF didn't seem to help.

Was there a good disassembler for OS 9/OS X? It'd be interesting to see the "client" side of the request.

There's also a "set-depth" OF command I can't figure the syntax of quite yet. I am wondering if I can set the depth in OF and just not touch it from OS9 (after ditching the resolution preferences)
 
It seems that the general assumption in this code is that if you make the screen gray, the subsequent call to program the hardware will fix it.

github.com

dingusppc/thirdparty/Apple/GDX/GraphicsCoreControl.c at 5a6cbe730cf470a7334aa8a2e34541905a82f85d · joevt/dingusppc

An experimental emulator. Contribute to joevt/dingusppc development by creating an account on GitHub.
github.com github.com

I wonder if later versions of OS X drivers didn't need the call to set things to gray anymore, so programming the hardware doesn't touch the gamma table and assumes we know what we are doing when we call the ndrv? Or we are dying somewhere in programming the hardware.
 
65a said:
Was there a good disassembler for OS 9/OS X? It'd be interesting to see the "client" side of the request.
Click to expand...
IDAPro does decent PPC disassembly. If you want something that runs ON OS 9, you're looking for Resourcerer or Jasik's debugger, neither of which does a great job, or the CodeWarrior debugger with the IDE, if you've got symbols.
 
adespoton said:
Yeah; I need to commit to my fork first; I've gathered a few now, but have a bunch to go.
So far: New World 1.1, 1.1.2, 1.4, 1.6, 3.0, 3.5, 3.6, (new one: 3.9), 5.2.1, 6.1, 7.5.1, 8.3.1, 8.4, 10.2.1.
This time, they're all OSXZipped with the resource forks attached. It'll take me a while to grab the rest of them, as I don't have the other installers that contain them immediately handy.
Are there any you guys would like sooner rather than later, such as 8.6 through 10.1.1?
https://docs.google.com/spreadsheets/d/1wB2HnysPp63fezUzfgpk0JX_b7bXvmAg6-Dk7QDyKPY/ contains a column identifying where each of the ROMs can be found, so it should be relatively simple to extract the ones you want assuming you've got the CD or image that contains it.
Click to expand...
My repo's updated now, and a PR is in to sentient06/MacROMan/ -- I'm still missing a few, but found a few new ones while looking for them :)
 
adespoton said:
My repo's updated now, and a PR is in to sentient06/MacROMan/ -- I'm still missing a few, but found a few new ones while looking for them :)
Click to expand...
With the resource fork intact, the tbxi dump command will include in the dump a "SysEnabler" file which may include an optional PEF in some Mac OS ROM versions.
 
I've got the emac back together with things be easier to test back and forth. I think next step is to try patching the pefs in various interesting places and set up a flow so I can easily crash and recover...I replaced the CD drive with a CF card adapter, which should make recovery a bit easier.
 
adespoton said:
IDAPro does decent PPC disassembly. If you want something that runs ON OS 9, you're looking for Resourcerer or Jasik's debugger, neither of which does a great job, or the CodeWarrior debugger with the IDE, if you've got symbols.
Click to expand...

I'll check out those, I think any place where I could debug the calls and returns from the pef might be interesting (I guess this would be the OS 9 kernel calling the address? I don't really understand where the pef lives and gets called, is this kind of like BIOS interrupts? does it just get loaded somewhere and jumped to?), I suspect OS X started doing this differently around 10.3.9, but probably the easiest fix might just be hacking in the pef and trying to understand where we are likely ending up compared to the example pef.
 
In Mac OS 9, the Code Fragment Manager handles PEFs which are shared libraries.

In Mac OS X, there's a PEF loader in IOGraphicsFamily which loads an ndrv into the kernel.
 
joevt said:
In Mac OS 9, the Code Fragment Manager handles PEFs which are shared libraries.

In Mac OS X, there's a PEF loader in IOGraphicsFamily which loads an ndrv into the kernel.
Click to expand...
Is IOGraphicsFamily the only place that loads PEFs via ndrv in OS X? The location seems a bit... specific. After all, the one place we're going to see PEFs needing to be parsed is via the EFI spec (or WINE, but that's not Apple), which explains the ndrv approach, but there's more that needs to be loaded than just graphics hardware references; the PEF headers are used to define the entire UEFI structure aren't they? Although Apple EFI isn't strictly conformant to UEFI, so maybe graphics handling is the one area where extra handling is needed? I have to admit, I'm almost completely in the dark in this area. I jumped from vanilla OF to x86 EFI and never dabbled much in PPC PEF handling.
 
adespoton said:
Is IOGraphicsFamily the only place that loads PEFs via ndrv in OS X? The location seems a bit... specific.
Click to expand...
PEF is not a thing in Mac OS X except for the ndrv for a GPU used in a IONDRVFramebuffer (subclass of IOFramebuffer) kernel extension.
An IONDRVFramebuffer allows most any GPU that works with OS 9 to be usable in Mac OS X without having to create a new driver. New drivers are required for 2D/3D acceleration since that is not included in an ndrv.

adespoton said:
After all, the one place we're going to see PEFs needing to be parsed is via the EFI spec (or WINE, but that's not Apple),
Click to expand...
EFI uses PE which is a Windows format - not the same as PEF.
Classic Mac OS uses PEF (Code Fragment Manager for 68K or PPC) or CODE resources (not Code Fragment Manager).
Mac OS X uses Mach-O.
 
You must log in or register to reply here.
Back
Top