Gray NDRV solution!

[joevt]

Minor update; added some missing samples, moved 4 that ended up in the wrong location.

You should rebase your fork to the current upstream master before doing a pull request.
You should use interactive rebase, then fixup to combine multiple related commits into a single commit to clean things up.
You should remove the original .rom files after converting them to .zip.
You should look at all the fixes I did in my fork to see if anything can be cleaned up in your fork. For example, there are many duplicate New World ROMs, such as version 9.0.1.
I've chosen to use macbinary instead of zip because the zip format might be proprietary to macOS and the ditto command or the Finder "Compress..." command that creates zip archives is non-deterministic - doesn't produce the same file twice.
Also, git is able to see file transforms between normal file and macbinary file even if the file is moved and renamed because macbinary is not a compressed file format and git can therefore see the normal file contents inside the macbinary container.

I combined all your commits into a single commit in my fork:
https://github.com/joevt/MacROMan/c...5076387938f6dbe0dab767da8f0ab352fd90a72f8c3e8

 

[adespoton]

You should rebase your fork to the current upstream master before doing a pull request.
You should use interactive rebase, then fixup to combine multiple related commits into a single commit to clean things up.
You should remove the original .rom files after converting them to .zip.
You should look at all the fixes I did in my fork to see if anything can be cleaned up in your fork. For example, there are many duplicate New World ROMs, such as version 9.0.1.
I've chosen to use macbinary instead of zip because the zip format might be proprietary to macOS and the ditto command or the Finder "Compress..." command that creates zip archives is non-deterministic - doesn't produce the same file twice.
Also, git is able to see file transforms between normal file and macbinary file even if the file is moved and renamed because macbinary is not a compressed file format and git can therefore see the normal file contents inside the macbinary container.

I combined all your commits into a single commit in my fork:
https://github.com/joevt/MacROMan/c...5076387938f6dbe0dab767da8f0ab352fd90a72f8c3e8

Thanks! I'll do that.

 

[adespoton]

Thanks! I'll do that.

I think I'm just going to drop-replace my archive with yours and then script up a little thing to validate the version numbers; as you pointed out, 8.9.1 and 9.0.1 have the same data fork MD5, as do 7.8.1 and 7.9.1. I'll pull the right version numbers out and get all that sorted.

 

[joevt]

I've chosen to use macbinary instead of zip because the zip format might be proprietary to macOS and the ditto command or the Finder "Compress..." command that creates zip archives is non-deterministic - doesn't produce the same file twice.

To make sure the macbinary command always produces the same result file, I use SetFile -a avBStclInmedz to make sure all the files have the same finder flags (bundle, system, inited).

I think I'm just going to drop-replace my archive with yours and then script up a little thing to validate the version numbers; as you pointed out, 8.9.1 and 9.0.1 have the same data fork MD5, as do 7.8.1 and 7.9.1. I'll pull the right version numbers out and get all that sorted.

Attached the stuff I used to compare ROMs from the three forks.

 

[adespoton]

To make sure the macbinary command always produces the same result file, I use SetFile -a avBStclInmedz to make sure all the files have the same finder flags (bundle, system, inited).


Attached the stuff I used to compare ROMs from the three forks.

Should your worksheet include a check for a resource fork? There's a few files you converted to MacBinary that didn't have their resource fork anymore (the ones I hadn't updated).

 

[joevt]

Should your worksheet include a check for a resource fork? There's a few files you converted to MacBinary that didn't have their resource fork anymore (the ones I hadn't updated).

Look at the code that produces /tmp/filelist3.txt
The file list includes md5 for comparing data forks, and size of resource fork.
0 = no resource fork.
286 = empty resource fork.
I convert all the files to MacBinary to preserve file type/creater, dates, flags. I suppose the files missing resource forks don't need to be in MacBinary format but it doesn't matter. A small script decodes all the MacBinary files (search for macbinary decode).

 

[65a]

Had some eMac annoyances, it turns out that you must run Update Drivers from Drive Setup 2.1 if the partition layout has changed (or you are getting a flashing question mark), but I have triple boot working with Linux, OS X and OS 9.

eMac is currently undergoing surgery, I can sometimes boot to OF at 1.92ghz, but still trying to understand the vid0-vid4 settings for CPU voltage. I may try a lower clock, or replacing the one obviously bad cap next.

So I can confirm: injecting the Apollo PEF (and not touching res/depth settings) will give 1024x768 at millions of colors by default at boot. Any changes to res or depth require depth to be 256 to not gray screen, but work otherwise. I strongly suspect there are changes to the calling convention for the NDRV or something along those lines leading to grey screen.

I found some random tools that might be useful, including the Fragmalyzer and Discipline (not sure if I can use this to inspect NDRV calls or not yet).

Attached is the current basic ROM I am using.

 

[65a]

Notes for myself or some future other trying to run tbxi-patches scripts on linux: install python 3.10 or so (which may not match system python) and do everything in a venv associated with that version. As is tradition, python has been stripping out necessary functionality, and IIRC 3.10 is the last one with the necessary hqx functions to operate on hqx-encoded roms.

 

[65a]

Ok, I now have the eMac at 1.92 (it took a 1.475 core voltage to get there, but ok). I noticed another anomaly using just the normal ndrv, so here's the current state.

- We can change resolution if the depth is set to 256
- Default depth is already millions, and it will stay if you don't touch anything.
- Some games, like EV Nova, can change the depth to thousands and restore it without gray screen.

So this means that both depth and resolution can be changed, just not through all paths or both at once.

ghidra digging is tough going. There are a few bit checks with early returns near likely functions, but I am still trying to understand how exactly the call path works. I really suspect there is something stupid happening with a bitflag or something.