Running the Thunder II 1360 at 1600x1200

olePigeon

Well-known member
Would it be possible to use the Radius ROM? Bring back 4 and 16 colors which the Radius Thunder II had. Dunno if the cards were still identical hardware-wise after Radius took over.
 

David Cook

Well-known member
Use the slot rom utility: https://www.gryphel.com/c/minivmac/extras/slotrom/

It'll save files next to where it runs. As the transformations needed (address/data bit swaps and inversions, if any) should hopefully be known from the lesser cards, there shouldn't be a need to desolder it from the card.

Here you go. I changed the filename extension from .ROM as it didn't seem like it wanted to upload otherwise.
 

Attachments

  • SlotC.bin
    64 KB · Views: 3

Trash80toHP_Mini

NIGHT STALKER
Would it be possible to use the Radius ROM? Bring back 4 and 16 colors which the Radius Thunder II had.
Might could be, but doubtful that a 1600 ROM would work given results of the one experiment I did with a Radius card to Radius card ROM swap.

Dunno if the cards were still identical hardware-wise after Radius took over.
Short version:
Doubtful, per my digital design mentor @trag it looks to be dependent upon the RAMDAC installed on the card. Looks like the higher end version RAMDAC supported the higher resolution and the lower end version didn't. Dunno if the RAMDACs were pin compatible, but very likely in terms of PCB design/production. RAMDAC seems far more likely than any other method of differentiation I think. Crystal clock rears its ugly head as well.

It makes zero sense for either company to allow a ROM swap to upgrade lower tiers of a card. Upping resolution support of pin compatible RAMDACs along with ROM change as the differentiation makes a world of sense to me.

Long version:
 
Last edited:

eharmon

Well-known member
There were two of these from the seller. I bought the first one (labeled #2 ironically) for $350. The seller messaged me today and said "Bro! Don't open that box. Resell it immediately for $810!" (not his actual words). I thought that was pretty cool of the seller.

Here is the unboxing. I could hear the depreciation as I broke the seal.

The ROM is not socketed. What would you like me to use to rip the ROM? It's version 3.0.3.
Oh wow, that's an incredible deal!
You are a true man of the people.
Seconded!
Here you go. I changed the filename extension from .ROM as it didn't seem like it wanted to upload otherwise.
Awesome! Hopefully will find some time to spelunk through it this week.
 

eharmon

Well-known member
Some observations:
  • Generally the 1600 has reduced horizontal blanking at all resolutions.
  • The first section of the unknown BSR data is different in each timing set. This difference is the same for all timings.
    • 1360: 50020600
    • 1600: 31020600
  • The unknown SMT02 data is slightly different in each timing. This difference is the same for all timings.
    • 1360 @640x480: FFFFFFFF 00BBFFFF 0000FFFF 00000000 00000000 00404000 0C908005 05000000 E0C0B576 256D0000 00000040
    • 1600 @640x480: FFFFFFFF 00BBFFFF 0000FFFF 00000000 00000000 00804000 0C908005 05000000 E0C02576 256D0000 00000080
  • The unknown SQD data is slightly different in each timing. This difference varies per timing but is always different between cards.
    • 1360: 008100F3 0000
    • 1600: 0081007D 0000
  • The RAMDAC clocks are the same for lower resolutions (1360 and 1600 both use 0x0F for 1360x1024 for example).
    • This implies the clock table is the same for lower frequencies across the clock chip types.
  • But, unsurprisingly, the 1600x1200 resolution uses a new clock 0x21 or clock 0x30 (depending on monitor). Presumably these are the faster clocks available on the updated RAMDACs/clocks.
Since the lower resolution data mostly matches, I did try dropping the ROM directly into my 1360, and it does not work properly at any resolution. There are, however, signs of life (desynced pixel data over the video port), so it is possible that these BSR/SMT02/SQD registers just need to be set correctly. Or the reduced blanking is not compatible. I wonder if all BSR/SMT02/SQD revisions on the II hardware supported both types of RAMDACs or completely configurable outputs with these configuration bits selecting accordingly.

This pretty much just confirms what we already knew in the previous discussion. The 1600 uses RAMDAC clocks the 1360 does not support. But it is interesting! I might try rewriting these BSR/SMT02/SQD values for the lower resolutions to match the 1360 values and see if that's sufficient to make the ROM compatible (at lower supported resolutions). I don't see much point in doing that from a practical standpoint, but it would be interesting to know.

EDIT: Actually re-skimming the thread, the RAMDACs do support that speed, but would be overclocked as the 1360 only has 135MHz parts and need 160MHz. But the clock chip presumably can't generate those speeds at all (being completely missing from the tables), per previous posts.
 
Last edited:

eharmon

Well-known member
Extending this (still incomplete) list from way back:
  • Spectrum 24 Series III
    • SMT-01, BSR-02
  • Spectrum 24 PDQ
    • SMT-01, BSR-02
  • Spectrum 24 PDQ+
    • SMT-02, BSR-03, SQD-01
  • Spectrum 24 Thunder 24
    • SMT-02, BSR-03, SQD-01
  • Spectrum 24 Series IV
    • SMT-02S, BSR-03, SQD-01
  • Spectrum 24 Series V
    • SMT-02S, BSR-03, SQD-01
  • Thunder II 1152, 1360
    • SMT-02S, BSR-03 (3x), SQD-01S, CLK-03 (ICS1494), Bt458 (3x) @135MHz
  • Thunder II 1600
    • SMT-02S, BSR-03 (1x), SQD-01S, CLK-??, Bt467 (3x) @220MHz
Sometimes replaced with newer or equivalent parts.
 

joevt

Well-known member
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.*/
Made a fix to SlotsParse to get the timing number for SuperMac Thunder cards which seem to use sVidAuxParams in a non standard way.
https://github.com/joevt/SlotsDump
 

Attachments

  • SlotCParsed.txt.zip
    18.4 KB · Views: 0
Top