Have you tested on another mainboard? the 0WS isn't for the onboard ram, but for the ISA interface.

Really awesome card! I recall I was hunting for that specific Orchid Tseng ET4000AX about a year ago, since my Tseng ET4000AX

only has an 8-bit KDA04768L DAC, and DosDays having suggested that the Orchid card comes with a 16-bit colors providing Sierra DAC, indeed like your card has.

I wonder if that noise might be related to palette snow? If you try the PALANIM.EXE test, does its visual behavior change in 0ws vs 1ws mode? (see this post for description on palette snow and PALANIM.EXE)

Although the fact that DOS text mode also occassionally loses characters in 0ws mode suggests that maybe it might be something different. Hmm...

My card does not have a 0ws jumper marked, though Diamond SpeedSTAR 24 user manual does document this for JP1:

which I presume is a 0 or 1 wait state jumper.

Running with the card JP1 jumper set to the state shown in the above picture, SNOOP.EXE gives the following:

i.e. 771 KB/sec Read and 1329 KB/sec Write speed in Mode 13h.

When I flip JP1, I observe that Read speed stays the same but Write speed drops to 1157 KB/sec. (1329KB/sec calculates to ~7.5 ISA clocks per access, and 1157KB/sec calculates to ~8.6 ISA clocks per access, so indeed about one clock more) So JP1 on this card does seem to be the 0/1 wait state switch.

Looks like my card has 60ns memory. Running VIDSPEED4 on it in 0ws mode gives this result, i.e. no flickering present.

I wonder if this could be a motherboard thing? The documentation on Diamond SpeedSTAR24 manual above says "Bus timings on motherboards vary". Do you have another motherboard to test it on?

weedeewee wrote on 2024-01-26, 08:41:

Have you tested on another mainboard? the 0WS isn't for the onboard ram, but for the ISA interface.

clb wrote on 2024-01-26, 11:15:

I wonder if this could be a motherboard thing? The documentation on Diamond SpeedSTAR24 manual above says "Bus timings on motherboards vary". Do you have another motherboard to test it on?

No unfortunately, I don't.

clb wrote on 2024-01-26, 11:15:

I wonder if that noise might be related to palette snow? If you try the PALANIM.EXE test, does its visual behavior change in 0ws vs 1ws mode? (see this post for description on palette snow and PALANIM.EXE)

Although the fact that DOS text mode also occassionally loses characters in 0ws mode suggests that maybe it might be something different. Hmm...

I'm very fortunate that the ProDesigner IIs user manual is available as a PDF in a few places. The rear jumper block is where the 0ws switch is located. It also has an "Alternate Timing" jumper alongside the IRQ2 jumper on board, though switching the selection doesn't produce any visible results.

I'm not able to test with PALANIM or SNOOP for now so that will have to wait a bit. Depending on the results, though, I may need to somehow source a new RAMDAC.

Ran PALANIM and this was the result. It's nowhere near as severe as the BIOS screen and the missing text makes me think it's something else entirely, but the RAMDAC is definitely affected by out-of-vblank palette writes.

These are the results from running SNOOP.

The card apparently does some things with the timing literally backwards, and is very weird, but I kind of figured that already seeing how the PALs and ET4K itself are wired (Pins detailed in the datasheet as being for MCA are wired to the PALs, the read and write lines are described as needing to be tied low when in ISA mode, but are wired directly to the ISA bus despite those being "MCA" pins).

Nothing changes when going in and out of 0ws mode in either test.

Bumping again.

Running WHATVGA and similar artifacts appears where the test palette is loaded in the respective test image
This only happens in the "Phase Two" (where the test image extends off of the display area) of Modes:
0025h (640:480:16 Planar)
0029h (800:600:16 Planar)
0037h (1024:768:16 Planar)
0038h (1024:768:256 Packed)
0330h (800:600:32K)
0430h (800:600:64K) (mode still displays even though the card only has a 32k-capable RAMDAC)

Below are a couple of images of the 32/64k mode errors and the 0038h errors.

0330/0430h errors:

1. Before the image loads fully, part of the palette is drawn on screen, unknown if this is stale data carried over from "Phase 1", where the full pattern is visible, or if the palette is loaded fresh and this is the result.
2. after the palette section loads fully, it appears correctly filled in
3. Note how the cross is misaligned and appears to be old data from the previous screen, but totally unknown.

0038h errors:

1. Similarly, like the VGA Hi-Color modes, when the palette is first loaded in Phase 2 it seems to be stale data.
2. once the image loads fully, again the 256-color palette square appears as normal, and again, the center cross is misaligned. Part seems to be on the old "completely-visible" area, and the rest is aligned to the new "extends offscreen" area.

Any advice on what could be the root cause would be very nice. Glad to know however that these errors appear consistently and predictably, and only in specific video modes.