Running the Thunder II 1360 at 1600x1200

jmacz

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

Oh, so there might be hardware differences between the Thunder II GX 1600 and the Thunder II GX 1360?
 

jmacz

Well-known member
Just to avoid confusion since we have had a lot of topics in this thread :)

Primary Topic (eHarmon's original post)

Get 1600x1200 @ 24 bits working on a Thunder II GX 1360 because @eharmon had noted the hardware should be the same between the Thunder II GX 1360 and the Thunder II GX 1600, and 1600x1200 @ 24 bits works on the Thunder II GX 1600. My question in the previous post was assessing whether we feel the hardware is still the same between the Thunder II GX 1600 and Thunder II GX 1360 based on the most recent posts.

Second Topic (jmac's unfortunate partial hijacking of the thread)

Get 1280x1024 @ 24 bits working on a Thunder II GX 1360. This is not currently supported but we're trying to hack it into the ROM. And we seem to be making some great progress on this front.

Third Topic (another side thread)

Get a Thunder 4 GX 1360 to be seen as a Thunder 4 GX 1600 both on a real physical card and in emulation on MAME. A ROM exchange resolved the issue on a physical card. And the ROM exchange also got it working on MAME. This topic is complete.
 

MacOSMonkey

Well-known member
Below is a quick comparison of the Thunder II boards and some additional thoughts.

Thunder II GX 1360 pic below with 3x Bt458LPJ135, socketed DIP ROM and a 14.31818MHz clkRef for ICS1494. The DAC is an 85-pin plastic J-Lead package and marked as -135 -- likely indicates the top speed (135MHz).

gx1360.png

Thunder II GX 1600 pic below showing a newer board layout, soldered ROM, 3xBt467 and an extra crystal in the lower right (that may just be a refClock or could be related to 1600x1200 -- can't really see it). Note that Bt467 is not pin-compatible with the Bt458 -- the package below is a 160-pin PQFP (plastic quad flat pack).

gx1600.png

For 1360 vs. 1600 Thunder II boards, the hardware is clearly different. However, that doesn't mean that the 1360 board couldn't possibly work in a 1600x1200 config. The DACs do not appear to be maxed out can could be replaced with a -165 version (165Mhz).

According to Brooktree, the Bt458 can do 1600x1200 -- see the selection guide below (but it might require the -165 version). More research is needed. I don't know that there is another pin-compatible, high-frequency part. So, Bt458LPJ165 might be the only option for a max speed Thunder II 1360, but bear in mind that the ICS1494 clock generator also caps at 135Mhz. So, there would be no point in upgrading the Bt458 unless you also planned (and needed) to bypass the ICS1494 external buffering. FrankenThunder II! There might be something workable with the existing mask frequencies.

bt458-1600.png
Anyway, the boards appear to be different, but 1600x1200 might still be possible with some hacking. If there are Thunder II 1360 and 1600 boards that appear the same, then SuperMac merged the designs either before or after the soldered ROM respin. If anyone has, knows of, or can find a DIP-ROM Thunder II 1600 GX board, please post a hi-res picture of it without the accelerator attached. That would be an interesting thing to see. Otherwise, if there is a Thunder II 1360 design with a soldered ROM, then we know that it can probably be upgraded to a 1600 with a ROM swap because it is likely just a gimped 1600 board with Bt467s on it. That would also be an interesting thing to see if anyone happened to have a picture.
 

MacOSMonkey

Well-known member
@eharmon Below is another snippet of the disassembly from @jmacz 's PrimaryInit post that has the RAM fill. It looks like it either uses a horizontal value of 512 or 256 (which would be rowbytes -- added from d4 to a1). In 1-bit mode, that is either 2048 or 4096 1-bit pixels. The vertical value appears to be $12c0, or 4800 lines (outer loop in d3). It should be enough to prevent garbage at 1280x1024 (which is only 164Kb in 1-bit mode vs. a fill of at least 256 bytes * 4800 lines, or 1.2Mb).

Did you definitely set all the sRsrc vertical values to 1024 from 960? If you missed something that is still set to 960, that might explain why you see garbage at the bottom of the screen...or it could be something else. I commented this disassembly in one of my other posts, but the snapshot below should be good enough.

Code:
;;
;; Some type of memory fill function?
;; Called from: PrimaryINIT
;; This routine is filling RAM with gray

Function_3:
000002c4 : 2f09                MOVE.L   A1,-(A7)
000002c6 : 383c 0200           MOVE.W   #$0200,D4
000002ca : 122e ffc7           MOVE.B   -57(A6),D1
000002ce : 0201 0020           ANDI.B   #$20,D1
000002d2 : 6604                BNE      $000002d8
000002d4 : 383c 0100           MOVE.W   #$0100,D4
000002d8 : 70ff                MOVEQ    #$FF,D0
000002da : 2200                MOVE.L   D0,D1
000002dc : 363c 12c0           MOVE.W   #$12c0,D3
000002e0 : 224c                MOVEA.L  A4,A1
000002e2 : 2049                MOVEA.L  A1,A0
000002e4 : 3404                MOVE.W   D4,D2
000002e6 : 20c0                MOVE.L   D0,(A0)+
000002e8 : 20c0                MOVE.L   D0,(A0)+
000002ea : 20c0                MOVE.L   D0,(A0)+
000002ec : 20c0                MOVE.L   D0,(A0)+
000002ee : 20c0                MOVE.L   D0,(A0)+
000002f0 : 20c0                MOVE.L   D0,(A0)+
000002f2 : 20c0                MOVE.L   D0,(A0)+
000002f4 : 20c0                MOVE.L   D0,(A0)+
000002f6 : 0442 0020           SUBI.W   #$0020,D2
000002fa : 6eea                BGT      $000002e6
000002fc : c141                AND.W    D0,D1
000002fe : d2c4                ADDA.W   D4,A1
00000300 : 51cb ffe0           DBF      D3,$000002e2
00000304 : 225f                MOVEA.L  (A7)+,A1
00000306 : 4e75                RTS
 

eharmon

Well-known member
(Ignoring the other posts for a bit while I catch up)
Code:
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. :p :D 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!
I don't quite follow the strobe in the assembly, it seems to set the values, wait, strobe it low, high, low, then wait again?

The data sheet indicates a 20ns strobe pulse, with 10ns setup and 10ns hold on the frequency select data.

Wouldn't this violate the spec since it's never held high for any significant time?

I'm able to cause a loss of sync (presumably the strobe doing its thing), but it doesn't appear to be accepting the new fs values.
 

MacOSMonkey

Well-known member
Yeah - I might have been a little bit excited there on the code timing. I transposed the post-delay to fit what I was thinking. Looking at it again, I'm not sure those delays do very much, unless it's for some other hardware settling. The 68K instruction timing is slow enough so that the delays shouldn't matter (for the ICS1494). The other possibility is that the post-delay is a non-bug where the delay really should have been during strobe high and not after -- but was never an issue because of 68K timing.

The ICS1494 spec indicates the following:
Strobe Pulse Width: 20ns
Setup Time Data to Strobe: 10ns
Hold Time Data to Strobe: 10ns

If you were to assume better-than-best case 68K of 50Mhz, that's a period of 20ns (max standard Mac was the 840AV @ 40Mhz/25ns). The best case for a move immediate to effective address is 1 clock cycle on the '040 and 3 clock cycles on the '020. So, the only machines that would possibly matter are '040 or later, and even with no delay in the hypothetical case of a 50Mhz '040, the timing would still be OK (including some additional time from the following CLR instruction until the line is seen as logic level 0). So, it would end up as >20ns. The 10ns times are irrelevant, since they are faster than a single clock cycle. There were accelerated cases, but even with a 133Mhz PPC, it would probably still be in the window because of the 68K emulator that required multiple PPC cycles for every 68K instruction (but still a Davidian engineering marvel). Also, the ICS1494 stated timings are worst-case and probably faster.

As above, maybe the delay afterwards is for hardware stabilization at the new clock frequency. I don't know. There were multiple ICs that had to settle.

Just to confirm, when you are writing values to the IC1494 registers, you need to write longs of either $FFFFFFFF or $00000000 (which is the equivalent function of the BFEXTS for a data register destination). The easiest way to test would be to use the board as a secondary screen, write a different config that causes it to lose sync, then write back the original config and see if it resyncs (you may or may not need to power cycle the display). It may or may not work for some other reason, but it looks like the right code because of the 5-bit write followed by an obvious strobe. If it doesn't work from Macsbug, then it might require a dedicated code snippet to do the writes -- perhaps optimally with interrupts disabled.
 

eharmon

Well-known member
Yeah - I might have been a little bit excited there on the code timing. I transposed the post-delay to fit what I was thinking. Looking at it again, I'm not sure those delays do very much, unless it's for some other hardware settling. The 68K instruction timing is slow enough so that the delays shouldn't matter (for the ICS1494). The other possibility is that the post-delay is a non-bug where the delay really should have been during strobe high and not after -- but was never an issue because of 68K timing.

The ICS1494 spec indicates the following:
Strobe Pulse Width: 20ns
Setup Time Data to Strobe: 10ns
Hold Time Data to Strobe: 10ns

If you were to assume better-than-best case 68K of 50Mhz, that's a period of 20ns (max standard Mac was the 840AV @ 40Mhz/25ns). The best case for a move immediate to effective address is 1 clock cycle on the '040 and 3 clock cycles on the '020. So, the only machines that would possibly matter are '040 or later, and even with no delay in the hypothetical case of a 50Mhz '040, the timing would still be OK (including some additional time from the following CLR instruction until the line is seen as logic level 0). So, it would end up as >20ns. The 10ns times are irrelevant, since they are faster than a single clock cycle. There were accelerated cases, but even with a 133Mhz PPC, it would probably still be in the window because of the 68K emulator that required multiple PPC cycles for every 68K instruction (but still a Davidian engineering marvel). Also, the ICS1494 stated timings are worst-case and probably faster.

As above, maybe the delay afterwards is for hardware stabilization at the new clock frequency. I don't know. There were multiple ICs that had to settle.

Just to confirm, when you are writing values to the IC1494 registers, you need to write longs of either $FFFFFFFF or $00000000 (which is the equivalent function of the BFEXTS for a data register destination). The easiest way to test would be to use the board as a secondary screen, write a different config that causes it to lose sync, then write back the original config and see if it resyncs (you may or may not need to power cycle the display). It may or may not work for some other reason, but it looks like the right code because of the 5-bit write followed by an obvious strobe. If it doesn't work from Macsbug, then it might require a dedicated code snippet to do the writes -- perhaps optimally with interrupts disabled.
“Sign extend to 32-bits”…whoops I missed that important detail! Let me try that.
 

MacOSMonkey

Well-known member
Good -- otherwise...??? If you were writing a 1 only (bit 0) to the strobe location (is at the base address, or offset $0), that would be interesting vs. having to write 0L or -1L for the other FSx bits. That might indicate that bit 0 is mapped to register 0/strobe at the base and each register has its own bit assignment so that FS0 is bit 1, FS1 is bit 2, etc. Just speculation. That would also explain the bfexts, because it would be the most efficient way to set all the bits, where only 1 sequential bit mattered. Or, it could just be that it is some other bit.

If you feel like trying this experiment, the data to write to each location would be:
$00/STROBE: $00000001
$04/FS0: $00000002
$08/FS1: $00000004
$0c/FS2: $00000008
$10/FS3: $00000010
$14/FS4: $00000020
 

jmacz

Well-known member
Ok, finally back in front of my machine.

I modified the ROM for 1280x1024 using the $1C and using the most recent set of timing values from @eharmon:
  • HES: 15
  • HEB: 35
  • HSB: 195
  • HTOT: 215
  • VES: 2
  • VEB: 42
  • VSB: 1066
  • VTOT: 1069
My LCD (Dell 1905FP) is recognizing the signal as 1280x1024 @ 58Hz.

It's pretty damn close.. horizontally it seems correct. Nothing is cropped and it seems to be utilizing all the dots across the LCD. Vertically, nothing is cropped, but the display is not using the first 4 pixel rows (it looks like 4... ) so that suggests it's smooshed slightly. Pixels look pretty clear.

When booting as the secondary screen, I get the "S" supermac logo screen first which looks good... then it refreshes to a checkerboard gray but with a red band along the bottom (maybe 72 pixels high? just a guess.. about an 1" high maybe?) which lasts for a second, then it refreshes again and then everything looks correct after that.
 

MacOSMonkey

Well-known member
It sounds like a sync issue. Try increasing VES by increments of +1.

There is a 960 value that hasn't been changed somewhere. The vertical delta to 1024 is ~1", or 64 pixels.

I'll look at the disassembly again. The spot where I commented in a previous post about checkerboard alternating lines with $55/$AA, etc. - Secondary init?

Also, make sure you have changed the values in both 24-bit and 32-bit sRsrcs from 960 to 1024 (I mention the table offset in an earlier post). The board will attempt to install the 32-bit sRsrc and if it still has 960 in the vRes, that could be the problem.

You have to change it in the sRsrcs for every bit depth. 1 is missing somewhere. It could be 1-bit mode. You could also try breaking on SetDepth to see if the problem is happening before or after the OS tries to set the current depth.

Also, you could try booting in different bit depths.
 

jmacz

Well-known member
Actually, disregard the part about the first 4 rows not being used... it looks like that's just the LCD panel being shifted down within the plastic enclosure. I just drove the display at 1280x1024 @ 60hz off another computer and it's the same.

But I just checked and there was one row at the bottom being cropped off so for me right now, the settings that work are with no cropping and detecting at 58Hz:
  • CLOCK: $1C
  • HES: 15 ($000F)
  • HEB: 35 ($0023)
  • HSB: 195 ($00C3)
  • HTOT: 215 ($00D7)
  • VES: 2 ($0002)
  • VEB: 42 ($002A)
  • VSB: 1068 ($042C)
  • VTOT: 1071 ($042F)
This was all done via MacsBug live. I'm going to try burning the ROM with the slight tweak to see if that red band on boot disappears. Otherwise, not sure what's causing that. But will use your latest suggestion to see if I missed a spot... I thought I got them all but will check again.
 

MacOSMonkey

Well-known member
Check 1-bit 1280x1024 at the base+offset location. Otherwise, boot in different depths and see if that helps pinpoint the problem (in the event that it's happening after SetDepth).

Your vertical looks correct. I may have erred in an earlier comment on timing - forgetting that the blanking area includes the specified lines and is not 0-based. A little rusty.

VEB: line 42 - the last line of vertical blanking
VAStart: Line 43 - the first line of the active area
VAEnd: Line 43+1024 = 1067 - the last line of the active area
VSB: line 1068 - the first line of vertical blanking

It may also sync up in config $0f at something approaching 75Hz, once you get this one working. And if you can find an external 135Mhz oscillator and the pad works, then you can try config $01.
 

eharmon

Well-known member
Also, make sure you have changed the values in both 24-bit and 32-bit sRsrcs from 960 to 1024 (I mention the table offset in an earlier post). The board will attempt to install the 32-bit sRsrc and if it still has 960 in the vRes, that could be the problem.
I'm pretty sure this is what I missed. I'm away from my machine for a bit, but I bet adjusting the other sResource clears the bar up (that's what I've been seeing too), @jmacz.

Nice to know $1C clock is working for you! I still haven't gotten live clock-adjustments working, you managed with MacsBug?
 

jmacz

Well-known member
Ok, I got it working. I searched the entire ROM for remaining occurrences of 0x03C0 and found a bunch of them. But only two of them looked resolution related so I changed those two and now I no longer get the red band during boot!

With the changes, I have a clean 1280x1024 @ 58Hz working. I think this resolves my need for 1280x1024. :)

I also modified the version string to be 3.0.1 just so that I can tell it apart from the stock ROM. I have attached the modified ROM to this post.
 

Attachments

  • SMTv3jmacz-v4.bin
    64 KB · Views: 2

jmacz

Well-known member
With regards to the remaining quest for 1600x1200 @ 24bits (original post request), I'm trying to understand the set of recent posts on this topic. Is the current thought that there was a revision to the DAC on the Thunder II GX 1600 vs the Thunder II GX 1360? Based on the pictures from @MacOSMonkey it looks like the DACs are different. In that case, is 1600x1200 no longer a possibility on the 1360 (without hardware changes)?
 

MacOSMonkey

Well-known member
Great job! That's awesome! Are you going to try 1280x1024 @ 130MHz now? :D

1600x1200 might be possible -- the DAC supports it per the Brooktree doc...and there are 165Mhz parts. Another research project.

I went back to look at my earlier post on the 24/32-bit sRsrc tables. It was Post #50. Here is the section of code that loads the 32-bit sRsrc, etc. I added some extra comments. The table offset appears to be $54.

Code:
; So, from this code, the spIDs are in the format of:
; [block of 32-bit IDs]
; -- Cut-Off of $AA for max 32-bit ID -- probably the 1st 24-bit ID
; [block of 24-bit IDs]
; -- delta between a 32-bit ID and its matching 24-bit ID is $54, or 84 decimal.
; So, if x is the 32-bit ID, x+$54 is the matching 24-bit ID

0000009e : 0c03 00d4           CMPI.B   #$D4,D3                  ; NOTE: this is not register d4 ;-)
; if the sRsrc order is [32-bit][24-bit], this must be the 1st 24-bit resource ID (check it)
000000a2 : 6d06                BLT      $000000aa                    ; this branch means that the spID is already in the 32-bit range

000000a4 : 0404 0054           SUBI.B   #$54,D4                  ; therefore, this must be the 24-32 delta - so it selects 32-bit
000000a8 : 6004                BRA      $000000ae                  ; and this branch must be to insert the 32-bit ID (and it is)

; Looking at the code again, the following line that subtracts 2A/42 from the spID is confusing and appears to be a blind operation.
; Maybe it's a bug - the reason it makes no sense is that the value in D4 should already be the target 32-bit ID, but then what does
; subtracting an additional $2A/42 do? What if the value is less than 42? Maybe it never executes because the board always
; boots with a 24-bit spID and then switches to 32-bit and always branches to offset $000000ae -- which makes more sense.
; It then takes the 32-bit ID and inserts it. If the offset is $54 between the tables, then $2A is not enough to index into a lower table.
; So, potentially could be a non-executing bug. I don't know - perplexing. Such are the vagaries of disassembly.

000000aa : 0404 002a           SUBI.B   #$2A,D4                  ; *** another offset or bug ***

000000ae : 1144 0032           MOVE.B   D4,+50(A0)                  ; branches converge and set new spID
000000b2 : 1944 0005           MOVE.B   D4,+5(A4)                  ; saving the current/updated spID - vendor use
000000b6 : 42a8 0018           CLR.L    +24(A0)                  ; clear spParamData (set to enabled - see 2-54 SlotManager)
000000ba : 42a8 0004           CLR.L    +4(A0)                  ; clear spSPointer (set to NIL)
000000be : 700a                MOVEQ    #$0A,D0
000000c0 : a06e                _SlotManager                         ; InsertSRTRec -- installing the 32-bit sRsrc
000000c2 : 1143 0032           MOVE.B   D3,+50(A0)                  ; set the old 24-bit ID still in d3
 

jmacz

Well-known member
Nice to know $1C clock is working for you! I still haven't gotten live clock-adjustments working, you managed with MacsBug?

Forgot to answer this. I did not try changing the clock live via MacsBug. Only the SMT registers. For the clock, I modified it to $1C in the ROM.
 

eharmon

Well-known member
Ok, I got it working. I searched the entire ROM for remaining occurrences of 0x03C0 and found a bunch of them. But only two of them looked resolution related so I changed those two and now I no longer get the red band during boot!

With the changes, I have a clean 1280x1024 @ 58Hz working. I think this resolves my need for 1280x1024. :)

I also modified the version string to be 3.0.1 just so that I can tell it apart from the stock ROM. I have attached the modified ROM to this post.

Great job! That's awesome! Are you going to try 1280x1024 @ 130MHz now? :D

1600x1200 might be possible -- the DAC supports it per the Brooktree doc...and there are 165Mhz parts. Another research project.

I went back to look at my earlier post on the 24/32-bit sRsrc tables. It was Post #50. Here is the section of code that loads the 32-bit sRsrc, etc. I added some extra comments. The table offset appears to be $54.

Code:
; So, from this code, the spIDs are in the format of:
; [block of 32-bit IDs]
; -- Cut-Off of $AA for max 32-bit ID -- probably the 1st 24-bit ID
; [block of 24-bit IDs]
; -- delta between a 32-bit ID and its matching 24-bit ID is $54, or 84 decimal.
; So, if x is the 32-bit ID, x+$54 is the matching 24-bit ID

0000009e : 0c03 00d4           CMPI.B   #$D4,D3                  ; NOTE: this is not register d4 ;-)
; if the sRsrc order is [32-bit][24-bit], this must be the 1st 24-bit resource ID (check it)
000000a2 : 6d06                BLT      $000000aa                    ; this branch means that the spID is already in the 32-bit range

000000a4 : 0404 0054           SUBI.B   #$54,D4                  ; therefore, this must be the 24-32 delta - so it selects 32-bit
000000a8 : 6004                BRA      $000000ae                  ; and this branch must be to insert the 32-bit ID (and it is)

; Looking at the code again, the following line that subtracts 2A/42 from the spID is confusing and appears to be a blind operation.
; Maybe it's a bug - the reason it makes no sense is that the value in D4 should already be the target 32-bit ID, but then what does
; subtracting an additional $2A/42 do? What if the value is less than 42? Maybe it never executes because the board always
; boots with a 24-bit spID and then switches to 32-bit and always branches to offset $000000ae -- which makes more sense.
; It then takes the 32-bit ID and inserts it. If the offset is $54 between the tables, then $2A is not enough to index into a lower table.
; So, potentially could be a non-executing bug. I don't know - perplexing. Such are the vagaries of disassembly.

000000aa : 0404 002a           SUBI.B   #$2A,D4                  ; *** another offset or bug ***

000000ae : 1144 0032           MOVE.B   D4,+50(A0)                  ; branches converge and set new spID
000000b2 : 1944 0005           MOVE.B   D4,+5(A4)                  ; saving the current/updated spID - vendor use
000000b6 : 42a8 0018           CLR.L    +24(A0)                  ; clear spParamData (set to enabled - see 2-54 SlotManager)
000000ba : 42a8 0004           CLR.L    +4(A0)                  ; clear spSPointer (set to NIL)
000000be : 700a                MOVEQ    #$0A,D0
000000c0 : a06e                _SlotManager                         ; InsertSRTRec -- installing the 32-bit sRsrc
000000c2 : 1143 0032           MOVE.B   D3,+50(A0)                  ; set the old 24-bit ID still in d3
Sweet. I'll double check to see if the locations changed match up to these or if there's anything else missing :).
 

jmacz

Well-known member
I tried the $0F for the clock configuration and that also worked. The card is now driving 1280x1024 @ 71Hz.

I have attached the modified ROM, this time tagged with "3.0.2" as the version.
 

Attachments

  • SMTv3jmacz-v5.bin
    64 KB · Views: 2
Top