This is how the S3-Trio64 story (the beginning is in the previous post) went on.
The monitor LED was blinking as if there was no signal, and it looked like after all my suspect was correct and a generic "vga-video-on" code was not enough to initialize a S3-Trio card.
I don't have a null-modem cable to debug OFW using a serial line, so all the instruments I had to debug what's going wrong were the "beep" and "reset-all" OFW commands. Which is not much. So I considered trying another emulators to verify my S3 OFW fix.
First I tried 86Box. Just like PCem it uses a ROM file name to determine whether a PCI card should be available for the emulation. So there is no official way to start it without VGA BIOS. But it's easy to hack: just rename a ne2000.rom to a desired VGA BIOS name. Then there is a network BIOS instead of VGA BIOS, which is harmless because it exits after not finding the network card. Yeah, 25 years ago I used my network card to read arbitrary ROMs, the story repeats itself in reverse.
The screen stayed black just like on a real PC, so I thought I've got an easy way to debug where it goes wrong. Although 86Box (just like PCem) don't emulate serial connections, still using a floppy image is much easier than writing a physical floppy. Alas, after some debugging it turned out PCem and 86Box don't emulate the PLL registers which was the reason why OFW didn't like it. Disabling the PLL restart took the OFW a couple steps further. Up to a 86Box crash, reported here.
Being desperate I even tried Microsoft Virtual PC, which supposedly emulates S3-Trio64. Well, it doesn't emulate the PLL, so I had to get back to the experiments with the physical card.
To make a long story short, the "vga-video-on" was not the problem. It seems that OFW supported only the most of S3 Trio64 and some of Trio64V+ chips. I was just lucky to have an unsupported one. The OFW developers described the challenge of supporting the V+ chips in this nice comments:
\ Problem: none of the above will have worked if this is a "Z" version
\ of the Trio-64. "Z" versions are those parts marked with an "X" after
\ their part number. Hey, I didn't make this up, S3 did. Anyhow, if you
\ have one of these beasties, you have to wake up the part differently.
\ The catch is, you pretty much have to do this in the blind because
\ until the chip is working, you can't tell which version it is for if
\ you go poking at a chip that is not awake yet, you may hang the system.
\ As it turns out, the Trio-64V+ (which at this point in the probe process
\ is indistinguishable from all of the other versions of the Trio-64, also
\ won't have initialized prior to the above command. So, that extra command
\ is usefull for both the "Z" Trio-64 and the Trio-64V+ (also known as the
\ '765 [all other Trios have a '764 part number]). Oh but wait, there is
\ more. The 765 does not respond to IO accesses unless the memory access
\ enable bit is also turned on. Which is why the above now includes this
\ "feature".
\ And now back to our regularly scheduled programming...
So I tried to improve the Trio-64V+ recognition process, and Hercules Terminator 64 suddenly worked! The question is if the support of Trio-64V+ breaks the regular Trio-64.
I suspected my Trio-64V+ to be one of the last working ones in this Universe, but I wanted to be sure about it. After some googling I've stumbled over vogons.org, the community of people who still run S3 VGA (among some other cool stuff from the past) on a daily basis. So I asked them to test, and got a lot of responses. (Once again, thanks to everyone who responded)
Up to now there is no report of a Trio-64 which wouldn't work with the current OFW. So the fix is committed in the upstream OFW.
But still if you have one of S3-Trio32, S3-Trio64 or S3-Trio64V+ cards, please test if they work with OFW, as described on vogons.org.
/Stay tuned for more S3-Trio adventures.
The monitor LED was blinking as if there was no signal, and it looked like after all my suspect was correct and a generic "vga-video-on" code was not enough to initialize a S3-Trio card.
I don't have a null-modem cable to debug OFW using a serial line, so all the instruments I had to debug what's going wrong were the "beep" and "reset-all" OFW commands. Which is not much. So I considered trying another emulators to verify my S3 OFW fix.
First I tried 86Box. Just like PCem it uses a ROM file name to determine whether a PCI card should be available for the emulation. So there is no official way to start it without VGA BIOS. But it's easy to hack: just rename a ne2000.rom to a desired VGA BIOS name. Then there is a network BIOS instead of VGA BIOS, which is harmless because it exits after not finding the network card. Yeah, 25 years ago I used my network card to read arbitrary ROMs, the story repeats itself in reverse.
The screen stayed black just like on a real PC, so I thought I've got an easy way to debug where it goes wrong. Although 86Box (just like PCem) don't emulate serial connections, still using a floppy image is much easier than writing a physical floppy. Alas, after some debugging it turned out PCem and 86Box don't emulate the PLL registers which was the reason why OFW didn't like it. Disabling the PLL restart took the OFW a couple steps further. Up to a 86Box crash, reported here.
Being desperate I even tried Microsoft Virtual PC, which supposedly emulates S3-Trio64. Well, it doesn't emulate the PLL, so I had to get back to the experiments with the physical card.
To make a long story short, the "vga-video-on" was not the problem. It seems that OFW supported only the most of S3 Trio64 and some of Trio64V+ chips. I was just lucky to have an unsupported one. The OFW developers described the challenge of supporting the V+ chips in this nice comments:
\ Problem: none of the above will have worked if this is a "Z" version
\ of the Trio-64. "Z" versions are those parts marked with an "X" after
\ their part number. Hey, I didn't make this up, S3 did. Anyhow, if you
\ have one of these beasties, you have to wake up the part differently.
\ The catch is, you pretty much have to do this in the blind because
\ until the chip is working, you can't tell which version it is for if
\ you go poking at a chip that is not awake yet, you may hang the system.
\ As it turns out, the Trio-64V+ (which at this point in the probe process
\ is indistinguishable from all of the other versions of the Trio-64, also
\ won't have initialized prior to the above command. So, that extra command
\ is usefull for both the "Z" Trio-64 and the Trio-64V+ (also known as the
\ '765 [all other Trios have a '764 part number]). Oh but wait, there is
\ more. The 765 does not respond to IO accesses unless the memory access
\ enable bit is also turned on. Which is why the above now includes this
\ "feature".
\ And now back to our regularly scheduled programming...
So I tried to improve the Trio-64V+ recognition process, and Hercules Terminator 64 suddenly worked! The question is if the support of Trio-64V+ breaks the regular Trio-64.
I suspected my Trio-64V+ to be one of the last working ones in this Universe, but I wanted to be sure about it. After some googling I've stumbled over vogons.org, the community of people who still run S3 VGA (among some other cool stuff from the past) on a daily basis. So I asked them to test, and got a lot of responses. (Once again, thanks to everyone who responded)
Up to now there is no report of a Trio-64 which wouldn't work with the current OFW. So the fix is committed in the upstream OFW.
But still if you have one of S3-Trio32, S3-Trio64 or S3-Trio64V+ cards, please test if they work with OFW, as described on vogons.org.
/Stay tuned for more S3-Trio adventures.
