clb wrote on 2024-11-21, 19:20:

keenmaster486 wrote on 2024-11-21, 18:30:

Thanks for the quick reply. I tried your new DAC register tool, and it told me that it was already ENABLED. Running the tool had no effect on the palette.

Hmm, that's unfortunate. Re-reading the spec sheet, not quite sure where the issue would be, or if the Shadow DAC feature works somehow different than what I assume.

Your tool just got the logic the wrong way. If that bit is clear, the Cirrus chip will grab all palette writes, so the chipset is not forwarding it to the ISA bus. If that bit is set, the Cirrus chip will accept palette data, but not tell the chipset about it, so the chipset falls back to forwarding the palette writes to the ISA bus. This means you need a tool that sets the bit if it is clear, not a tool that clears the bit if it is set.

Well of course I did. I got hung up on the "Reset: 1" field in the documentation and kept thinking that therefore 1=Disabled.

Updated the utility now to allow flipping the bit either way, that should help test more extensively.

Just got my card, thanks clb!
Will eventually use it when I have more free time 😀

This is what I'm getting now with the CLGD_DAC tool. "Unable to change DAC shadowing register bit"

keropi wrote on 2024-11-22, 17:24:

Just got my card, thanks clb!
Will eventually use it when I have more free time 😀

Awesome! Makes me chuckle to note we're purchasing vintage PC projects from each other 😀

keenmaster486 wrote on 2024-11-22, 17:32:

This is what I'm getting now with the CLGD_DAC tool. "Unable to change DAC shadowing register bit"

The attachment Screenshot 2024-11-22 10-31-31.png is no longer available

That means that the register bit is stuck in state. Browsing the spec PDF, it looks like there is a lock register at 3C5h/06h (extension register SR6) that might prevent access.

I updated the tool in GitHub once more to try to unlock that register first. I wonder if that makes any difference?

clb wrote on 2024-11-22, 18:15:

That means that the register bit is stuck in state. Browsing the spec PDF, it looks like there is a lock register at 3C5h/06h (extension register SR6) that might prevent access.
I updated the tool in GitHub once more to try to unlock that register first. I wonder if that makes any difference?

Same result, unfortunately.

clb wrote on 2024-11-22, 18:15:

Awesome! Makes me chuckle to note we're purchasing vintage PC projects from each other 😀

balancing the universe! 😁

keenmaster486 wrote on 2024-11-22, 18:29:

clb wrote on 2024-11-22, 18:15:

That means that the register bit is stuck in state. Browsing the spec PDF, it looks like there is a lock register at 3C5h/06h (extension register SR6) that might prevent access.
I updated the tool in GitHub once more to try to unlock that register first. I wonder if that makes any difference?

Same result, unfortunately.

Bummer. I'm a bit out of ideas on this one. Double and triple checked the code, but couldn't spot if it still might have some flaw.

Tried the program on a PCI-based CL-GD5434, which reports the bit to be 1 (enabled) already. There it does appropriately flip the bit between 0 and 1 - but it actually doesn't do anything (which I suppose is not that weird, since on PCI cards, the palette snoop is controlled by another register bit in the PCI configuration address space).

I have another Cirrus Logic based card that I could try instead. May put it in my machine and report back.

clb wrote on 2024-11-21, 20:51:

keenmaster486 wrote on 2024-11-21, 20:32:

One more thing I forgot to mention: the PALTSR tool takes up 7K of RAM. Couldn't this be much less? Seems like what it's doing isn't that complex.

I agree, and believe it could, if I only knew how. I get an impression that Borland Turbo C++ 3.0 that I used to create that is possibly not the best tool. Maybe handwriting the TSR fully in assembly would be the way to go for these types of things. I might try disassembling what Borland Turbo C++ 3.0 generated for that, and writing an assembler version of the same.

I had a quick look at the C++ source, I could probably rewrite it fairly easily as assembly so it could be built as a .com file using yasm/nasm which would make it a lot smaller, probably less than 1KB resident - would there be any restrictions on what instructions to use, e.g. what is the minimum cpu architecture it needs to run on?

jmarsh wrote on 2024-11-22, 21:52:

clb wrote on 2024-11-21, 20:51:

keenmaster486 wrote on 2024-11-21, 20:32:

One more thing I forgot to mention: the PALTSR tool takes up 7K of RAM. Couldn't this be much less? Seems like what it's doing isn't that complex.

I agree, and believe it could, if I only knew how. I get an impression that Borland Turbo C++ 3.0 that I used to create that is possibly not the best tool. Maybe handwriting the TSR fully in assembly would be the way to go for these types of things. I might try disassembling what Borland Turbo C++ 3.0 generated for that, and writing an assembler version of the same.

I had a quick look at the C++ source, I could probably rewrite it fairly easily as assembly so it could be built as a .com file using yasm/nasm which would make it a lot smaller, probably less than 1KB resident - would there be any restrictions on what instructions to use, e.g. what is the minimum cpu architecture it needs to run on?

Wow, I would be so grateful to dip in to your knowledge, that would be fantastically interesting to learn from.

The PALTSR.EXE program can only ever be needed on ISA VLB or PCI adapters. It is never needed on older ISA VGA adapters. So that would make it 386 arch minimum I suppose, as 286s never had VLB bus?

However CRT Terminator is a 8-bit ISA card. So it is good to avoid using 16-bit I/O port writes when communicating with it.

I got my CRT Terminator today!

Haven't tried it out yet, but hopefully will soon. I've got a handful of VLB cards to test with this. 😁

Yay, so glad to see that UPS un-screwed themselves. Hope the card meets all your expectations, and then some!

Seeing an issue when running VGA programs. It will frequently lose sync and glitch out for a split second, as in the attached video. So far I've observed this in Doom and Jazz Jackrabbit.

This kind of sync problem points towards either Hsync or Display Enable signal seeing glitches on the VGA adapter line. What were the jumper settings on the board? Something you can try is to disable automatic video sampling phase detection by setting J2 to 2-3 (Disabled). This enables the manual signal sampling phase detection jumpers J3-J6 to take effect.

After disabling automatic video sampling phase, then try to toggle J4 and J6 jumpers to find a combination that gives the best results. Were you testing with the short 15cm or long 30cm Feature Connector video cable?

I wrote a new manual page to detail which settings to use in OBS to record "unconventional" 70Hz video footage that would aim to not miss any frames.

Paired with a YouTube example video upload (which does lossily resample the video down to 60Hz): https://www.youtube.com/watch?v=8o7cu9mYL10

clb wrote on 2024-11-22, 23:05:

Wow, I would be so grateful to dip in to your knowledge, that would be fantastically interesting to learn from.

The PALTSR.EXE program can only ever be needed on ISA VLB or PCI adapters. It is never needed on older ISA VGA adapters. So that would make it 386 arch minimum I suppose, as 286s never had VLB bus?

However CRT Terminator is a 8-bit ISA card. So it is good to avoid using 16-bit I/O port writes when communicating with it.

This is what I ended up with, seems to output the correct data on the CRTT ports when used under DOSBox.

1; compile cmdline: "yasm -f bin -o paltsr.com paltsr.asm"
2
3BITS 16
4org 0x100
5
6  ; jmp near = 3 bytes, 4 bytes needed for old_isr (overwrites entry point jump)
7old_isr:
8  jmp near init
9  nop
10  
11pal: times 256*3 db 0
12crtt_pal_index: dw 0
13
14update_palette:
15  ; N.b. the Palette DAC has a boolean "am I in read mode"
16  ; vs "am I in write mode" state. Reading port 0x3C7
17  ; is supposed to tell us which one we are currently in,
18  ; but that does not seem to work reliably. See
19  ; http://www.osdever.net/FreeVGA/vga/colorreg.htm#3C7
20  
21  mov dx, 0x3C8    ; dx = 0x3C8
22  in al, dx        ; al = inp(0x3C8)
23  push ax          ; old_dac_write_index
24  dec dx           ; dx = 0x3C7
25  xor ax, ax
26  out dx, al       ; Switch DAC to reading VGA palette index 0
27
28  add dx, 2        ; dx = 0x3C9
29  ; si is used to index the local palette memory
30  ; bh is used as a counter to iterate through the DAC palette entries
31  ; di is used to cache the value of crtt_pal_index
32  mov si, pal      
33  xor bx, bx       ; set bh to zero
34  movzx di, [crtt_pal_index]
35.loop:
36  in al, dx        ; fetch red
37  movzx cx, al
38  xchg [si], al
39  cmp cl, al       ; compare current red to old red, set/clear EQ flag
40  
41  in al, dx        ; fetch green
42  mov ch, al
43  xchg [si+1], al
44  jne .blue
45  cmp ch, al       ; compare current green to old green, set/clear EQ flag
46  
47.blue:
48  in al, dx        ; fetch blue
49  mov bl, al
50  xchg [si+2], al
51  jne .update      ; if EQ is not clear, update CRTT
52  cmp bl, al       ; compare current blue to old blue, set/clear EQ flag
53  je .update_done  ; if EQ is clear don't update CRTT
54  
55.update:
56  ; does the CRTT index need to be updated?
57  movzx ax, bh              ; ax = i
58  cmp di, ax                ; if (i != crtt_pal_index) {
59  je .skip_index_update
60  

61  mov dx, 0x123             ; dx = 0x123
62  mov di, ax                ;   crtt_pal_index = i;
63  out dx, al                ;   outp(0x123, i)
64                            ; }
65  
66.skip_index_update:
67  mov dx, 0x124             ; dx = 0x124
68  ; expand 6-bit -> 8-bit by copying 2 MSBs to LSBs
69  shrd ax, cx, 6
70  shrd ax, cx, 14
71  movzx cx, ch
72  out dx, al       ; outp(0x124, red)
73  shrd ax, cx, 14
74  out dx, al       ; outp(0x124, green)
75  shrd ax, bx, 6
76  shrd ax, bx, 14
77  inc di           ; crtt_pal_index++
78  out dx, al       ; outp(0x124, red)
79  mov dx, 0x3C9    ; dx = 0x3C9
80
81.update_done:
82  inc bh           ; increment index - will overflow to zero when 256 is reached
83  lea si, [si+3]   ; increment palette pointer (without setting flags)
84  jne .loop
85
86  ; Set DAC back to palette write mode, and set the old VGA palette write
87  ; index. This assumes that games/programs never rely on the DAC being
88  ; left in read mode, and that they disable interrupts while programming
89  ; the palette.
90  ; (because if interrupts would occur in the middle of writing G or B
91  ; component, we cannot reset write index back to that color component)
92  pop ax     ; al = old_dac_write_index
93  dec dx     ; dx = 0x3C8
94  mov [crtt_pal_index], di          ; save crtt pal index for next time
95  out dx, al ; outp(0x3C8, old_dac_write_index);
96
97  retn
98
99timer_handler:
100  ; push used registers
101  push ax
102  push bx
103  push cx
104  push dx
105  push si
106  push di
107  push ds
108  mov ax, cs
109  mov ds, ax
110  
111  call update_palette
112  
113  ; pop used registers
114  pop ds
115  pop di
116  pop si
117  pop dx
118  pop cx
119  pop bx
120  pop ax
121  
122  ; we are done, branch to previous timer routine
123  jmp far [cs:old_isr]
124  
125init:
126  ; disable interrupts
127  cli
128  
129  ; initialize crtt
130  xor ax, ax
131  mov dx, 0x123
132  out dx, al  ; Sync initial CRT Terminator palette write index state
133  call update_palette
134  
135  mov cx, 256
136  mov bx, pal
137.loop:                ; for (bx=&pal[0], i=256; i > 0; i--) {
138  xor byte [bx], 0x80 ;   *bx.r ^= 0x80
139  add bx, 3           ;   bx++;
140  loop .loop          ; }
141  
142  call update_palette
143  
144  ; enable interrupts
145  sti
146  
147  ; get old timer routine
148  mov ax, 0x351C
149  int 0x21
150  mov [old_isr], bx
151  mov [old_isr+2], es
152  
153  ; set new timer routine
154  mov dx, timer_handler
155  ; ds should already be set to our (single) segment
156  mov ax, 0x251C
157  int 0x21
158
159  ; terminate and stay resident, release all memory after init
160  mov dx, (init+15) >> 4
161  mov ax, 0x3100
162  int 0x21

You can build it into a .com file using yasm, the command line is at the top of the file. It takes up a little over 1KB of memory since the PSP is 256 bytes, another 768 bytes for the palette plus what's needed for the code.

Thanks, this is so awesome. I gave it a test and it works really well. Memory consumption is 1,584 bytes, whereas with the CPP version compiled with Borland Turbo C++ 3.0 memory consumption was 8,072 bytes.

Gave a performance a test by running DOOM high res from Phil's DOS Benchmark Pack three times in each case: (lower is better)

1No TSR (i.e. incorrect colors): 2798, 2798, 2810 realtics. Avg: 2806 realtics.
2PALTSR.ASM: 2855, 2846, 2857 realtics. Avg: 2852.7 realtics. (+1.66% slower than no TSR)
3PALTSR.CPP: 2851, 2864, 2853 realtics. Avg: 2856 realtics (+1.78% slower than no TSR)
4PCI Palette Snoop enabled: 2801, 2813, 2800 (2804.7) (i.e. practically same as palette snooping disabled)

This test was done on a 80MHz Cyrix 486 PC with a PCI-based Hercules Stingray Pro (ARK1000PV) graphics card. The last test was done by enabling ISA Palette Snooping the intended way by flipping the Palette Snoop bit in PCI configuration register space, without using a TSR. This was to sanity check/baseline the performance effect of enabling palette snooping in general. I.e. in this game, there does not seem to be an adverse observable perf difference in enabling palette snooping. (palette snooping was disabled originally to save on performance, but it is very rare, or application dependent as to whether there is an observable perf penalty)

When using both PALTSR.ASM, it should be noted that the video output might not be completely glitch-free. Because palette updates are then unsynchronized with respect to drawing, there can be occassional frames where palette updates come out delayed by a frame or two.

Thank you so much jmarsh for developing this TSR. <3 I sent you a direct message as a follow-up.

I did notice when I was testing that there were times the display palette would get corrupted during times of heavy updates e.g. fade-in/fade-outs such as splash screen or menu transitions in Descent. Pretty sure this is because the game doesn't disable interrupts when updating the palette and the timer/TSR is jumping in and resetting the update index in the middle of a write.

Does the VGA hardware typically update the DAC red and green values as they are written, or are those values stored temporarily and only get updated when the final/blue value is written?

Yeah, that is correct. The PALTSR approach is fundamentally fallible that way, and guarantees to be working only if the original game gates palette uploads inside an interrupts disabled block.

I did run tests way back to check on the "do VGA cards actually apply R/G/B palette colors after every single color component write, or only after the whole triplet?", and the result I got on a couple of cards that I tested (maybe CL-GD5422 and Tseng ET4000AX, I don't quite recall), was that the color was updated only after the final Blue component was updated. So if a sequence of red and green writes that might have been interrupted, but blue was not written, there wouldn't be any partial change. So I modeled that behavior to CRT Terminator FPGA's snooping of the palette registers as well.

Though I'm not sure if that behavior was ever specified in VGA, so it could be that one cannot guarantee that behavior to take place for all VGA adapters. But I think that is the source of the glitches that PALTSR gets, for example seen in Doom.

(Now that I think about this, that R/G partial upload behavior would be a semi-interesting quirk test to add to SNOOP, which has a bunch of these corner case quirk tests for various VGA adapters in it)

What makes the glitch worse is that when such an interruption occurs, the palette sub-index (are we on R, G or B) goes off sync "permanently" for the code that is resuming the palette upload after recovering from interrupts. So what happens is that the game will then program incorrect palette colors potentially for a long time to other palette indices, and might not get around to correcting it in quite a while, if ever. So the glitch leads to potentially a long period of incorrect colors, not just transient one frame.

One way that I thought to mitigate this problem might be for the PALTSR interrupt to use a heuristic : when the update interrupt it reads the currently active palette write index from 3C8h, it would compare it to what the active palette write index at the start of the previous interrupt run would be. If the previously active palette write index is different than the current one, the idea is to think "maybe we're right in the middle of an update", and the interrupt would skip mirroring the palette to CRTT. I.e. only when the palette index is seen to be identical twice in a row, the palette is mirrored to CRTT.

Actually, I now got encouraged to give that heuristic a try now in PALTSR.CPP, and at least running Doom timedemo 5 times, I did not see a single glitch (whereas before I would see some intermittent glitches every now and then). Maybe that heuristic might be useful - testing with more games will be needed. Nevertheless seems to work so well, so I pushed it to git: https://github.com/juj/crt_terminator/commit/ … ba100993R38-R46