• 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!

6

65a

6502
Over on macos9lives, I was hacking around with my eMac project.

The earliest ndrv is 10.3.8, which is when the fated gray page thing started with OS X drivers being injected into OS 9.

I patched the ROM and got a gray page, as one might expect.

Fiddling around in various parts of `strings`, `ghidra` and `r2`, I realized there were a lot of OF strings in these, including the stupidly obvious `AAPL,gray-value`

I set this property to 0 on the ATI device node, and instead of the gray page, I got a black screen. I tried `ffffffff` and the damn thing worked without a gray page.

I am not sure what this is, but it appears to be mask-like. Something like

`dev /path/to/card; " AAPL,gray-value" property ffffffff encode-int`

should work.

Thanks to @elliotnunn for tbxi-patches and @DarthNvader for the pef discovery!

os9lives thread is here, but not getting a lot of bites there: https://macos9lives.com/smforum/index.php?topic=7683.0
 
No, this is RV351, I think it's too new. This machine (1.42 2005) has a Radeon 9600 unlike the other eMacs which are 9200 (with OS9 support), and the ndrv is from 10.3.8. I had to remove some ATI stuff that was crashing at boot...as far as I know this is the first time this machine has worked with any OS9 ndrv.

Most of the OS9 unsupported ROMs use a <10.3.8 NDRV because the later ones have this "gray page" bug. The above is a somewhat successful workaround for it, enabling later ndrvs to be used to boot to desktop at native resolution. This won't make newer cards work with older drivers (I think, unless ATI did ship 9600/rv351 drivers in the updates and we can patch the ID to something they are looking for, because by default they do not work).

However, resolution may be native, but changing it will return the gray page (disregarding the OF hack above) until the preferences are removed (not sure which one yet) that try to change resolution every boot. Probably some more patching and reverse engineering of the ndrv is needed.
 
There are some other OF properties that aren't set in the OF tree but the ndrvs can read, there may be other lucrative hacks there for cards that do have full os9 support.
 
There's probably zero chance you can get acceleration in Mac OS 9 since you're using a GPU meant for Mac OS X.

Without the "ATY,Apollo" ndrv, Mac OS 9 should be able to use the "Non-existent hardware" ndrv from the "Mac OS ROM" file. It only requires Open Firmware to enable the graphics and set some properties but that means it can't support resolution or color depth changes.

Some of us need more info to catch up with where you are.

Regarding the patches, it appears you have a "Mac OS ROM" file having version 9.2.1, and applied some changes using tbxi build?
https://github.com/elliotnunn/tbxi
Do you have more info about the patches?

Using tbxi dump with your "Mac OS ROM" file and the original, we can compare the differences:
  • BootScript has added Open Firmware Forth code to make your newer eMac that supports only Mac OS X look like the older eMac that supports Mac OS 9. It sets some CPU and Mac model properties and a `prim-info` property for power management.
  • "ATY,Apollo-1.0.1f77" pef is added.
  • "ATALoad" DRVR has additional code.
  • "Nanokernel" has some changes and additional code.
  • Added "SysEnabler" file with PEF for NQD (New QuickDraw) Cursor stuff and many resources for other stuff.
The Mac OS ROM files in the MacROMan GitHub repository are missing resource forks so I can't compare those.
 
Yeah, not hoping for acceleration. I'm worried this hack might be incorrect though, details later.

The ROM is effectively similar to the modified ones for a mini G4.

I'm running a tbxi-patcher that is modified from the G4 mini one. I think my source ROM is stock 9.2, but it may be the universal one which is prepatched. I've patched https://github.com/elliotnunn/tbxi-patches somewhat for the "education" ATI emac already using macmini.py as a template.

There are some small changes for the power manager etc, sound in the prim-info property. The pef/ndrv name for those emacs are ATY,Merlin, but otherwise that worked. The machine which this was for died a long time ago of flyback and capacitor disease, so I don't have it to test with anymore :(


Lately I acquired a 1.42ghz eMac, which seems to be nearly identical except it has the Radeon 9600. I further modified the script to install the pef for ATY,Apollo, but didn't use the pef patching from macmini.py, This gray screened on every boot.

Most recent version (not uploaded) adds another of patch to set the AAPL,gray-value in /pci/ApolloParent. This does let me get to desktop and the screen is at least stretched edge to edge. It would then require a force quit to get out of some ATI application/extension thing that hanged, until I removed the ATI accelerator extension.

Changing resolution brings back the gray screen, so this isn't very good yet. It is possible that it doesn't work, but we're now avoiding any calls to the ndrv, which "works" but doesn't actually work. It's also possible that some calls to the ndrv are returning extra data or expecting additional parameters.

There are apparently two "AAPL,gray-screen" OF values, one in ApolloParent, the other(s) in Apollo_A and Apollo_B (the outputs). The latter can also be set, and it changes the color of the gray screen on resolution change, but FFFFFFFF doesn't make it go away. I haven't hacked at that more. So this may require further pef hacking, or it may just be using the OF resolution without going gray.
 
Seems like a solution would require a lot of hacking. Maybe convert the ATY,Apollo PEF into a shared library that doesn't match against the PCI device, create a wrapper NDRV that loads and calls the ATY,Apollo PEF and logs all the calls.
 
You fixed it? Congratulations! Hopefully that means we can use the later OS X ndrvs on the mini, which might fix the problems that some people have with 1080p DVI screens.
 
joevt said:
The Mac OS ROM files in the MacROMan GitHub repository are missing resource forks so I can't compare those.
Click to expand...
Oops. I thought I'd fixed that. I'll have to go back and find / re-assemble everything, as binhex or macbinary at some point. I know I've still got the resource forks for at least some of the dumps.
 
adespoton said:
Oops. I thought I'd fixed that. I'll have to go back and find / re-assemble everything, as binhex or macbinary at some point. I know I've still got the resource forks for at least some of the dumps.
Click to expand...
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).
 
@elliotnunn I don't think so, not completely. I can get it to partially use the ndrv and the desktop is in millions of colors, but any changes to the display work, but display the gray screen as well (the CRT and cursor resolution clearly indicate a resolution change). I believe the ndrv is actively drawing this gray box, because I can change its color with the AAPL,gray-value setting in the Apollo_A and Apollo_B nodes. There's more work to do, but I think it involves find the place in the pef where it draws the box (probably for OS X laziness reasons, such as non-flashing boot up, and somehow OS X tells it to stop doing that) and nop it out. I'll keep hacking on this...it seems like the place to look in the pef is near where either of the lookups happen for AAPL,gray-value. I should also note my OF above is _invalid_, not sure if that is helping here.

I do have all the files for the non-1.42 emac around still, basically just had to do the rockhopper patch on ATY,merlin, and guess the pmic value from other examples, change the compatibles, etc.
 
@joevt have "ffffffff encode-int" assuming we're describing an RGBA value (in some order). I think encode-int doesn't like that value (My forth is not super strong, maybe there's a better way to set this value and encode-int is the wrong command...I saw encode-bytes but didn't figure out the syntax), reading back .properties gives me various erroneous values/errors. That being said, that is the value I used successfully in ApolloParent.
 
65a said:
@joevt have "ffffffff encode-int" assuming we're describing an RGBA value (in some order). I think encode-int doesn't like that value (My forth is not super strong, maybe there's a better way to set this value and encode-int is the wrong command...I saw encode-bytes but didn't figure out the syntax), reading back .properties gives me various erroneous values/errors. That being said, that is the value I used successfully in ApolloParent.
Click to expand...
Open Firmware does not use semi-colon to separate commands.

You have to encode the property data before you finally create the property. Like, you need to place numbers on the stack before you can use an arithmetic operator:
1 2 + . result:3

ffffffff should work. -1 is the same value.
This should work:
dev /path/to/card -1 encode-int " AAPL,gray-value" property

encode-bytes requires an address and length like this:
here -2 , 4 encode-bytes " myprop" property
It adds a property with bytes -2 = fffffffe. It uses 4 bytes of dictionary space outside the dictionary space used for the property.
It's not as simple as encode-int if you just want to encode a single 4 byte number.

Alternative method using encode-bytes (still not as good as encode-int):
" "(fffffffd)" encode-bytes " myprop2" property
It adds a property with bytes fffffffd = -3. It uses a temporary string buffer for the source of the bytes which doesn't use dictionary space.
 
Sorry about the semicolons, short handing it and too much C/C++/bash. I have:

Code: 
" /pci/ATY,ApolloParent" select-dev
    " AAPL,gray-value" property FFFFFFFF encode-int
device-end

I'll play with those other options when I get a chance.

in the actual ROM. I haven't spent too much more time on this yet, but if I manually do that with fcode-debug on, and type .properties, it prints an error instead of the gray-value, which I assumed was due to an invalid encoding/type. It is possible that rather than actually setting the value, whatever that actually results in is misread by the pef and results in the partial improvement because it hits an edge case in the gray-box-drawing-code.

Before the patch, I cannot reach desktop without the gray screen of death.

So with that patch, I can:
1. See the display as "eMac" in controlstrip
2. See the appropriate resolutions in the menu
3. Change eMac geometry (though this works without the ndrv, because of the emac revision OF patch)

I cannot:
1. Actually change the resolution, without a full screen color appearing, which can be controlled by the gray-value property of the child nodes.

When the latter happens, the CRT does resize, as does the cursor. This is readily apparent because the horizontal alignment is different between resolutions and would need a geometry change in the control panel (haven't looked at the analog board yet). Clicking still works.

There are some other magic strings that seem interesting, "needsFullInit" and "ATY,Connected" the latter of which starts appearing around 10.3.8.
There is also the very interesting string "mvnoscnvbsttbrithuetsattflkwasr" which appears in many of the later drivers and I cannot make sense of :)
 
Like I said before,
Code: 
" AAPL,gray-value" property FFFFFFFF encode-int
is very wrong.

It should be:
Code: 
FFFFFFFF encode-int " AAPL,gray-value" property
 
Aha, that explains the errors. So if that is working, it's because the pef is responding to a garbage value. The erroneous forth does produce a property (if I run that by hand I see it there), but the value is undefined or something?
 
65a said:
Aha, that explains the errors. So if that is working, it's because the pef is responding to a garbage value. The erroneous forth does produce a property (if I run that by hand I see it there), but the value is undefined or something?
Click to expand...
The property will have an incorrect address or length which could cause an exception.
Code: 
0 > .properties 
AAPL,gray-value         DEFAULT CATCH!, code=FFF00300 
 ok
 
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.
 
You must log in or register to reply here.
Back
Top