I normally only boot my hackintosh systems in 32 bit mode as that is how genuine macs run under 10.6. (If Apple is treating 64 bit mode as bleeding edge, why venture into the uncharted territory with no noticible performance difference?)
bcc9, if you otool -arch i386 -vt ATIFramebuffer I can see the addl for each framebuffer, and find the address as you say.
However, otool -arch x86_64 -vt ATIFramebuffer does not show an addl in the CreateInfo section
Anyways, yes, for examining&patching the 64-bit code, the instructions are necessarily a bit different, as the addressing modes are different.
For the 64-bit address of the ConnetorInfo table, look at the last leaq instruction. Compute the effective address by adding the operand's constant to the address of the next instruction. So in the Uakari case:
000000000000db7e leaq 0x00004cbb(%rip),%rdi 000000000000db85 movslq %ecx,%raxThe effective address for the lea instruction is 0x4cbb+0xdb85=0x12840
And for routines whose table has only one connector, look for the leaq instruction that immediately proceeds the movq with 0x10(%rsi) as the second operand. Compute the effective address as above.
Once you have this effective address, you should be able to convert from virtual address to disk offset as described in post #1.
I don't think it's even possible to share data between architectures in a fat binary (unless it's done thru a file). So yes, there are duplicate copies of all the ConnectorInfo tables for both architectures.
Are you booting -arch i386 after this mod? Or does making the 1 change in the table still work for you booting into the normal 64 bit mode?
Huh? Where do you get that from? For wormy:
I am not sure you are correct about the LVDS Connector type.
Wormy looks to me like its 1st port is 0x8000
dd if=ATIFramebuffer of=/tmp/wormy bs=1 skip=221720 count=32
od -Ax -tx1 /tmp/wormy
000000 02 00 00 00 40 00 00 00 29 00 00 00 00 01 01 03
000010 04 00 00 00 16 00 00 00 00 00 00 00 00 10 02 01
port-number 0, connector-type 0x00000002 = LVDS
port-number 1, connector-type 0x00000004 = DVI
In my #defines, the integers are in native/host byte order (little endian).