Running the Thunder II 1360 at 1600x1200

[jmacz]

I tried mucking with the v3 ROM but didn't get very far. Changed one of the entries (at all bit depths) from 1280x960 to 1280x1024. After installing the modified ROM, I see 1280x1024 as an option in the SuperVideo control panel but selecting it and rebooting results if the video card sending 1280x960 to the LCD but a virtual resolution of 1280x1024. I think this is a similar result to what you had @eharmon ?

I don't have a disassembler set up (nor do I fully understand the nuances of disassembling one of these ROMs) but I did end up searching for all 0x03C0 in the ROM (which is the 960 vertical resolution) and found a few of them that were right next to a stream of other vertical resolutions (1024, etc) so changed those. Didn't help.

I took a peek inside the SuperVideo 3.1 control panel. It does have some SMxx resources, one of this is a SMtm which has a name that referred to timings in it. But I don't understand enough to know what the bits in that resource mean.

 

[jmacz]

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.

My guess is this list (which is a subset of the combinations available via the monitors control panel extension) is the list shown during initial boot when the pram is zapped or you hold the option key down. I don’t think it’s the monitor mapping.

 

[jmacz]

My best guesses:

00000072 = some sort of ID?

This one is the size of the record in bytes.

 

[jmacz]

BTW, here's where I got when I looked at these entries before (this is from my v3.0.0 Thunder II 1360 ROM - not GX).

• The first green value is the record size in bytes.
• The second green value is the width in pixels.
• The third green value is the height in pixels.
• The orange value looks to be the sResource entry to use.
• The red is the display name of the record at boot (null terminated).
• The grays are the same across all records so I wasn't looking at these much.

Again, I think this list is what is shown at initial boot when the PRAM is not initialized yet for this card. Also, the above screenshot list is incomplete. I only grabbed the entries out of the ROM that I thought might be interesting. It was not the complete set.

Of those white values, the only ones that I thought might be interesting from a monitor/output perspective were (using the SuperMatch 1360x1024 as an example):

• The 0F near the beginning - across the records this one roughly maps to screen resolution (except the 60Hz SuperMac).
• The 000F0022 00CC00D7 near the middle - outside of the last two records, this value is different for every record.
• The 0429042C in the middle - this one also kinda maps to the resolution (well the first 2 bytes anyway)

The rest of the values don't show a good pattern across the records to be what we might be looking for from a monitor/resolution selection perspective.

 

[eharmon]

It has a 50MHz crystal. (and a 14.31818 MHz as well).

The board currently has a Thunder II v3.0.0 ROM on it (not sure if there was a 3.1 for this card).

Yeah, I think that makes the GX ROM identical to the "normal" II other than the description string. Kinda odd really but SuperMac loved naming products.

I tried mucking with the v3 ROM but didn't get very far. Changed one of the entries (at all bit depths) from 1280x960 to 1280x1024. After installing the modified ROM, I see 1280x1024 as an option in the SuperVideo control panel but selecting it and rebooting results if the video card sending 1280x960 to the LCD but a virtual resolution of 1280x1024. I think this is a similar result to what you had @eharmon ?

I don't have a disassembler set up (nor do I fully understand the nuances of disassembling one of these ROMs) but I did end up searching for all 0x03C0 in the ROM (which is the 960 vertical resolution) and found a few of them that were right next to a stream of other vertical resolutions (1024, etc) so changed those. Didn't help.

I took a peek inside the SuperVideo 3.1 control panel. It does have some SMxx resources, one of this is a SMtm which has a name that referred to timings in it. But I don't understand enough to know what the bits in that resource mean.

Yeah, this is the same behavior I ended up with. I believe there's another mapping in the ROM which sets up the RAMDAC configuration including timings that would likely resolve this, but it seems likely to be in the initialization code and not the declrom descriptions, since it's internal to the card. I haven't yet gotten very far on disassembling it to figure out where those are configured.

I suspect that should be sufficient to reconfigure the card, given the control panel is optional for these cards (even acceleration works without it).

 

[jmacz]

I grabbed the PrimaryINIT and SecondaryINIT code out of the ROM.. your ROM Fiend made it easy to mostly grab just the code portions out of the ROM file. I then disassembled it using Resourcerer as well as another tool I found online which resulted in near similar results. (Ghidra UI is just so annoying I didn't use it).

The SecondaryINIT didn't look very interesting. Just the usual stuff as outlined in the Designed Cards and Drivers book.

The PrimaryINIT also starts off doing the usual stuff (checking slot manager version, reading the SPRAM for the slot, etc). But there's a lot more in there including from what I saw at a glance that it's accessing something in the slot address space but higher in memory (beyond the frame buffer). It seems to be setting values there so probably interacting with something in the card, registers or something.

I did get to a point though where I noticed the PrimaryINIT that I grabbed from ROM Fiend actually has what looks to be non-code blocks embedded. The other issue is that I found a branch instruction that jumps to a location that is in the middle of an OR instruction. That's really weird. And I found some cases of BTST instructions that are operating on the same register (ie. BTST D7, D7) and no subsequent Z flag check which also looked weird. I verified I did grab the bits from the ROM intact so not sure what happened as this code seems wrong.

But still working my way through it to see if I find anything interesting. But it does look like it's hitting something on the card in a few spots.

 

[eharmon]

I grabbed the PrimaryINIT and SecondaryINIT code out of the ROM.. your ROM Fiend made it easy to mostly grab just the code portions out of the ROM file. I then disassembled it using Resourcerer as well as another tool I found online which resulted in near similar results. (Ghidra UI is just so annoying I didn't use it).

The SecondaryINIT didn't look very interesting. Just the usual stuff as outlined in the Designed Cards and Drivers book.

The PrimaryINIT also starts off doing the usual stuff (checking slot manager version, reading the SPRAM for the slot, etc). But there's a lot more in there including from what I saw at a glance that it's accessing something in the slot address space but higher in memory (beyond the frame buffer). It seems to be setting values there so probably interacting with something in the card, registers or something.

I did get to a point though where I noticed the PrimaryINIT that I grabbed from ROM Fiend actually has what looks to be non-code blocks embedded. The other issue is that I found a branch instruction that jumps to a location that is in the middle of an OR instruction. That's really weird. And I found some cases of BTST instructions that are operating on the same register (ie. BTST D7, D7) and no subsequent Z flag check which also looked weird. I verified I did grab the bits from the ROM intact so not sure what happened as this code seems wrong.

But still working my way through it to see if I find anything interesting. But it does look like it's hitting something on the card in a few spots.

Nice! That's about where I trailed off so I think you're getting beyond where I paused. My belief was the PrimaryINIT basically directly controls the registers from memory-mapped IO, same as yours. I would assume it just needs to configure the RAMDAC, which has public data sheets...but there's a chance it also needs to adjust the scrollable region the ASICs are driving. I wish we had an 1152 or 1600 ROM to compare with...it'd probably make it pretty obvious based on the differences.

It's worth double checking if the INIT code lengths are "plausible" -- RF tries to guess at the correct length based on other data in the ROM, but afaik nothing truly describes its length, iirc. Instead, it's up to the code to never jump beyond its extent, and the rest of the ROM to declare nothing in that region. So the guesses can be off by even a few hundred bytes in some cases.

 

[jmacz]

Yeah, I just don't understand that branch statement. It feels the disassemble broke there but I'm looking at the raw hex and it looks correct. So I'm scratching my head.

As for the rest, the code looks to have ended before what RF thought was the end - which is fine. But there's also 2/3rds of the way through the PrimaryINIT that looks like data instead of code. The functions surrounding it look obvious as it saves registers at the beginning and restores them at the end before returning, so those look valid. But I see a weird chunk in the middle where it looks like data.

 

[eharmon]

Yeah, I just don't understand that branch statement. It feels the disassemble broke there but I'm looking at the raw hex and it looks correct. So I'm scratching my head.

As for the rest, the code looks to have ended before what RF thought was the end - which is fine. But there's also 2/3rds of the way through the PrimaryINIT that looks like data instead of code. The functions surrounding it look obvious as it saves registers at the beginning and restores them at the end before returning, so those look valid. But I see a weird chunk in the middle where it looks like data.

I don't think there's any reason the INIT can't have data mixed in that's read by the rest of the code, so it's plausible. But you mean it looks like there's a function entry point and return with a non-68k stream in between?

 

[Trash80toHP_Mini]

I've been looking at this thread on and off, still scratching my head. So the 1360 won't run 1600x1200/8bit in the SuperMac Thunder II series? Both the 1152 and 1360 versions of the Radius Thunder IV GX will do that if you can believe LEM? I lucked into a mis-listed 1600 for a song something like ten years ago and so haven't given any of these cards much thought.

 

[jmacz]

I don't think there's any reason the INIT can't have data mixed in that's read by the rest of the code, so it's plausible. But you mean it looks like there's a function entry point and return with a non-68k stream in between?

No, the stuff I think is data looks to be neatly placed between functions. It's just the disassembler thought it was code and came up with some crazy stuff but that part's fine.

The issue is a branch statement that I'm seeing inside what definitely is code but the address it jumps to is in the middle of an OR instruction...

0000005e : 257c 0000 e0c0 0068 MOVE.L   #$0000e0c0,+104(A2)
00000066 : 95fc 0010 0000      SUBA.L   #$00100000,A4
0000006c : 002e 0004 ffc7      ORI.B    #$04,-57(A6)
00000072 : 6100 00e4           BSR      $00000158

That final BSR goes to:

00000150 : 8080                OR.L     D0,D0
00000152 : 8080                OR.L     D0,D0
00000154 : 0080 8000 0c6e      ORI.L    #$80000C6E,D0
0000015a : 0523                BTST     D2,-(A3)

Basically within the ORI.L. And those two OR.L's look strange.

Actually, now that I look at it, I think something got screwed up -- there must have been a data block in there somewhere because that 0523 was a board identifier for SuperMac elsewhere in the code and the preceeding 0c6e is a CMPI instruction... so I think something shifted by 2 bytes somewhere higher up.

So the 1360 won't run 1600x1200/8bit in the SuperMac Thunder II series?

I'm not sure if @eharmon is trying 24bit or 8bit at that resolution. I'm personally trying to get 1280x1024 working. Card supports 1280x960 and 1360x1024 both at 24bits.

 

[MacOSMonkey]

Looking at your data, the first long appears to be the resource length...and that would be typical. Every sRec starts with its length as a long.

For example:
Apple 13: 0x72 = 118 bytes; Length: 117 bytes + 1 pad
SuperMac 19": same
Through RasterOps 12", it's either 112 or 114 bytes. Again, there's probably a padding byte that is missing...would have been word-aligned.
Then, Radius is correct at 0x6A or 106 bytes.
SuperMac 1280x960 is correct with padding at 118 bytes.
SuperMatch 1360 is correct at 120 bytes (no padding/even)
1360 Compatible mode is correct at 114 byes (no padding/even)

The next byte tracks the config resolution and refresh rate (so...clock?). The 13" is 0x06. The 19" 60Hz is 0x0c. The 19" 75Hz ones are all 0x0d - important clue. The 1152's are all 0x0e. The 1360's are both 0x0f (note: ascending -- and historical -- order)...and the 1280x960 is 0x1f, which says that it was probably added late in the game (excepting the earlier 1280x960 mono/TTL SuperView? monitors -- I think). Anyway, curiously, the 0x1f value may mean that there are 16 other timing groups between the 1360s and the SuperMatch 1280x960 config...or it could have just been a convenient config bump/descriminator with an added buffer. If you are hacking sRecs, try changing this byte to a different value for confirmation (timing issue).

I think you are on the right track modifying the 1280x960 resource. Since you guys are seeing a VDT of 1024 on a 960 pixel screen, it likely means that the vertical timing is wrong and SMT02 has been set up to display 960 lines. However, the OS thinks there are 1024.

 

[jmacz]

Well we have two resolutions to get through... I want 1280x1024 and @eharmon wants 1600x1200 at 24bit

Thanks for the tips!

 

[Arbee]

That final BSR goes to:

00000150 : 8080                OR.L     D0,D0
00000152 : 8080                OR.L     D0,D0
00000154 : 0080 8000 0c6e      ORI.L    #$80000C6E,D0
0000015a : 0523                BTST     D2,-(A3)

The 00 80 80 00 is part of some data block. If you start the disassembly from $158 it should be valid code.

 

[jmacz]

The 00 80 80 00 is part of some data block. If you start the disassembly from $158 it should be valid code.

Yup. I think there are more of these, will need to mark those sections as data before disassembling.

 

[eharmon]

Well we have two resolutions to get through... I want 1280x1024 and @eharmon wants 1600x1200 at 24bit

Thanks for the tips!

I wouldn't mind 1280x1024 too...the only monitors I have for my Macs are 1280x1024 and 1920x1200...call me unlucky!

1600x1200 might still be a stretch for the hardware...but it seems in-spec. I'm not really sure what was different about the 1600 version besides the 13w3 connector. There's sufficient memory and the RAMDAC clocks high enough, iirc.

There's also the mystery of 1080p support -- it seems like it's present in the card, but I can't tell what it's looking to sense to provide those options. God knows what timing it outputs...I'm not sure what 1080p broadcast was expecting in the wild early days of 1993.

But I digress...

My original plan was to replace the mostly-useless resolutions with a few modern resolutions in those slots.

I need to read through the data sheet for the RAMDAC. It should be possible to work backwards from the timing configuration it expects to try to find matching data regions to try to decode the tables (basically working the other direction from disassembly).

 

[eharmon]

I've been looking at this thread on and off, still scratching my head. So the 1360 won't run 1600x1200/8bit in the SuperMac Thunder II series? Both the 1152 and 1360 versions of the Radius Thunder IV GX will do that if you can believe LEM? I lucked into a mis-listed 1600 for a song something like ten years ago and so haven't given any of these cards much thought.

Nope, that was a Radius feature, I guess. 1360 won't exceed 1360, it's quite odd really.

 

[zigzagjoe]

You will want to focus efforts on the ASIC (unfortunately). The RAMDAC is just 3 fast DACs with CLUT, and possibly gamma hardware. Your ASIC is what sets up pixel clocks, number of bytes per line, offsets, porches, sync times, polarities, etc as well as orchestrating actually getting that data *into* the RAMDAC at those specific intervals.

DeclROM structures are for telling Mac OS how to interface to your card, but the actual setup of the card hardware has to be done in code, so taking apart the PrimaryInit is a good first step. Driver Open and Control routines would be next in line, but likely harder to understand.

The configuration of the ASIC could be located in a number of places. It is often done in the primaryinit using tables baked into DeclROM structures, or possibly values baked directly into the code, but it may also be done in the driver. Possibly in multiple places, especially if dynamic resolution changes are done. Looking at the vpBaseOffset and vpRowBytes in DeclROM will give some hints towards the memory organization programmed into the DAC; keep in mind that it may not be exactly pixels (and bytes) per line but instead divided by powers of two. Those values may also be split across multiple registers (low and high bytes) since the hardware might not be natively big endian.

While you're looking around, searching for SwapMMUMode can give you a strong tell when registers are being touched. Framebuffer is often first in the card's address space, to allow 24 bit access to work, and above it is registers/ROM which often require 32 bit address mode to access. So, SwapMMUMode will bracket register accesses.

 

[jmacz]

Yeah, I did see what looked like register calls to the SMT02S (the main ASIC), and yeah, they were surrounded by SwapMMUMode calls. Just need to finish disassembling the code.

 

[jmacz]

I'm using an older disassembler (dis68k) that has bugs (found and fixed two of them). Was looking at the v3 Thunder II 1360 ROM on a flight and assuming the PrimaryINIT code starts at $00000000, the code and data segments seem to be:

00000000,00000148,code
00000148,00000158,data
00000158,0000020e,code
0000020e,00000308,data
00000308,000003d6,code
000003d6,0000043a,data
0000043a,00000558,code
00000558,00000596,data
00000596,00000698,code
00000698,000006b6,data

Aside from the usual stuff, the code looks to be accessing a few offsets (off the slot base address) that are outside of the frame buffer. The calls look like reads and writes to long values. A few calls look to be polling for values also. But most of the calls are going to offset +$0c000000. There are some also to offset +$0d0e0000, +$0d0b8000, +$0d0a8000, and +$0e000600. I am guessing those are two ICs.

The calls to these offsets are in the following code segments (offsets from the start of the PrimaryINIT):

• +$0c000000
  • 00000308
  • 0000043c
  • 0000046a
  • 000004a6
• +$0d0e0000
  • 0000016e
• +$0d0b8000, +$0d0a8000
  • 000004da
  • 00000596
  • 0000063c
• +$0e000600
  • 0000050e

Unless I screwed something up, there's a opcode I don't recognize ebc3, specifically:

• ebc3 07c1
• ebc3 0781
• ebc3 0741
• ebc3 0701
• ebc3 06c1

bfexts?