Mach64 memory controller initialization

[thorfdbg]

Hi folks,

is there any experience how to initialize the memory controller of the mach64 cards from ATI? I know, this is usually done by the VESA Bios, but I'm running on a non-x886 environment and cannot depend on the bios code. The Linux kernel code and the BSD code all assume that the memory controller is already setup and then only reprogram the CRTC, the DAC and the PLL for the clock, but leave the memory controller untouched.

For the r200 series and above, this is (moderately) straight forward as the Bios contains (in a documented place) the necessary register values in a table, and for even more modern cards, ATI provides the "ATOMBIOS", a pseudo-code that, when interpreted, runs through the initialization procedures.

I worked my way through the mach64 bios, and it seems it also uses some p-Code interpreter to perform these steps, however the card documentation (the register reference and programmer reference) do not contain any hints on the p-Code. It is not identical to the ATOMBIOS p-Code.

Did anyone attempt to understand this pCode? What does actually happen within the Mac mach64 cards used in the G3 series (e.g. "Gossamer") - do they have a PPC ROM, something that is interpreted by the OpenFirmware, or is the initialization entirely done by the OpenFirmware kernel and/or MacOs?

[thewrongchristian]

Hi folks,

is there any experience how to initialize the memory controller of the mach64 cards from ATI? I know, this is usually done by the VESA Bios, but I'm running on a non-x886 environment and cannot depend on the bios code. The Linux kernel code and the BSD code all assume that the memory controller is already setup and then only reprogram the CRTC, the DAC and the PLL for the clock, but leave the memory controller untouched.

No experience, but the registers seem to be included in:
http://bitsavers.informatik.uni-stuttga ... 999410.pdf

I worked my way through the mach64 bios, and it seems it also uses some p-Code interpreter to perform these steps, however the card documentation (the register reference and programmer reference) do not contain any hints on the p-Code. It is not identical to the ATOMBIOS p-Code.

Did anyone attempt to understand this pCode? What does actually happen within the Mac mach64 cards used in the G3 series (e.g. "Gossamer") - do they have a PPC ROM, something that is interpreted by the OpenFirmware, or is the initialization entirely done by the OpenFirmware kernel and/or MacOs?

I wonder if it's fcode instead of p-Code. If it was fcode, it can be used as is on OpenFirmware, and Mach64 based GFX were also used in entry level Sun Ultra 5/10, so it would make sense that it's OpenFirmware executable code.

[Octocontrabass]

I know, this is usually done by the VESA Bios, but I'm running on a non-x886 environment and cannot depend on the bios code.

Sure you can, just run the ROM in an emulator.

What does actually happen within the Mac mach64 cards used in the G3 series (e.g. "Gossamer") - do they have a PPC ROM, something that is interpreted by the OpenFirmware, or is the initialization entirely done by the OpenFirmware kernel and/or MacOs?

The PPC Mac versions of PCI display adapters have ROMs containing FCode instead of (or in addition to) x86 code. Open Firmware interprets the FCode. Here's the standard.

[thorfdbg]

Thanks for the replies. Yes, I do have the register definition and the programmer's manual, but it does not include information how to setup or probe these registers. Just testing all combinations is not very feasible - and despite that, you also need to setup the memory clock correctly.

The code does not seem to be FCode, it is a binary code with 8-bit opcodes, and the code interpreter is as easy to follow as a spaghetti on your lunch plate. I can decode a couple of the opcodes (conditionals, memory tests, and codes that select PCI-config, PCI addresses, VGA mapped registers as destinations), but some opcodes are totally opaque.

A ROM emulator might be helpful - any recommendations?

[Octocontrabass]

The code does not seem to be FCode, it is a binary code with 8-bit opcodes, and the code interpreter

If there's an interpreter, that's the part that would be FCode instead of x86 code on the PPC Mac version of the card.

A ROM emulator might be helpful - any recommendations?

What kind of ROM do you have? Parse the PCI data structures for each image in the ROM (there may be more than one image!) and check each image's "code type" byte.

If it's a legacy BIOS expansion ROM (type 0), you need an x86 CPU emulator. You can either write your own or use an existing one like libx86emu. That's the easy part. The hard part is you also need to emulate the various BIOS functions and hardware devices the ROM might expect to find, and you need to do that while also giving the emulated x86 CPU access to the real display hardware.

If it's an Open Firmware expansion ROM (type 1), you need an FCode interpreter and... I'm not actually sure what else, but you can read the Open Firmware specifications and figure it out.

You probably won't see the other types on such an old display adapter, but PCI expansion ROMs are still around today on modern display adapters, where you might see an EFI expansion ROM (type 3) that requires either an EFI bytecode interpreter or another CPU emulator. Oh, and you'll have to emulate a bunch of UEFI functions.

[thorfdbg]

That's really an x86 legacy bios extension that maps to c000:xxxx, and the ROM I just extracted bytewise, on a non-x86 architecture. The code does not seem to use many bios functions, or at least the interpreter does not - it goes through the int1a bios service to read and write PCI configuration data - though that is the harmless part.

On the positive side, I managed now to implement a C version of the assembler bytecode interpreter. Unfortunately, it looks as messy as the original, but the mist is clearing a bit. Unfortunately, it is not a full CPU abstraction (so unlike ATOMBIOS), as it contains one opcode that calls a native x86 function, and that opcode is unfortunately even used.

At least I get now some idea which registers are written/read and a bit of the control structure within the pCode.

The code is moderately compact, but utterly unstructured with many code parts recycled for multiple functions. Somebody at ATI must have had a lot of fun writing (and even more debugging) this stuff.

Anyhow, it's some kind of fun - like archeology, trying to decrypt an ancient language.