• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Running the Thunder II 1360 at 1600x1200

jmacz

Well-known member
Looking at the above, the two options for 1280x1024 in the Thunder 4 GX ROMs are:

1280x1024 #1:

Code:
04000500 001F0057 0197019F 00020024 04240427 000500F0 00153C10
H:
001F - 31 * 8  = 248  ... or 31 * 4  = 124
0057 - 87 * 8  = 696  ... or 87 * 4  = 348
0197 - 407 * 8 = 3256 ... or 407 * 4 = 1628
019F - 415 * 8 = 3320 ... or 415 * 4 = 1660
V:
0002 - 2
0024 - 36
0424 - 1060
0427 - 1063

1280x1024 #2:

Code:
04000500 002F0057 0197019F 0003002E 042E0435 00050030 000FE41F
H:
002F = 47 * 8  = 376  ... or 47 * 4  = 188
0057 = 87 * 8  = 696  ... or 87 * 4  = 348
0197 = 407 * 8 = 3256 ... or 407 * 4 = 1628
019F = 415 * 8 = 3320 ... or 415 * 4 = 1660
V:
0003 = 3
002E = 46
042E = 1070
0435 = 1077
 

nyef

Well-known member
I didn't see the obvious second set of resolutions in the same dump above. So each record looks to be 28 bytes, not 56 bytes... red columns below showing the resolutions.. green box representing a single record (best guess based on the appearance of the data). After the resolution, first set of 8 bytes seems to be horizontal timing, second set of 8 bytes seems to be vertical timing, not sure about the third set of 8 bytes.
Okay, first off, it's very easy to determine that the horizontal timings are in units of four pixels. The first half of the third set of 8 bytes seems to be some sort of flags (the 24th byte takes on values of $30, $c0, $f0, $f3, and $f8), possibly coarse scaling of the pixel clock multiplier and maybe sync polarity. But then we get to the two 640x480 modes:
Code:
01E00280 00170023 00C300C7 00010021 0201020C 000500F0 000FA91D
01E00280 000F0027 00C700D7 00020029 0209020C 000500F0 00132510
We'll take HTOT * VTOT * 4 on each to get total pixel clocks per frame: 104276 and 112660, respectively. These numbers are within 10% of each other. Now, presumably one of these is a 60Hz mode and the other a 75Hz mode, which means that one of them has approximately 4/5 the total clock periods per second of the other, and the last four bytes of each entry have approximately that relationship ($fa91d is 1026333, $132510 is 1254672).
 

Arbee

Well-known member
Yeah, the CRTC horizontal timings are indeed in 4-pixel units. That's fairly common, and I've even seen 8-pixel units on other chips.

Also, I dropped Bolle's 1600 ROM into MAME and the card then IDed as a 1600 and 1600x1200 in millions of colors. I was kind of rooting for it to be something sneakier where you could change a jumper, but swapping the ROM is even simpler.
 

jmacz

Well-known member
Also, I dropped Bolle's 1600 ROM into MAME and the card then IDed as a 1600 and 1600x1200 in millions of colors. I was kind of rooting for it to be something sneakier where you could change a jumper, but swapping the ROM is even simpler.

Nice!! Lots of progress on this thread. :)

I think @olePigeon had a Thunder II GX 1600 but I think he sold it. Would have been nice to get that ROM dump. I may have to start looking into it getting a 1600x1200 LCD.
 

eharmon

Well-known member
Writing directly to the registers with Macsbug works, for the II they're mapped with 2 bytes of padding in between:

$dc000002 - HES
$dc000006 - HEB
$dc00000a - HSB
$dc00000e - HTOT
$dc000012 - <unknown>
$dc000016 - VES
$dc00001A - VEB
$dc00001E - VSB
$dc000022 - VTOT

Now I just need to work out the right horizontal settings...while typing blindly whenever I blank the display.

EDIT: I tried converting the horizontal settings from the IV listed above...no dice:

HES: 124 / 8  = 15.5 = 0010
OR 188 / 8 = 23.5 = 0018
HEB: 348 / 8  =  43.5 = 002C
HSB: 1628 / 8  =  203.5 = 00CC
HTOT: 1660 / 8  =  207.5 = 00D0

Compare with the original:

HES: 120
HEB: 240
HSB: 1520
HTOT: 1608

The pixel clock is quite high for the original 1280x960 mode on the II, $1F, maybe that's causing weirdness?

I've cloned VESA modes before, but these using slightly different parameters I haven't worked out the conversion math yet...I'll review the thread again.

EDIT2: No I'm just using Macsbug wrong, somehow, or this just doesn't change on the fly correctly. I'm gonna set up VNC on this computer so I can still see after I break stuff...
 
Last edited:

eharmon

Well-known member
Nice!! Lots of progress on this thread. :)

I think @olePigeon had a Thunder II GX 1600 but I think he sold it. Would have been nice to get that ROM dump. I may have to start looking into it getting a 1600x1200 LCD.
We already chatted awhile back and:
I sold my card, sorry.

Maybe one will turn up again and we can have 1600 support without hacks :).
 

jmacz

Well-known member
EDIT2: No I'm just using Macsbug wrong, somehow, or this just doesn't change on the fly correctly. I'm gonna set up VNC on this computer so I can still see after I break stuff...

Do you have a second video card? Was so much easier when I went with a dual monitor setup. I still have a week to go before I am back in front of my machine.
 

eharmon

Well-known member
Do you have a second video card? Was so much easier when I went with a dual monitor setup. I still have a week to go before I am back in front of my machine.
I only have one HD15 adapter…haha I should probably get another one.
 

jmacz

Well-known member
Writing directly to the registers with Macsbug works, for the II they're mapped with 2 bytes of padding in between:

$dc000002 - HES
$dc000006 - HEB
$dc00000a - HSB
$dc00000e - HTOT
$dc000012 - <unknown>
$dc000016 - VES
$dc00001A - VEB
$dc00001E - VSB
$dc000022 - VTOT

I don't think it matters given the values you are using, but note that when I was debugging my Spectrum 24 series V (uses an SMT02-S) I had thought the registers were 32bit values with no padding in between beginning at offset $c000000. Just mentioning since it looks like you're playing with the lower 2 bytes and seeing a 2 byte padding in between. Again, given the range of values you are using, it shouldn't make a difference.
 

Arbee

Well-known member
Since they're somewhat related, I'll mention that I just finally figured out how the horizontal works on the Spectrum PDQ (and probably several other SuperMac cards).

For 1024x768 @ 75 Hz, the values written are
HES: 5
HEB: 13
HSB: 80
HTOT: 82

The magic is to add 3 to HEB. So (80 - (13 + 3)) * 16 = 1024. The +3 to HEB holds for all of the modes it supports (832x624, 1024x768, and 1152x870).
 

MacOSMonkey

Well-known member
The values after HTOT and VTOT are going to be the counters...and I think they are read only. So, if you poll them, you will see them turning over. HCNT follows HTOT and VCNT follows VTOT.

Also, no reason to type blindly -- hook up the Thunder as a secondary screen. ;-)

I think in the TMS34061, the pixel clock was x16 -- maybe in the Spectrum/8 days, etc. But, yes -- that's right -- SMT is x4 for improved/most compatible timing support.
 
Last edited:

Arbee

Well-known member
I had the thought of trying to get an idea of the ASIC revisions, but photos of these cards where you can read the chip numbers aren't always easy to find.

SpecPDQ is SMT01 and BSR02 http://bitsavers.org/pdf/apple/nubus/supermac/Supermac_Spectrum_PDQ_1.27/SpectrumPDQ_F.jpg
Thunder 24 is SMT02 and BSR03 http://bitsavers.org/pdf/apple/nubus/supermac/Supermac_Thunder_24/Thunder24_F.jpg
Thunder II is SMT02B (I think, the photo's not super clear) and BSR03 https://wiki.preterhuman.net/images/0/0e/Thundergx2.jpg
 

jmacz

Well-known member
I had the thought of trying to get an idea of the ASIC revisions, but photos of these cards where you can read the chip numbers aren't always easy to find.

SpecPDQ is SMT01 and BSR02 http://bitsavers.org/pdf/apple/nubus/supermac/Supermac_Spectrum_PDQ_1.27/SpectrumPDQ_F.jpg
Thunder 24 is SMT02 and BSR03 http://bitsavers.org/pdf/apple/nubus/supermac/Supermac_Thunder_24/Thunder24_F.jpg
Thunder II is SMT02B (I think, the photo's not super clear) and BSR03 https://wiki.preterhuman.net/images/0/0e/Thundergx2.jpg

The Thunder II uses SMT-02S.

The same chips (SMT-02S and BSR03) are used on the Spectrum 24 series IV and series V as well.

Spectrum 24 PDQ+ uses SMT-02 (non-S) but uses BSR03.
 

jmacz

Well-known member
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.
 

MacOSMonkey

Well-known member
SMT01 worked...but was very buggy. Very sensitive to timing and had issues decoding properly in slot $b. If you sneezed on it, it could crash. SMT02 fixed those issues. Similarly, there were problems and crashing issues with the original BSR02 that were corrected in BSR03. SQD was very solid. It had a crazy number of test vectors (1M+?) as I mentioned in an earlier post. I think there was also a Squid Jr. -- maybe for the 8-bit boards? I would have to think about it and look at the board ICs.

The Thunder class boards are basically the same design. Mostly just marketing naming to bamboozle the users and create product SKUs.
 

MacOSMonkey

Well-known member
Based on the info I have previously posted, the addresses and access should be as follows:

Given a base of Superslot (e.g. $d0000000 as in eHarmons post above) + $c000000, the timing-related register offsets should be:

SMT register offsets (words or longs -- take your pick -- either should work):
HES equ $00
HEB equ $04
HSB equ $08
HTOT equ $0c
HCNT equ $10
VES equ $14
VEB equ $18
VSB equ $1C
VTOT equ $20
VCNT equ $24
VINT equ $28 (follows VCNT as in the TMS34061)

The operation to write the data value is a long write of word-based data value. (unless you are storing the data as longs, of course)

So, when you want to write the values to SMT, you can either store and use them as long values, or store them as words -- but either way, you are doing long writes. Just make sure that you don't have data typing issues and that if you are doing long writes of word values in assembly that you first clear the intended data register so that the upper word is 0; It may or may not matter, but it's good practice and makes for easier debugging.

Assumptions:
(assume the correct SMT address is in A0 as $Sc000000)
(assume start of data is HEB at offset $0)
(assume the ptr to an ordered array of word-based SMT values is in A1)
(you could put -1 in the locations for the counters and VINT as flags to mark skip/exit conditions)
(your data would look like: [hes,heb,hsb,htot,-1,ves,veb,vsb,vtot,-1,-1 or ?,-1])
(assume maxAddr equ $0028 ; VINT - maybe you want to set VINT in which case the max would be $002c)
(assume you are writing the SMT registers in order from the array in A1)

Code:
WriteSMT
           ; entry code goes here
           moveq.l    #0,d0   ; clear d0
next       move.w     (a1)+,d0 ; get the next smt value from the data array
           bmi.s      @skip  ; if -1 (N flag set after move), skip it, otherwise, do the write

write      move.l     d0,(a0) ; write and increment destination register
                                        ; or post-increment and branch here if you want

skip       adda.l     #4,a0 ; increment the address
           cmpa.w     #maxAddr,a0  ; check to see if we are at the end (word, not long because of slot address)
                                                  ; subtracts source from destination, so negative if not at yet max address
           blt.s      @next ; keep writing until done
exit                ; exit code goes here
           rts      ; exit when all done

There are obviously a lot of ways to skin the SMT cat -- assembly, C, etc. For example, if you didn't want to use the flag method shown above and wanted to update values in any order, you could use an array of address offsets matching the data storage order. Then, get the offset, get the data and write it to the offset, etc. Whatever works. ;)
 
Last edited:

MacOSMonkey

Well-known member
A couple of other details: The counter registers should be read-only. So, writes to those registers should be ignored, but I have never tried to write to them. :D And, now that I think of it, the VINT function should be the same as TMS34061. The point of VINT was to set a value that would trigger a host interrupt when VCNT = VINT.
 

eharmon

Well-known member
Heh good point, I should have noted in my post it was slot D-specific!

Thanks for the count details, that makes a lot of sense! If I'm bored tomorrow I might refine my crappy peek/poke hack to let me push entire configurations in one go to rapidly test timings for the chosen resolution.
 

MacOSMonkey

Well-known member
@eharmon - sure - happy to help! :)

I was thinking about this problem last night, and coming at things from a different engineering direction, focusing on the CLK-02 (or CLK-0?) IC might be helpful. We know certain things about it. It is the clock synthesizer (in the lower right-hand corner on the original Thunder/24 board) -- and it's labeled CLK-02. Instead of trying to iterate on timing, it might be faster and more certain to characterize the behavior of CLK-0x.

I have posted historical clock frequencies in other posts. But...the main thing of interest is connecting the CLK-02 output frequency to the sRsrc configuration/setup value -- that first byte after the length. The first point of verification is that if you change the value and the clock changes, then it's a known entity.

After a certain point in time, 60Hz configurations were out because of fluorescent lighting interference/oscillation (and vendors like Sony/Hitachi switched to 75Hz). So, SuperMac would have tried to avoid implementing future configs at 60Hz. The transitional point for this change was at the Series III boards (Spectrum/8 III and Spectrum/24 III).

-Looking at the sRsrcs, the CLK-02 values (1st byte after the length in the sRsrc, as in my earlier posts) are as follows:

$0c: 1024x768 60Hz = 64Mhz
$0d: 1024x768 75Hz = 80Mhz (various timings -- SuperMac, RasterOps, etc.)
$0e: 1152x870 = 100Mhz (various 21" configs)
$1f: 1280x960 = ? If it's 75Hz, then it's likely going to be in the 129Mhz range - maybe? If it shipped, it should hopefully be 75Hz. If 60Hz, then it will be less. Is it indicated as 60Hz in SuperVideo 3?

However, with its custom ICs, SuperMac would have planned for headroom for larger configs in CLK-02 (or maybe they had to spin it) and there were larger displays available at the time -- just not characterized or integrated as product SKUs. For 12890x1024, it could have been a 60Hz issue or also a next-gen marketing decision to get people to upgrade to the Thunder II, etc. boards. Either.

The sequential implications of the resolution progression are that $0f is the next in the sequence and 1280x1024/960 is the next step. Since the shipped clock value for 1280x960 is $1f, then that must mean that $0f is for something else...and that something else could have been 1280x1024 -- maybe at 60Hz, which is why $0f wasn't used -- or it just wasn't right (again pointing to a possible spin if the Thunder II/IV have updated CLK ICs). The odds point at $0f for 1280-something.

Anyway -- assuming the first byte controls the clock, if someone would like to scope the output of CLK-0x to confirm the frequencies -- it should be possible to match the above known configs. Then, the next logical thing to do would be to plug in sRsrc values of $0f-1f to characterize the output frequencies of the CLK chip. It doesn't matter what the screen shows -- don't even connect a monitor -- just look at the frequency output on CLK-02. And, knowing the frequencies, it should then be simple to set up the modified timing (and choose the best clock value). Supported configs may go higher than $1f -- that's also something to test.

As above, the Thunder II and Thunder IV boards may have an updated CLK IC. I haven't looked/don't know. If so, then it would be good to characterize it vs. the CLK-02 on Thunder/24. And, if it's a new version, then the spin might have been for 1600x1200 support (not available in 1991 when CLK-02 appeared), since that was the max config.

Also -- one edit -- looking at the earlier SMT discussion of x16, x4, etc. It looks like SMT is x8, where there are 8 pixels displayed for a visible area of 160 at a horizontal resolution of 1280 that adds up to an HTOT of 201. So, if correct, each change to a blanking value should move the margin by 8 pixels vs. 16 or 4.
 

Arbee

Well-known member
Thunder IV uses an off-the-shelf IC Designs ICD2062B, which takes 3 parameters in 21 bits to program the PLL against a 14.31818 MHz reference. The actual chip you feed the numbers in via a 2-wire serial interface but the Thunder IV's ASIC makes it so you just write a 32-bit word and the 21 bits are magically sent to the chip.

I wouldn't be surprised if the SuperMac CLK-02 was a remarked version of the chip the Micron XCEED cards used where a small mask ROM determines the frequencies and you just tell it a number between 0 and 31.

ETA: Just checked the preterhuman Thunder II photo and it seems to say "CLK03 ICS1494" which would indeed be the Micron XCEED chip.
 
Last edited:
Top