Running the Thunder II 1360 at 1600x1200

[eharmon]

Everything seems right for the SuperMac Thunder II GX 1360 to successfully run at 1600x1200:

Like it's 1600 peer it has:
- 6MiB of memory
- 3x 135MHz RAMDACs

So I took a look at modifying the ROM and/or extension to enable 1600x1200 resolutions.

The bad news: doesn't work yet.
The good news: I'm not convinced it's a dead-end.

Roughly, I started by patching one of the resolutions (832x624) to map to a 1600x1200 framebuffer in the declrom. Essentially I just modified the existing vpBounds for a higher resolution. That works, it'll boot at 1600x1200...sorta:

- The framebuffer runs properly at 1600x1200, but I think acceleration goes a bit haywire, drawing duplicate data in multiple regions of memory (vertically). It "works", but the software stack isn't handling it properly.
- The output signal behaves oddly, the card does auto-adjust to the resolution, but improperly. It ends up outputting somewhere around 1200x1200, but with a pretty poor sync lock. My upscaler locks onto the signal crushed by 50% vertically.
- The card puts it in virtual desktop mode, so the 1600x1200 framebuffer is scrolled around the 1200x1200 output.

All this occurs before we even reach Mac OS, so it's pretty clear the extension doesn't have much responsibility here.

So the card's init is definitely capable of "figuring out what to do" to a degree, but it's not able to exactly understand how it should handle this situation.

I've read some of Designing Cards and Drivers for the Macintosh Family, and took a look at the timing descriptions for various video modes. But I can't tell how the card might be determining how to configure the RAMDAC, which I presume it's doing only half-correctly.

Could the control panel be laying down the right hints in the PRAM? Only a few bits are twiddled on display changes. Is there some hardcoded table in the PrimaryInit? Or in the driver provided by the card? I see suspicious sections in the status function that look quite a bit like data tables.

A 1600 ROM to compare with would be best, obviously, and they might even be compatible with each other. But since those seem to be soldered down it seems unlikely we'll see a copy. But I kinda wonder if they're mostly universal and with the right bits flipped, the 1360 card will behave like a 1600 anyway.

(As an aside: Thunder/24 ROMs are NOT compatible with Thunder II, it seems the universality does not extend that far -- makes sense since Thunder II were the first cards with higher resolutions)

 

[Melkhior]

Essentially I just modified the existing vpBounds for a higher resolution.

You also need to patch vpRowBytes for the stride between lines (depth times horizontal resolution is the minimum, exact value depends on how the HW behave...). If all resolutions in the DeclRom uses the minimum value, it's easier, the HW can do anything just use 1600 (if you're in 8-bits). If the values are (sometimes) higher, alignment restriction might be in play...

Also check if vpBaseOffset changes from one resolution to the next, or if it is constant (in which case you don't need to worry about it, the most likely case).

You may also need to change mPageCnt (to something lower) to account for the larger framebuffer. Though I don't think the system uses the extra pages for anything ever so it's unlikely to cause trouble.

 

[eharmon]

You also need to patch vpRowBytes for the stride between lines (depth times horizontal resolution is the minimum, exact value depends on how the HW behave...). If all resolutions in the DeclRom uses the minimum value, it's easier, the HW can do anything just use 1600 (if you're in 8-bits). If the values are (sometimes) higher, alignment restriction might be in play...

Also check if vpBaseOffset changes from one resolution to the next, or if it is constant (in which case you don't need to worry about it, the most likely case).

You may also need to change mPageCnt (to something lower) to account for the larger framebuffer. Though I don't think the system uses the extra pages for anything ever so it's unlikely to cause trouble.

Awesome, thanks for the hints. Do you know any good docs for things like the page count? Despite being 500 pages, most of the documentation is a bit vague on what that actually does to memory layout.

 

[Melkhior]

Do you know any good docs for things like the page count?

Not really, just put 1 if in doubt that's always legit Originally I suppose the intent was double-buffering or other optimizations - each "page" can hold the entire framebuffer and can be used as the source of data to display, so you can switch what is displayed very efficiently. Can be useful to render a frame in an unused "page" for instance. Or for virtual displays. But I don't think MacOS is doing much with it - at least I don't remember seeing it trying to change the "page" in my driver.

 

[eharmon]

Not really, just put 1 if in doubt that's always legit Originally I suppose the intent was double-buffering or other optimizations - each "page" can hold the entire framebuffer and can be used as the source of data to display, so you can switch what is displayed very efficiently. Can be useful to render a frame in an unused "page" for instance. Or for virtual displays. But I don't think MacOS is doing much with it - at least I don't remember seeing it trying to change the "page" in my driver.

Here's where I'm at right now:

Original Mode, 832x624x24:

vpBaseOffset: 2097152
vpRowBytes: 8192
vpBounds: 0, 0, 624, 832
vpVersion: 0
vpPackType: 0
vpHRes: 72
vpVRes: 72
vpPixelType: 0
vpCmpCount: 16
vpCmpSize: 32
vpPlaneBytes: 196616
mPageCnt: 1
mDevType: 2

I simply swapped vpBounds, as noted previously.

By comparison here's the 2048x1024x24 virtual mode:

vpBaseOffset: 2097152
vpRowBytes: 8192
vpBounds: 0, 0, 1024, 2048
vpVersion: 0
vpPackType: 0
vpHRes: 72
vpVRes: 72
vpPixelType: 0
vpCmpCount: 16
vpCmpSize: 32
vpPlaneBytes: 196616
mPageCnt: 1
mDevType: 2

Looking at lower bit depths, we see the type switch from 2 (direct) to 0 (indexed CLUT), and the vpRowBytes and vpPlaneBytes are decreased as bit depth decreases. But 24-bit modes all seem pretty much the same.

We're already at a single page (mPageCnt), and everything else is held the same. 2048x1024x24 should use exactly every bit of memory the card has for the framebuffer (6MiB), so if it works to write all 6MiB from that base offset, I'd think the smaller 1600x1200x24 should fit too.

Which I would think means either the card init can't figure it out or the control panel writes something funky into PRAM as a second value to instruct the card how to configure the RAMDAC?

 

[eharmon]

Okay, still digging around but I've found some things via the PRAM values. It appears there's two areas with resolution values (with the card in slot E):

Offset 0x78: A 1-byte value indicating the physical display output.
Offset 0x84: A 1-byte value indicating the sResource to use for the framebuffer.

I'm not sure exactly what those first values are, but they do correspond logically:

640x480: 0000 0110 = 6
1280x960: 0001 0101 = 21
1360x1024: 0001 0110 = 22
2048x1024: 0001 0101 = 21

Well...sorta. Both 1360x1024 and 2048x1024 should output the same physical resolution in normal operation? Just to confirm the second byte, looking at the sResources they point at we see 150 for 1360 and 141 for 2048, and these match the DeclROM.

But what do these values correspond to? Are there standard timings specified anywhere? Or is this mapping some table in the ROM (there's a few sections that look suspiciously like indexed data...).

But maybe the INIT can be reverse engineered knowing where it looks at the PROM...hmm...

 

[Melkhior]

Original Mode, 832x624x24:

vpBaseOffset: 2097152
vpRowBytes: 8192
vpBounds: 0, 0, 624, 832
vpVersion: 0
vpPackType: 0
vpHRes: 72
vpVRes: 72
vpPixelType: 0
vpCmpCount: 16
vpCmpSize: 32
vpPlaneBytes: 196616
mPageCnt: 1
mDevType: 2

Mmmm, that looks suspicious to me. The values for vpCmpCount, vpCmpSize and vpPlaneBytes are really weird.
Also, you're missing an entry for vpPixelSize immediately after vpPixelType - so maybe the end of that is not well decoded.
vpPackSize is also missing after vpPackType, but maybe the two words were conflated in a single longword as the vpHRes/vpVRes are OK with 72.

If we insert vpPixelSize that would translate to:

vpPixelType: 0
vpPixelSize: 16
vpCmpCount: 32
vpCmpSize: 3
vpPlaneBytes: 524288 (+ two missing LSB)

still not looking great. Thinking about it, the resolution stuff is suppose to be fixed-point so would appear as 4718592 unless decoded as fixed-point... or if it was shifted by 2 bytes from the missing vpPackSize ? if we add that back:

vpPackType: 0
vpPackSize: 0
vpHRes: 0x480000 [== 72.00 fixed-point]
vpVRes: 0x480000 [== 72.00 fixed-point]
vpPixelType: 16
vpPixelSize: 32
vpCmpCount: 3
vpCmpSize: 8
vpPlaneBytes: [4 missing bytes]

Which looks much better to me. I would suggest double-checking how you decode the resources.

Then if the vpBounds is used for the virtual desktop (which makes sense, as MacOS is using those values for the size of the usable FB), I don't think changing that would directly affect the output - it's really just a description of the memory content. The driver likely figures out how to set up the video output based on a combinations of the virtual resolution from the resources, and either some built-in algorithm or some other source of information from e.g. a control panel to figure out the display signal to produce.

At some point the ROM is going to have to write values to the RAMDAC and maybe other parts of the device to setup the output resolution. I doubt that's going to be easy and doable just with resources. You will need to look at the Primary init function, and probably Open and Secondary as well.

I'm asusming you want a larger physical display, not a smaller virtual desktop

640x480: 0000 0110 = 6
1280x960: 0001 0101 = 21
1360x1024: 0001 0110 = 22
2048x1024: 0001 0101 = 21

Well...sorta. Both 1360x1024 and 2048x1024 should output the same physical resolution in normal operation? Just to confirm the second byte, looking at the sResources they point at we see 150 for 1360 and 141 for 2048, and these match the DeclROM.

You would need to confirm which (physical) resolution is outputed for various (virtual) resolutions, including for other normally non-virtual size like 832x624. Is there some way to select said (physical) resolution? i.e. for a 2048x1024 virtual framebuffer, can you select what signal to send to the screen ? It'd make sense that would work on any "monitor sizes" as Apple was measuring back then. If you can't change, then the logic is likely hardwired in the driver and/or additional software, and might be stored in the PRAM. If you can, then it's very likely to be stored in the PRAM.

But what do these values correspond to? Are there standard timings specified anywhere? Or is this mapping some table in the ROM (there's a few sections that look suspiciously like indexed data...).

The most likely tables in the ROM if are gamma tables, which are usually quite large (sets of 256 entries or multiple thereof).

But maybe the INIT can be reverse engineered knowing where it looks at the PROM...hmm...

You likely need to if you want to figure out how to change the hardware settings. What does the INIT offer as additional feature? I would suggest focussing on the ROM only at first, to simplify the work.

 

[eharmon]

Mmmm, that looks suspicious to me. The values for vpCmpCount, vpCmpSize and vpPlaneBytes are really weird.
Also, you're missing an entry for vpPixelSize immediately after vpPixelType - so maybe the end of that is not well decoded.
vpPackSize is also missing after vpPackType, but maybe the two words were conflated in a single longword as the vpHRes/vpVRes are OK with 72.

If we insert vpPixelSize that would translate to:

vpPixelType: 0
vpPixelSize: 16
vpCmpCount: 32
vpCmpSize: 3
vpPlaneBytes: 524288 (+ two missing LSB)

still not looking great. Thinking about it, the resolution stuff is suppose to be fixed-point so would appear as 4718592 unless decoded as fixed-point... or if it was shifted by 2 bytes from the missing vpPackSize ? if we add that back:

vpPackType: 0
vpPackSize: 0
vpHRes: 0x480000 [== 72.00 fixed-point]
vpVRes: 0x480000 [== 72.00 fixed-point]
vpPixelType: 16
vpPixelSize: 32
vpCmpCount: 3
vpCmpSize: 8
vpPlaneBytes: [4 missing bytes]

Which looks much better to me. I would suggest double-checking how you decode the resources.

Then if the vpBounds is used for the virtual desktop (which makes sense, as MacOS is using those values for the size of the usable FB), I don't think changing that would directly affect the output - it's really just a description of the memory content. The driver likely figures out how to set up the video output based on a combinations of the virtual resolution from the resources, and either some built-in algorithm or some other source of information from e.g. a control panel to figure out the display signal to produce.

At some point the ROM is going to have to write values to the RAMDAC and maybe other parts of the device to setup the output resolution. I doubt that's going to be easy and doable just with resources. You will need to look at the Primary init function, and probably Open and Secondary as well.

I'm asusming you want a larger physical display, not a smaller virtual desktop


You would need to confirm which (physical) resolution is outputed for various (virtual) resolutions, including for other normally non-virtual size like 832x624. Is there some way to select said (physical) resolution? i.e. for a 2048x1024 virtual framebuffer, can you select what signal to send to the screen ? It'd make sense that would work on any "monitor sizes" as Apple was measuring back then. If you can't change, then the logic is likely hardwired in the driver and/or additional software, and might be stored in the PRAM. If you can, then it's very likely to be stored in the PRAM.


The most likely tables in the ROM if are gamma tables, which are usually quite large (sets of 256 entries or multiple thereof).


You likely need to if you want to figure out how to change the hardware settings. What does the INIT offer as additional feature? I would suggest focussing on the ROM only at first, to simplify the work.

Hmmm, yeah it definitely doesn't look decoded right. I actually copied and pasted wrong (twice!), so I am decoding vpPackSize.

vpPixelSize was missing though and after poking around some other source, it seems like there's also an undocumented(?) gap between vpPackSize (supposedly a word) and vpHRes.

Skipping 2 bytes between that and vpHRes and now it looks sane! I double checked with libdecl from decltools and, oddly, both now agree vpPlaneBytes should be zero...fortunately we agree on every value now, too. And yes, libdecl skips an extra 2 bytes!

Fortunately all the setup seems to be in the Primary, Open, and Secondary. I'll keep digging...at least the declrom parsing seems like it makes more sense now .

 

[Melkhior]

vpPixelSize was missing though and after poking around some other source, it seems like there's also an undocumented(?) gap between vpPackSize (supposedly a word) and vpHRes.

vpPackSize is a word in the documentation (DCDMF3 Table 9-2), but a long in my own (known to work!) DeclROM. It's also a long in the sample ROM of DCDMF3 (page 548 a.k.a. 589 in the PDF), which I used as a reference as the beginning of my work. I guess someone didn't proofread Table 9-2 correctly...

Edit: I used the table 9-2 definition (word) in my post above, hence why as you had already decoded but not copy/pasted it ended up taking 4 bytes... guess for once, two wrongs did make a right

 

[eharmon]

vpPackSize is a word in the documentation (DCDMF3 Table 9-2), but a long in my own (known to work!) DeclROM. It's also a long in the sample ROM of DCDMF3 (page 548 a.k.a. 589 in the PDF), which I used as a reference as the beginning of my work. I guess someone didn't proofread Table 9-2 correctly...

Edit: I used the table 9-2 definition (word) in my post above, hence why as you had already decoded but not copy/pasted it ended up taking 4 bytes... guess for once, two wrongs did make a right

I think you're right! Third edition and it still has a typo .

Continuing to poke around, from ROMDefs.h I found the DeclROM can declare the timing information, and this DeclROM does:

sVidAuxParams               = 123,                          /*more video info for Display Manager -- timing information*/

I wonder if the first set of bits in the PRAM select which timing to use from those params? Need to figure out how to parse them...

 

[eharmon]

Well, that was easy to parse but unfortunately itself potentially a dead end. The sVidAuxParams is another OSLst mapping to the sResource values for the video modes (which was promising!).

Essentially that list is a set of video mode IDs mapping to two values, one I can't tell what it is (max bits per pixel? -- it always seems to be 8 -- maybe it's some sort of flag), and the other is the video timings as defined in Video.h!

I can see mode 137 in the ROM (512x384) maps to the timing entry for 512x384 @ 60Hz! Neat.

Unfortunately, all the fun resolutions in the original ROM are mapped to timing zero, instead, which must mean it's up to the card to define. Video.h indicates its "Unknown timing... force user to confirm", I assume the "user" here is the card.

By example:

sResource (Board) ->
    sVidAuxParams (123) ->
        Mode 133 ->
            ???? = 8
            Timing = 512x384 (60Hz)

However, there is a defined timing for 1600x1200 in Video.h. A few even. I guess I'll give that a try and see what happens!

 

[joevt]

What tool are you using to do the parsing?

I've attached the tools from the NuBus/Slot Manager folder of the Apple Developer CDs. / Tool Chest / Devices.

SlotsDump is a tool I made in CodeWarrior Pro 4. Sample output from a Macintosh LC, IIfx, Centris, and Power Mac 8600 is included. The 8600 is not interesting since it's a PowerPC Mac with PCI instead of NuBus. The Centris has sRsrcVidNames. For each sRsrcVidNames name it has a corresponding entry in the next sResource entry with ID 0x7E sRsrcUnknown? I don't know what that's for (but wait! see below).

The info available in the Slot Resources isn't enough to add a new resolution / timing. You need to know all the registers and all the values you can put in the registers. As an example, look at the Open Firmware driver for the video output of a Power Mac 8600 (for the chaos/control device). Control1 is from Open Firmware. Control2 is from boot-68 (Apple open source and is included with XPostFacto bootx code - it fixes bugs in the Open Firmware version by completely replacing the Open Firmware version). Control3 is my attempt to add more modes and a nvram preference (untested?). Apple included sample code "GDX 950717" for ndrv PowerPC graphics drivers and I did try to reverse engineer the control ndrv from Mac OS 9.1 using that sample code. I don't think I finished that.

The slot rom may contain a 68K DRVR which might have the info for programming the registers if that info is not included elsewhere in the ROM.

A timing includes pixel clock, and horizontal and vertical blanking front porch, sync width, back porch. A register might explicitly define one of those but more likely there's multiple registers that need to be set using some kind of complicated calculation like using a numerator (multiplier) and denominator (devider) and selecting from one or more different clocks, etc.

Actually, looking back at sResource type 0x7E in the Centris SlotsDump output. ROMDefs.h says it is sVidParmDir. It is mentioned in a few places in the SuperMario source code (GitHub). It appears to contain some register values for the Sonora, Civic, CSC, VSC, and DAFB, graphics device for each display mode. Every graphics device has different registers, so the format for sVidParmDir is different for each one. This is not important in this case unless the Thunder II also defines sVidParmDir and you can decipher the format. You need to look at the 68K DRVR, search for where it looks up the sVidParmDir and see how it uses the info.

sVidParmDir 126 may be confused with sVidAuxParams 123 in some places such as
Developer Note "Display Device Driver Guide" Device support for the Display Manager.

You mentioned sVidAuxParams 123. Searching for that in SuperMario results in hits for DisplayMgrUtils.c and the video devices Sonora and VSC. It appears to be just a single timing number but that doesn't seem to match what you're seeing? I need to see a SlotsDump output to be sure. Timing modes are listed in IOMacOSVideo.h. SuperMario uses the Deprecated timing names. Timing mode 8 is this one:

timingInvalid_SM_T24 = 8, /* Work around bug in SM Thunder24 card.*/

 

[eharmon]

What tool are you using to do the parsing?

I've attached the tools from the NuBus/Slot Manager folder of the Apple Developer CDs. / Tool Chest / Devices.

SlotsDump is a tool I made in CodeWarrior Pro 4. Sample output from a Macintosh LC, IIfx, Centris, and Power Mac 8600 is included. The 8600 is not interesting since it's a PowerPC Mac with PCI instead of NuBus. The Centris has sRsrcVidNames. For each sRsrcVidNames name it has a corresponding entry in the next sResource entry with ID 0x7E sRsrcUnknown? I don't know what that's for (but wait! see below).

The info available in the Slot Resources isn't enough to add a new resolution / timing. You need to know all the registers and all the values you can put in the registers. As an example, look at the Open Firmware driver for the video output of a Power Mac 8600 (for the chaos/control device). Control1 is from Open Firmware. Control2 is from boot-68 (Apple open source and is included with XPostFacto bootx code - it fixes bugs in the Open Firmware version by completely replacing the Open Firmware version). Control3 is my attempt to add more modes and a nvram preference (untested?). Apple included sample code "GDX 950717" for ndrv PowerPC graphics drivers and I did try to reverse engineer the control ndrv from Mac OS 9.1 using that sample code. I don't think I finished that.

The slot rom may contain a 68K DRVR which might have the info for programming the registers if that info is not included elsewhere in the ROM.

A timing includes pixel clock, and horizontal and vertical blanking front porch, sync width, back porch. A register might explicitly define one of those but more likely there's multiple registers that need to be set using some kind of complicated calculation like using a numerator (multiplier) and denominator (devider) and selecting from one or more different clocks, etc.

Actually, looking back at sResource type 0x7E in the Centris SlotsDump output. ROMDefs.h says it is sVidParmDir. It is mentioned in a few places in the SuperMario source code (GitHub). It appears to contain some register values for the Sonora, Civic, CSC, VSC, and DAFB, graphics device for each display mode. Every graphics device has different registers, so the format for sVidParmDir is different for each one. This is not important in this case unless the Thunder II also defines sVidParmDir and you can decipher the format. You need to look at the 68K DRVR, search for where it looks up the sVidParmDir and see how it uses the info.

sVidParmDir 126 may be confused with sVidAuxParams 123 in some places such as
Developer Note "Display Device Driver Guide" Device support for the Display Manager.

You mentioned sVidAuxParams 123. Searching for that in SuperMario results in hits for DisplayMgrUtils.c and the video devices Sonora and VSC. It appears to be just a single timing number but that doesn't seem to match what you're seeing? I need to see a SlotsDump output to be sure. Timing modes are listed in IOMacOSVideo.h. SuperMario uses the Deprecated timing names. Timing mode 8 is this one:

timingInvalid_SM_T24 = 8, /* Work around bug in SM Thunder24 card.*/

I have a Tcl template that works with Hex Fiend for parsing.

Thanks for the resources, the card definitely needs to set the internal RAMDAC registers, etc, via it's internal routines, but I've had a strong hunch that's actually data driven by tables in the ROM, since it supports so many displays.

It seems like the sVidAuxParams might have been a red herring. I'm not sure what those are being used for, but they definitely encode some information about the display data, and in most places correspond to those timing enum values -- but modifying it didn't seem to accomplish much.

However, I think this might be achieved by a set of additional sResources in the board resource, from 200-228. They seem to encode information about specific monitors, and correspond correctly to the physical IDs in the PRAM I mentioned above. If you add 200, you always get a monitor entry that correctly corresponds to the supported resolution you're using. So 640x480 encodes ID 6, and the entry at 206 is for a 640x480 monitor.

I unpacked those resources a bit and there's a ton of values, but I think I've figured out what some of them are. Unfortunately, possibly not enough to affect timing, I think.

Looking at the entry for a standard 1152x870 Apple (or clone) monitor, we see:

00000072 0E322000 50020600 4F010101 000F001A 00AA00B7 00020028 038F0394 FFFFFFFF 00E7FFFF 0000FFFF 00000000 00000000 00404000 05518005 05000000 E0C0B576 256D0000 00000040 008100F3 00000480 03669300

A bunch of these are flags that I'm not really sure the intention of, or seem fixed and never vary between monitors/resolutions. However, a few are interesting:

00000072 0E322000 50020600 4F010101 000F001A 00AA00B7 00020028 038F0394 FFFFFFFF 00E7FFFF 0000FFFF 00000000 00000000 00404000 05518005 05000000 E0C0B576 256D0000 00000040 008100F3 00000480 03669300

My best guesses:

00000072 = some sort of ID?
0E322000 = flags
001A = flags
00AA = flags
00B7 = some sort of ID?
038F0394 = two v-blank related values? -- for this 1152x870 display the values are 911 and 916, respectively
00E7 = gamma-related? -- some monitors just have FFFF here
0040 = flags?
0551 = flags?
0480 = hres
0366 = vres
9300 = flags?

As a comparison, here's a 1360x1024 entry:

00000078 0F320000 50020600 4F010101 000F0022 00CC00D7 00020028 0429042C FFFFFFFF 00E7FFFF 0000FFFF 00000000 00000000 00404000 05508005 05000000 E0C0B576 256D0000 00000040 00810073 00000550 04009600

Besides various flag changes, you can see the v-blank(?) values and vres/hres change most significantly.

It is possible the ROM does another lookup within it's own routine, but these are quite interesting (and I'm still fighting decompilers).

 

[eharmon]

Huh, correcting the sVidAuxParams caused the Monitors control panel from 7.6 to now display the new resolution names. Previously only 7.1 did after I changed the sRsrcVidNames. That or I fixed something else along the way...but 7.1 definitely displays whatever text is in sRsrcVidNames and 7.6 does not.

So it at least has that effect!