Running the Thunder II 1360 at 1600x1200

[eharmon]

Based on what @MacOSMonkey provided previously on the SuperMac ROMs thread, and from my observations debugging some of these cards, here's a list grouped by similarity and in chronological order (of the ones I have had access to):

• Spectrum 24 Series III
  • SMT-01 and BSR-02
• Spectrum 24 PDQ
  • SMT-01 and BSR-02
• Spectrum 24 PDQ+
  • SMT-02 and BSR-03 and SQD-01
• Spectrum 24 Thunder 24
  • SMT-02 and BSR-03 and SQD-01
• Spectrum 24 Series IV
  • SMT-02S and BSR-03 and SQD-01
• Spectrum 24 Series V
  • SMT-02S and BSR-03 and SQD-01
• Thunder II
  • SMT-02S and BSR-03 and SQD-01S (not positive on this one)

The PDQ+, Thunder 24, Series IV, and Series V that I have handled had almost nearly identical board layouts. Some revisions were different but the revisions I handled were nearly the same.

Double checked my II and it has:
- SMT-02S, BSR-03, a sticker over the SQD I don't feel like peeling off, and a 50MHz oscillator. The board on higher intellect has a slightly different sticker with a silkscreen sticking out that strongly implies SQD-01S: https://wiki.preterhuman.net/images/0/0e/Thundergx2.jpg

I have noticed in the past that Thunder/24 seems to have a 40MHz oscillator, so I suspect the II runs 25% faster clocks? S is for speed?

@MacOSMonkey My II has a CLK-03.

 

[MacOSMonkey]

@Arbee -- Thanks for looking that up on the Thunder IV. Yeah - good point about CLK-02. Could be.

14.31818MHz is also the frequency used by NTSC, but is called out in the ICD2062B spec.

 

[Arbee]

To follow up, the ICS chips were available with custom mask ROMs so the frequency selection varies from chip to chip. Micron's version had $0C as 34 MHz and $0D as 36 MHz up to $1F being 125 MHz so it clearly wasn't the same table.

 

[MacOSMonkey]

@eharmon -- Great -- so that pins down the clock devices, as follows:

Thunder/24 flavor boards (including PDQ+) are CLK-02
Thunder II boards are CLK-03
Thunder IV are ICD2062B

 

[Arbee]

14.31818 was a common base frequency for early frequency generators because ISA slots had a clock at that rate on one of the pins.

 

[eharmon]

Here's the data sheet for CLK-03/ICS1494: https://www.ardent-tool.com/datasheets/ICS_ICS1494.pdf

Obviously, that wouldn't reflect any customizations.

 

[Arbee]

That data sheet doesn't even say what the stock mask ROM frequency table is, either. Fortunately the Micron XCEED technical docs PDF includes a copy of the table they used on PDF page 47.

 

[eharmon]

That data sheet doesn't even say what the stock mask ROM frequency table is, either. Fortunately the Micron XCEED technical docs PDF includes a copy of the table they used on PDF page 47.

Ah found that! Looks like their custom part was -536, and Thunder II was -543, so I think that's more confirmation they're different tables.

Seems like I can just bit-bang it with a scope hooked up to determine each value, but I'll have to find some time to do that.

That said, the ICS1494 only advertises 135MHz performance, as do the RAMDACs, which is kinda slow for 1600x1200? Doubt the official 1600 card was overclocking them...

 

[eharmon]

Found the table in the 1994 ICS data book on bitsavers:

 

[Arbee]

Excellent find @eharmon! I wonder which Radius card(s) used the ICS now.

 

[jmacz]

@eharmon -- Great -- so that pins down the clock devices, as follows:

Thunder/24 flavor boards (including PDQ+) are CLK-02
Thunder II boards are CLK-03
Thunder IV are ICD2062B

Although my Spectrum 24iv has the CLK02, I have seen pictures of a Spectrum 24iv with a CLK03. I believe my Spectrum 24v has a CLK03. So some of the Thunder/24 flavor boards had a CLK03.

 

[eharmon]

Poking values into the registers at runtime, I've got a centered display with no missing edges with:
HES: 31 (1F)
HEB: 35
HSB: 205
HTOT: 211

But my monitor pulls sync at 68Hz, whereas I'm pretty sure this is meant to be a 67Hz mode. As a result, there's some edges on either side.

So far I can't quite get the hang of how the geometry changes with each of these values.

 

[jmacz]

Poking values into the registers at runtime, I've got a centered display with no missing edges with:
HES: 31 (1F)
HEB: 35
HSB: 205
HTOT: 211

But my monitor pulls sync at 68Hz, whereas I'm pretty sure this is meant to be a 67Hz mode. As a result, there's some edges on either side.

So far I can't quite get the hang of how the geometry changes with each of these values.

Should it be 60Hz?

 

[MacOSMonkey]

Great job! And I definitely now remember Ardent and masking upon seeing this discussion. The 130.48Mhz frequency for $0f probably translates to 1280x1024 at 7xHz (and possibly a 16x multiplier). And, the different mask versions probably just indicate an extension of the same setup. The base frequencies would have to be the same to support existing products. So, CLK-02 and CLK-03 as ICS1494 should produce the same frequencies at the same index.

Also, the issue of the max clock frequency is altered by the pixel multiplier, as above. So, for example, the board appears to be x8 for some configs and may be x16 for others -- 1600x1200? The clock divider is set in SMT somewhere. The best way to figure this out would be to look at the sRsrc values for the timing, figure out the multiplier and then look to see which subsequent values in the word-based SMT data might be different.

One more edit:
Horizontal Active Area (HSB-HEB) values to use as ballparks for sRsrc data -- maybe depending on which board:
1024: 64 (x16), 128 (x8)
1152: 72 (x16), 144 (x8)
1280: 80 (x16), 160 (x8)
1600: 100 (x16), 200 (x8)

For example, in eHarmon's timing for 1280, HSB-HEB is 170 (a little bit too wide - should be 160), but clearly a x8 multiplier and not x16. @eharmon -- you might be able to fix the problem by adjusting the visible area and retiming the other values (is HES too high?) -- or it could just be that it's a stretch for the timing requirements of the monitor based on the input clock frequency. Does the monitor have size adjustment controls? In the more customized case, now that things are better identified, you could theoretically lift the output pin on the ISC1494 and input whatever clock frequency you want from a mini-breadboard that optimally matches your monitor timing. It would be a cool Thunder hack.

The lower the resolution, the lower the multiplier. For example, resolutions like 640x480 and 512x384 may use a x4 multiplier.

And, on an unrelated note, another clue in decoding SMT programming might be to compare interlace configs like NTSC vs. normal to look for sRsrc config differences -- like for NTSC serration, etc.

 

[eharmon]

Should it be 60Hz?

60 is ideal for LCDs, but 67 works fine. If we can better figure out the timing multipliers we might be able to get 60.

Great job! And I definitely now remember Ardent and masking upon seeing this discussion. The 130.48Mhz frequency for $0f probably translates to 1280x1024 at 7xHz (and possibly a 16x multiplier). And, the different mask versions probably just indicate and extension of the same setup. The base frequencies would have to be the same to support existing products. So, CLK-02 and CLK-03 as ICS1494 should produce the same frequencies at the same index.

Also, the issue of the max clock frequency is altered by the pixel multiplier, as above. So, for example, the board appears to be x8 for some configs and may be x16 for others -- 1600x1200. The clock divider is set in SMT somewhere. The best way to figure this out would be to look at the sRsrc values for the timing, figure out the multiplier and then look to see which subsequent values in the word-based SMT data are different.

I see! That makes sense.

There's one outstanding problem, which is that I just can't seem to get the VRAM to initialize correctly. It's like I'm now getting an unusual shape like 1360x960...at first that wasn't a big deal because the OS was painting the bottom 64 pixels...but the extra pixels on the side are being written into the horizontal blanking and causing my monitor to stretch the screen to fit -- it was locking in tight to 1280x1024 for a bit but now it's being picky.

I've been making the following edits:

• sResource 1 (Board)
  • sResource 123 (sRsrcVidNames)
    • sResource 149 (1280x960)
      • Pointed at a new resource with the name "1280x1024" in a blank spot in ROM
  • sResource 221 (SuperMatch High-Res 20 Color Timing)
    • HES -> 31
    • HEB -> 35
    • HSB -> 205
    • HTOT -> 211
    • VES -> 2
    • VEB -> 42
    • VSB -> 1066
    • VTOT -> 1069
    • hRes -> 1280
    • vRes -> 1024
• sResource 149 (Display for Video Mode 149)
  • For each sResource 128, 129, 130, 131, 132:
    • set vpBounds(2) to 1024

When I get around to it, I'll just add resources in the blank space instead of replacing 1280x960.

But I can't figure out what's sizing the VRAM initialization. The SMT, SQD, BSR data is basically the same for all timings so it's not those.

 

[MacOSMonkey]

Sorry - I edited my post above to add some additional info. Your HSB-HEB should be 160 @ x8 (active area) and HES may be too high, but it depends on the expected monitor timing.

 

[eharmon]

Sorry - I edited my post above to add some additional info. Your HSB-HEB should be 160 @ x8 (active area) and HES may be too high, but it depends on the expected monitor timing.

With:

15
35
195
215

It's damn close. Holding to 160 does avoid the extra data striping the right side.

It's about a pixel off in each dimension, so it could be slightly clearer, but this "feels" close to spec. Both my Dell and Extron are pulling in perfect sync.

EDIT: Definitely shimmers badly on some patterns, sometimes syncs wrong, and still fails to initialize the bottom portion of VRAM at first. Usable for now though, so I burned a ROM before I work on seeing if 1600x1200 will go .

A bspatch is attached if you would like to try the same.

To apply, do the following (macOS):

$ brew install bsdiff
$ bspatch <original.rom> <patched.rom> 1280-patch.bin

bsdiff is usable on all *nix platforms if you're using something else. Then flash <patched.rom> to a new 27C512 or equivalent.

Now you can select any multi-sync monitor that supports higher resolutions (NEC 21XP or SuperMatch High-Resolution 20 Color) and choose the new 1280x1024 option that has replaced 1280x960.

Still just a hacky patch, but if anyone else wants to try it, there you go.

 

[MacOSMonkey]

@eharmon - good! That may be the best you can do. It sounds like you are having clock alignment/rounding issues with the missing pixels.

Here are my morning thoughts: I looked back in the thread and your monitor is the E178FP. From the Dell User Guide, the supported modes are as follows:


So...per the spec...you would ideally need a dot clock of 108Mhz for 60Hz or 135Mhz for 75Hz. According to the ICS1494 table, config $1F is 122.32Mhz. So, coming back to the discussion of the $0f clock selector and likely support for 1280x1024 (my earlier post), you can try setting $0f as the clock selector for 130.48Mhz, which is going to be closer to the spec for 1280x1024 75Mhz (within 3.3%) and your Dell monitor may be tolerant of the deviation...but there's still potentially a rounding issue. The monitor(s) tolerate 122.32Mhz, which is even further away. So...? You may get back the missing pixels.

Looking at the ICS1494-543 config table, the other option in the quest for perfection would be to try to use mask configuration $01 for the sRsrc clock select byte and add an external 135Mhz oscillator. The Thunder II has an additional oscillator pad on it adjacent to the 1431818Mhz refClock. Thunder/24 didn't have this pad, but Thunder II does (extra design flexibility). Just verify that the output is connected to the EXTFREQ/Pin 7 on the ICS1494. If so, the config $01 trick + custom oscillator may work, the timing should be perfect and the other monitor configurations would still work.

Depending on the accelerator interference fit, you might be able to socket the oscillator pad location. This method might offer the best outcome and also point to additional flexibility for screwing around with other timings, like 1600x1200 - or whatever. However, the ICS1494 output is buffered, so if you're not going to add a bypass hack (lift the ICS output and add a switch) the output will still probably have a specified max of 135Mhz.

If you only ever plan to use it in a certain configuration, then just bypass it, with or without a switch. There doesn't seem to be a way to trick the ICS1494 into outputting it's max frequency, which would be a great solution...but...nope.

Just some more experiments to try. Maybe something above will work for you.

Actually -- I was stuck in 75Hz mode. You could also try config $1c and run at 1280x1024 60Hz. $1c is very close to the 108Mhz spec at 107.35Mhz (within 0.6%). May work better and not have pixel issues...but 75Hz would certainly be easier on your eyes and look nicer.

 

[eharmon]

@eharmon - good! That may be the best you can do. It sounds like you are having clock alignment/rounding issues with the missing pixels.

Here are my morning thoughts: I looked back in the thread and your monitor is the E178FP. From the Dell User Guide, the supported modes are as follows:

View attachment 76640
So...per the spec...you would ideally need a dot clock of 108Mhz for 60Hz or 135Mhz for 75Hz. According to the ICS1494 table, config $1F is 122.32Mhz. So, coming back to the discussion of the $0f clock selector and likely support for 1280x1024 (my earlier post), you can try setting $0f as the clock selector for 130.48Mhz, which is going to be closer to the spec for 1280x1024 75Mhz (within 3.3%) and your Dell monitor may be tolerant of the deviation...but there's still potentially a rounding issue. The monitor(s) tolerate 122.32Mhz, which is even further away. So...? You may get back the missing pixels.

Looking at the ICS1494-543 config table, the other option in the quest for perfection would be to try to use mask configuration $01 for the sRsrc clock select byte and add an external 135Mhz oscillator. The Thunder II has an additional oscillator pad on it adjacent to the 1431818Mhz refClock. Thunder/24 didn't have this pad, but Thunder II does (extra design flexibility). Just verify that the output is connected to the EXTFREQ/Pin 7 on the ICS1494. If so, the config $01 trick + custom oscillator may work, the timing should be perfect and the other monitor configurations would still work.

Depending on the accelerator interference fit, you might be able to socket the oscillator pad location. This method might offer the best outcome and also point to additional flexibility for screwing around with other timings, like 1600x1200 - or whatever. However, the ICS1494 output is buffered, so if you're not going to add a bypass hack (lift the ICS output and add a switch) the output will still probably have a specified max of 135Mhz.

If you only ever plan to use it in a certain configuration, then just bypass it, with or without a switch. There doesn't seem to be a way to trick the ICS1494 into outputting it's max frequency, which would be a great solution...but...nope.

Just some more experiments to try. Maybe something above will work for you.

Actually -- I was stuck in 75Hz mode. You could also try config $1c and run at 1280x1024 60Hz. $1c is very close to the 108Mhz spec at 107.35Mhz (within 0.6%). May work better and not have pixel issues...but 75Hz would certainly be easier on your eyes and look nicer.

I'm really starting to grasp how video timing works, thanks for the master class! I think you're right, that should put us pretty close to perfect for VESA timing which any modern monitor should handle (and the Dell tables pretty much match). Seems like the 1600 must have unique hardware or puts out an odd mode like 30Hz, 135MHz just isn't quick enough for 60+. But I'll futz around once 1280x1024 is locked in.

Any idea where the clock register is mapped into memory? If not I think I should be able to determine from the disassembly.

 

[MacOSMonkey]

@eharmon You're very welcome! It has been a looong time since I used to do this stuff - yeesh - ...but it's definitely helping me remember -- especially hearing the name Ardent and seeing the clock docs. I wondered how you came up with the part number, but then I realized from the pictures that it's printed on the device.

It looks like the 1600x1200 config may run at 185Mhz on Thunder IV -- see this old thread/image:
Thunder IV 1600 Config

Also, Thunder II 1600 uses Bt467s (8bit, 170-220MHz). The Thunder IV uses the ADV7152, an 85-220Mhz triple-channel DAC. So, 1600 may not work on the 1360 board because it's using Bt458s with a max spec of 165Mhz. However, on the Bt458, 130Mhz might be enough to run at 60Hz and you could potentially do 75Hz at 165Mhz (within the DAC spec) -- but that's off the end of ICS1494 -- you would need to bypass with an external oscillator.

For starters, try 1280x1024 at 60Hz with $1c and and 75Hz at $0f and see if you see any pixel loss.

The clock base address you're looking for is going to be in the $d000000 range and it's going to be in the disassembly by @jmacz where I highlighted the bfexts. There are going to be a bunch of bit writes. Then, from the spec, the timing shows that you have to drive the strobe while the data inputs are valid to the latch the config. Also, there is a hold time -- so delays before and after strobe.

From the ICS1494 Spec:

Just look for the bfexts instructions that are followed by minimum setup and hold times for the ICS1494 strobe pulse. Let me look at the earlier Primary Init post...OK -- see the disassembly in this post.

Below is the code from @jmacz's disassembly/function_11 that matches the ICS1494 spec - number of bits, setup, strobe and hold. I added relevant comments and changed some of the disassembly notation.

00000654 : 204a                MOVEA.L  A2,A0                                   ; get board base address
00000656 : d1fc 0d0a 0000      ADDA.L   #$0d0a0000,A0               ; a0 = slot base address + $0d0a0000 (base of ICS1494)

; Program all 5 bits of the ICS1494
0000065c : ebc3 07c1           BFEXTS   D3{31:1},D0                     ;  for BFEXTS, decimal field/size descriptors are idiomatic
00000660 : 2140 0004           MOVE.L   D0,$04(A0)                          ; write ICS1494 FS0 (hex offsets are idiomatic)
00000664 : ebc3 0781           BFEXTS   D3{30:1},D0
00000668 : 2140 0008           MOVE.L   D0,$08(A0)                          ; write ICS1494 FS1
0000066c : ebc3 0741           BFEXTS   D3{29:1},D0
00000670 : 2140 000c           MOVE.L   D0,$0c(A0)                         ; write ICS1494 FS2
00000674 : ebc3 0701           BFEXTS   D3(28:1},D0
00000678 : 2140 0010           MOVE.L   D0,$10(A0)                         ; write ICS1494 FS3
0000067c : ebc3 06c1           BFEXTS   D3{27:1},D0
00000680 : 2140 0014           MOVE.L   D0,$14(A0)                        ; write ICS1494 FS4
00000684 : 6100 fabe           BSR      $00000144                   ; branch to Delay_00 *** ICS1494 strobe setup delay ***
00000688 : 4290                CLR.L    (A0)                                 ; *** ICS1494 strobe low ***
0000068a : 20bc 0000 0001      MOVE.L   #$00000001,(A0)  ; *** ICS1494 strobe high ***
00000690 : 4290                CLR.L    (A0)                                 ; *** ICS1494 strobe low *** so the strobe is at the base offset
00000692 : 6100 faa0           BSR      $00000134                   ; branch to Delay_13  *** ICS1494 strobe hold delay ***

So, from the above, the ICS1494 base appears to be at: $Sd0a0000 and the register offsets are:
$00: STROBE
$04: FS0
$08: FS1
$0c: FS2
$10: FS3
$14: FS4

Hopefully, the above is correct and will help move things forward. It looks right, but YMMV. Actually, you should be able to use this stuff in Macsbug to reset the clock in real time. Hmm...interesting.

The ICS1494 datasheet and mask configs were super-helpful! Those docs were great finds!