• Please review our updated Terms and Rules here

ISA Video card strange sparkly artifacts

The clue that leads me to believe this is DAC-related is that it's "almost always while a scene is fading in or out."

Additionally, SimCity 2000 uses palette color cycling to achieve most animations, which would explain why it's happening constantly in that game.
 
twolazy said:
Have you tried swapping slots to closest to the keyboard connector?
Click to expand...
I did not, that's an 8 bit slot and unfortunately this AT mobo is in an ATX case with no availability to put a card there, but I guess I could pull out the mobo and try it on the bench.
 
Plasma said:
The clue that leads me to believe this is DAC-related is that it's "almost always while a scene is fading in or out."

Additionally, SimCity 2000 uses palette color cycling to achieve most animations, which would explain why it's happening constantly in that game.
Click to expand...
True but Dazzle uses pallet color cycling extensively and these effects don't show up there.
 
Should be simple enough to write a program that just displays a simple set of color bars in mode 13h and pounds on the palette register to see what happens. Don't know if QBASIC would be fast enough to really make it sweat, though, so you'll probably want something compiled.
 
Eudimorphodon said:
Should be simple enough to write a program that just displays a simple set of color bars in mode 13h and pounds on the palette register to see what happens. Don't know if QBASIC would be fast enough to really make it sweat, though, so you'll probably want something compiled.
Click to expand...
Hmm yeah I'm not too familiar with programming for VGA cards. Maybe I can find a program that does this already?
I might have a copy of DJGPP floating around somewhere.

Meanwhile the seller said he'd exchange it for another card but I asked him if he wouldn't mind me trying to socket those last two ram chips first, just to try everything I can even though it's unlikely a ram issue. If the replacement does the same thing then I'd say it's just some weird quirk of how it works in this system, maybe some conflict I'm not seeing.
 
Divarin said:
Hmm yeah I'm not too familiar with programming for VGA cards. Maybe I can find a program that does this already?
I might have a copy of DJGPP floating around somewhere.
Click to expand...

I tested this on my Tandy 1000 with a VGA card, where it's probably way too slow to trigger snow even if my Oak VGA card were prone to it, but you can try running this under QBASIC. Or find a copy of QuickBASIC and compile it.

Code: 
SCREEN 13
y = 0
z = 0
q = 0
REM init screen
FOR x = 0 TO 255
LINE (x, 10)-(x, 199), x
NEXT x

10 REM poke the crud out of the palette register
OUT &H3C8, 0
FOR x = 0 TO 255
OUT &H3C9, y
OUT &H3C9, z
OUT &H3C9, q
y = y + 1: IF y > 63 THEN y = 0
z = z + 3: IF z > 63 THEN z = 0
q = q + 5: IF q > 63 THEN q = 0
NEXT x
GOTO 10
 
Last edited:
Eudimorphodon said:
Or find a copy of QuickBASIC and compile it.
Click to expand...

Never mind, I already did that. I'll try attaching a .zip of the .EXE file. This version only flashes a portion of the screen to be a little less distracting, and even on my Tandy 1000 it runs fast enough to be *very* distracting.

And here's what I'll say about the results: Unless it's an artifact of my LCD monitor getting wiggy when the colors change so fast I think I may have discovered the DAC in my Oak VGA card is prone to DAC snow. It's subtle but I see some small white dot/dashes intermittently show up, even outside the area where the colors are cycling.

And anything you see with this cannot be RAM related, all it's doing is hitting the I/O port for the DAC. No screen writes are happening after the lines are drawn and "Hit ESC to exit" is printed.
 

Attachments

  • pounder.zip
    18.2 KB · Views: 6
Eudimorphodon said:
Never mind, I already did that. I'll try attaching a .zip of the .EXE file. This version only flashes a portion of the screen to be a little less distracting, and even on my Tandy 1000 it runs fast enough to be *very* distracting.

And here's what I'll say about the results: Unless it's an artifact of my LCD monitor getting wiggy when the colors change so fast I think I may have discovered the DAC in my Oak VGA card is prone to DAC snow. It's subtle but I see some small white dot/dashes intermittently show up, even outside the area where the colors are cycling.

And anything you see with this cannot be RAM related, all it's doing is hitting the I/O port for the DAC. No screen writes are happening after the lines are drawn and "Hit ESC to exit" is printed.
Click to expand...

Nice! Unfortunately I've already shipped the card back to the seller. I asked him how he felt about me trying to replace those two ram chips (I figured it could go either way, he might want to try to avoid exchanging it if at all possible but also he might be concerned that I'll damage it in the process) He said not to do that and he said he'd ship the replacement immediately.

So I'm back to the OAK card at the moment, though I think I'll run this against that card to get a baseline. When the replacement ET4000 comes if it has the same issue then I can run this against that card.
 
Eudimorphodon said:
Never mind, I already did that. I'll try attaching a .zip of the .EXE file. This version only flashes a portion of the screen to be a little less distracting, and even on my Tandy 1000 it runs fast enough to be *very* distracting.

And here's what I'll say about the results: Unless it's an artifact of my LCD monitor getting wiggy when the colors change so fast I think I may have discovered the DAC in my Oak VGA card is prone to DAC snow. It's subtle but I see some small white dot/dashes intermittently show up, even outside the area where the colors are cycling.

And anything you see with this cannot be RAM related, all it's doing is hitting the I/O port for the DAC. No screen writes are happening after the lines are drawn and "Hit ESC to exit" is printed.
Click to expand...
If the changing colors are distracting, you should also be able to cause snow by reading and writing back the same values. Since it's the contended access that would cause snow, not the actual change.
 
Plasma said:
If the changing colors are distracting, you should also be able to cause snow by reading and writing back the same values. Since it's the contended access that would cause snow, not the actual change.
Click to expand...

Yeah, that occurred to me after the fact, but I figured having at least part of the screen do "something", well, show's it's doing something. Although I guess I could easily just recompile it so all it does is write the same values over and over again instead of incrementing.
 
Divarin said:
Nice! Unfortunately I've already shipped the card back to the seller. I asked him how he felt about me trying to replace those two ram chips (I figured it could go either way, he might want to try to avoid exchanging it if at all possible but also he might be concerned that I'll damage it in the process) He said not to do that and he said he'd ship the replacement immediately.

So I'm back to the OAK card at the moment, though I think I'll run this against that card to get a baseline. When the replacement ET4000 comes if it has the same issue then I can run this against that card.
Click to expand...
That is the most sensible thing to do. From what I remember those cards were better in MS Windows 3.1 than Dos anyway.

I have one in my MS Windows for Workgroups 3.11 486dx2/50 server box. It is still set up as it was the day it was commisioned and still works perfectly. ;)
 
Last edited:
... find attached a less pyrotechnic version of the DAC-pounder. It still rolls something visibly on the screen, but it's a pretty easily tuned out localized grayscale cycle, the rest of the screen is stable.

And without the pyrotechnics I can tell for sure, yeah, my Oak's DAC snows. Pretty hard, actually.
 

Attachments

  • pounder2.zip
    18.2 KB · Views: 6
I found this video which seems to be relevant. There are before/after comparisons starting at 9:00.

 
FWIW, I tried to photograph the snow; I had to use the manual mode and crank up the shutter speed to even try but even then my phone camera wasn't quite up to it. You can see mostly in the initial "stock palette" color bars a few instances of the "smears", mostly where they're a darker color on top of light (see the black mark on the red bar, and the brown smear into the white.) But it doesn't really do justice to what you see in person, where there are both dark-on-light and light-on-dark flecks and very noticeable if you look for them.

EDIT: It actually shows up far better in a video. I'd upload one if I weren't so lazy.

Anyway, if you want to test your own card to see if this is a problem I'm pretty confident my program will trigger it.

dac-snow.jpg
 
Plasma said:
I found this video which seems to be relevant. There are before/after comparisons starting at 9:00.

Click to expand...
Ah that is exactly what I was seeing on my card. Unfortunately looking at the images of my card (well the card I just shipped back) my ramdac is not socketted and is surface mount. I am not very good at surface mount soldering so I may have to just live with the snow.
 
Last edited:
You still might have better luck with a replacement, it is at least possible the individual DAC on your particular card was bad, or maybe came from an early buggy batch. (Assuming I read the part number correctly the datasheet claims it should be glitch-less. Maybe that comes with an asterisk that wasn’t obvious just scanning it, but still, it seems like the flecks on yours were… maybe usually prominent.)

So does your Oak snow if you run my torture test on it?
 
I wonder if it's possible to create a TSR that uses EMM386 to trap DAC port access and force waiting for vertical retrace :unsure:

It might slow things down quite a bit but if it's mostly fades it probably wouldn't matter...
 
You must log in or register to reply here.
Back
Top