Home Page Forums MAME MAME CRTCs are annoying

I'm overhauling the heck out of pds30_30hr.cpp, one of the oldest-style remaining NuBus video cards now that the original source and documentation is circulating ( https://github.com/ZigZagJoe/Color30HR-ROM). Even with the encryption on the registers resolved (Kale thinks SVGA is bad, LOL), I can't get the numbers to work.


Some decrypted register values, validated against the numbers in the source (which are all hard-coded).

Stock Mac-style 640x480 (30.240 MHz pixel clock). Htotal should be in the vicinity of 896, and Hvis is of course 640.
H front porch interval: 63
Half of H sync: 31
H back porch minus NS: 66
H line ("[# of pixels per line - (FS1+FS2)] divided by 2 : 205
HSync22 ("FS1+FS2+NS+H Front Porch+H Back Porch+Line/2"): 370
Row MSBs ("Row transfer address MSBs"): 234
FS1 ("Format run pipe fill"): 1
FS2 ("Format run off"): 11
NS ("Period in H back porch interval to begin holding off DAC access to prevent snow"): 17

If you assume all values are 1 less than the real number (which is plausible), I can torture these values to almost work:
H line (206 * 2) = 412 + (FS1 2 + FS2 12) = 426 *2 (arbitrary) = 852 Htotal (too far off, but play along) - (HFP 64 + HSync (x2) 64 + (HBP+NS) 84) = 640 visible.

But this blows up for the 640x480 SVGA mode (25.175 MHz pixel clock):
HFP: 15
HSync: 47
HBP: 16
HLine: 238
HSync22: 304
Row MSBs: 237
FS1: 1
FS2: 11
NS: 16

800x600 @ 72 Hz SVGA (57.283 MHz pixel clock):
HFP: 31
HSync: 36
HBP: 70
HLine: 92
HSync22: 0
Row MSBs: 490
FS1: 7
FS2: 9
NS: 16

Mac 832x624:
HFP: 12
HSync: 18
HBP: 79
HLine: 128
HSync22: 0
Row MSBs: 498
FS1: 2
FS2: 4
NS: 18

1024x768 (65 MHz pixel clock):
HFP: 29
HSync: 32
HBP: 54
HLine: 163
HSync22: 0
Row MSBs: 499
FS1: 6
FS2: 8
NS: 12

If anyone can get these numbers to work please let me know how :-)

SailorSat is really good or Calamity over at GroovyMAME. Both are experts when it comes to CRT timings/numbers.
This site has nice info for CRT timings. Its just that it burns in the eyes : https://www.improwis.com/tables/video.webt#Table

Well (S)VGA is just the equivalent of descendants of Cain: everyone wanted to add their own flavor atop the original IBM VGA specs, over the principle of doing specific stuff so that an errand lalaland code execution won't blow up the attached monitor.
On it's own the VGA CRTC setup isn't even all that special and nobody really do sorcery with it (i.e. it's currently handled by one single function for all, `vga_device::recompute_params_clock`), while external clocking modes are really handled by PLL, and attached RAMDAC does the actual pixel changes.

It goes without saying that it pales compared to this, what's the actual code doing these inits?

You can see the code at the Github link in my first post. It's literally just this:

MOVE.L #$C0E00000, kMavAHFPorch(A0) ; $03F
MOVE.L #$E0E00000, kMavAHSync(A0) ; $01F
MOVE.L #$BDE00000, kMavAHBPorch(A0) ; $042 ($043) llsm 12/18/91
MOVE.L #$32E00000, kMavAHLine(A0) ; $0CD ($0CE) llsm 12/18/91
MOVE.L #$FDE00000, kMavAVFPorch(A0) ; $002
MOVE.L #$FDE00000, kMavAVSync(A0) ; $002
MOVE.L #$D9E00000, kMavAVBPorch(A0) ; $026
MOVE.L #$20C00000, kMavAFrameLines(A0) ; $1DF
MOVE.L #$8DC00000, kMavAHSync22(A0) ; $172
MOVE.L #$FFE00000, kMavAColRow(A0) ; $000
MOVE.L #$15E00000, kMavARowMSBs(A0) ; $0EA
MOVE.L #$FF400000, kMavAModesA(A0) ; $500 ($580) llsm 1/14/92
MOVE.L #$FEE00000, kMavAFS1(A0) ; $001
MOVE.L #$F4E00000, kMavAFS2(A0) ; $00B ($00A) llsm 12/18/91
MOVE.L #$FFE00000, kMavAReqToTransDly(A0) ; $000
MOVE.L #$FFE00000, kMavATransToReqDly(A0) ; $000

The values written have the top 8 bits moved to the bottom 8 bits and XORed with $FF, the remaining 3 bits are rotated and added so that writing $E in bits 20-22 is really $0 in bits 8-11 of the result. The commented values on the right are the decrypted values.