red-ray wrote on 2026-02-05, 10:41:

Feliksas wrote on 2026-02-05, 09:24:

Well, I've also found a couple posts here and there claiming it's PReP, but that isn't easily verifiable
Mine has the 332MHz 604e
the Matrox 220 GPU might be the culprit.

Yes it is, see https://www.youtube.com/watch?v=fjXZh-a9WZE

Actually, I'm not so sure it is pure PReP anymore 😀

10 > dev /  ok    
20 > .properties 
3name                    IBM,7043-140
4model                   IBM,7043-140
5compatible              IBM,7043-140
6clock-frequency         03f64598 
7device_type             chrp
8pc-emulation            
9exception-relocation-size 
10                        00100000 
11processor-hole          
12system-id               0002035macadd
13#address-cells          00000001 
14#size-cells             00000001 
15platform-open-pic       f96c0000 
16
17 ok
180 > 

Feliksas wrote on 2026-02-06, 15:17:

I've actually ordered an S3 Trio64V+ 86C765, planning to replace the BIOS on it and try

I'm not 100% sure, but it comes to my mind that IBM PPC has gone a different road than Sun and Apple, and they don't need specific FCode VGA BIOSes. Instead they have built a small 8086 emulator in a firmware, and execute the usual VGA BIOS using CPU emulation. Don't know if it applies to all IBM firmware though. Can you please try your Matrox in a 80x86 machine to check whether it has a usual VGA BIOS?

No, it is not a regular PC card - it does not get initialized in an x86 machine and does not display any signal, although Windows XP recognizes it as a regular Matrox Mystique PCI (but BIOS version shows up as v0.0). I've desoldered the ROM (1 MBit TMS28F010B) and dumped the contents, attaching it to this post.

I've also desoldered and dumped the contents of two AM29F040B 4 MBit ROMs on the motherboard, but their contents turned out to be 100% identical to what is in the firmware image - the top 512KB of it goes to the chip closer to the front panel (which is also accessible from OpenFirmware at addresses 0xFFF00000 - 0xFFF7FFFF), the other 512KB goes to the second chip that's closer to the rear. Also attaching their contents here.

P.S. I see some strings in the video ROM that show up as Forth words when the adapter is selected in the device tree - function names?

Feliksas wrote on 2026-02-09, 15:22:

P.S. I see some strings in the video ROM that show up as Forth words when the adapter is selected in the device tree - function names?

Thank you for the dumps! I've always been jealous to people who can just desolder a SMD ROM, and then solder it back. How cool is that?!
There are no functions in Forth, only "words" which can perform stack operations. But yes, they are somewhat similar to typeless functions.
Yes, the Matrox ROM is FCode, it can be somewhat detokenized by fcode-utils-1.0.2:

1 detok MATROX_220_IBM_FRU_08L0895.BIN |less
2\  PCI Header identified
3\    Offset to Data Structure = 0x0020 (32)
4\  PCI Data Structure identified
5\    Data Structure Length = 0x0020 (32)
6\    Vendor ID: 0x102b
7\    Device ID: 0x051a
8\    Class Code: 0x030000  (VGA Display controller)
9\    Vital Prod Data: 0xe00
10\    Code Type: 0x01 (Open Firmware)
11\    Image Length: 0x000b blocks (5632 bytes)
12\    Last PCI Image.
13start1   ( 16-bit offsets)
14  format:    0x08
15  checksum should be:  0xf457, but is 0x1057
16  len:       0x0c35 ( 3125 bytes)
17b(") ( len=7 )
18" display"
19device-name 
200 
210 
22my-space 
23encode-phys 
240 
25encode-int 
260 
27encode-int 
28encode+ 
29encode+ 

Is pretty obfuscated though:

1 detok MATROX_220_IBM_FRU_08L0895.BIN  |grep -c unnamed-fcode
2468

But this is quite typical for VGA FCodes, the S3 Trio 64 and ATI are obfuscated too.

atar wrote on 2026-02-09, 16:24:

Thank you for the dumps! I've always been jealous to people who can just desolder a SMD ROM, and then solder it back. How cool is that?!

Well, it is a pretty bulky PLCC32 package, that can be removed with a hot air gun and then even hand-soldered back to avoid unnecessarily reheating an old PCB again. All it takes is a bit of flux and patience, really 😀 And some aluminum tape to protect the components in the vicinity from hot air, too.

atar wrote on 2026-02-09, 16:24:

Yes, the Matrox ROM is FCode, it can be somewhat detokenized by fcode-utils-1.0.2:

Hmm, interesting. But what do you make of the system firmware images? The right chip image seems to have two distinct sections - first 64KB and the rest. First 64KB seem to contain some compiled C code, judging by some strings found there (some of them are common C function names), other function names suggest that this mostly has to deal with the floppy disk controller operations (for reading firmware update images?). The second, larger part, seems to deal with writing the ROM image itself (names like transfer_uncompressed_image, transfer_compressed_image, transfer_ROM_code).

Feliksas wrote on 2026-02-10, 11:14:

Hmm, interesting. But what do you make of the system firmware images? The right chip image seems to have two distinct sections - first 64KB and the rest. First 64KB seem to contain some compiled C code, judging by some strings found there (some of them are common C function names), other function names suggest that this mostly has to deal with the floppy disk controller operations (for reading firmware update images?). The second, larger part, seems to deal with writing the ROM image itself (names like transfer_uncompressed_image, transfer_compressed_image, transfer_ROM_code).

Forth itself is probably implemented in C (I don't know about the IBM implementation). Also does it show any fancy animations when powered on? The 40p firmware does, but than again it doesn't have Forth. If the 43p implementation is similar to the Firmworks one, there is an interpreter and a dictionary. If we find where the dictionary starts, we can load it with ppcforth. I did it with the Motorola PowerStack II OFW, but it was based on Firmworks (which has been meanwhile released fully Open Source), so that was easy. I only needed to trick it not to execute init code, as it would try accessing the hardware directly, but I've forgotten the details.

The IBM implementation is less open than Firmworks OFW. AFAIR it doesn't even have the word "dump" for printing a mapped memory region, nor has it "dis" for disassembling.

Mitch Bradley (the creator of OBP and OFW) once told me there were an unreleased but working MacOS for PReP machines made by some Swiss company, but that's unobtanium I guess, just like Windows NT for SPARC.

atar wrote on 2026-02-10, 22:25:

Also does it show any fancy animations when powered on?

Well, not animations. but it does display a splash image (which is also, undoubtedly, part of this firmware, since it changed after I have updated it with the latest image I could find).

atar wrote on 2026-02-10, 22:25:

The IBM implementation is less open than Firmworks OFW. AFAIR it doesn't even have the word "dump" for printing a mapped memory region, nor has it "dis" for disassembling.

I could check, but I've successfully used Forth's @ operator for dumping contents of memory locations, though 😀 It dumps data in machine words (4 bytes per read). At least those that can be read without generating a CPU exception...