Thanks for that.
It seems to go on an IC that is hidden underneath the bios ROM.
I'll do more tracing when I have a bit more time. Hopefully is an easy fix.
I'm curious though why an IRQ setting of the MPEG player will cause the VRAM to malfunction

The dotted lines that had appeared during MPEG playback, shown here: Re: MPEG-1 decoder add-on board for [S3 Vision 968] Diamond Stealth 64 VRAM VLB , also started appearing without MPEG playback. I had thought maybe the 70 ns VRAM on these cards wasn't fast enough for 40 MHz. I had sourced some NOS VRAM pieces, NEC D482445GW-60 and soldered them onto the 2 MB memory upgrade module. I then placed that module onto a PCI card to ensure they work properly. The NEC pieces appeared to work fine on the PCI Vision968 card.

I then proceeded to replace the IBM VRAM modules on the MPEG daughter card using the NEC pieces, however I still saw some corruption on the screen. I then replaced the IBM modules on the Diamond VLB card, but the issue remains. Thus it appears that these dotted lines aren't due to the video memory. If I use the VLB card without any upgrade card or MPEG card (2 MB only), the issue on the screen has no issue. The issue only occurs when either the MPEG card (which has 2 MB onboard) or the 2 MB memory module are installed. I have confirmed that these two daughter cards work fine on the PCI card.

Which is the most likely component on the VLB card which could be causing this image corruption when 4 MB is used?

a) the 10 uF, 16V tantalum SMD caps on the graphics card (no shorts were detected)?
b) the Texas Instruments TVP3026-220PCE RAMDAC?
c) the S3 Vision968 86C968-P?
d) The F245 bus transcievers?
e) ?

Rephrasing for the converse, which of these could it not be? Any ideas? Thanks!

EDIT: It did seem that after the installation of the NEC memory, the frequency and quantity of the corruption increased slightly versus when the IBM pieces were installed. I'm not sure what can be drawn from this.

I would scratch #2.
In previous posts you took a screenshot with the lines present there.
Data corruption is in video memory (bit blit shows it).

Skimmed through the previous posts, but didn't see you trying different screen resolutions and color depths.
Also, what happens if you don't use S3 driver and go with standard VGA driver only ?
The results from this can indicate pure hardware issue, a sw/hw issue combo, or maybe just a problem caused by software (driver) config.

There is some form of data corruption at all resolutions and colour depths. However, if I run 1280x1024x24bit, the full bottom half of the screen shows corruption. The bottom half at this resolution would utilise the full 2nd 2 MB add-on memory. If I run at 1024x768x16bit, then about a quarter of the screen shows corruption.

The memory is fine as determined by testing it on other [PCI] cards. I've taken the FSB down to 33 MHz, but the issue continues.

I suspect whatever component on the VLB card which "handles" this 2nd MB add-on memory is having some issue, not the memory itself.

I replaced the tantalum cap near the Vision968, but that didn't help. I'm in the middle of replacing the Vision968, but ran into a snag. I'm borrowing a 968 chip from another card and perhaps I lifted too hard on desolder or perhaps the donor card was warped because when I went to solder on the 968 using paste, one whole side didn't make contact. I've never had this happen before. Have you had any luck putting paste over 50 non-contact QFP pins and not creating bridges? I don't really want to desolder the 968 and manually force down the whole side of pins, then re-paste it.

The main chip itself ?
Hope it works.

But didn't you say that removing the add on card makes the problem disappear?

Had some hot air work on smaller chips, but still with a lot of close packed gently legs.
Sometimes they get bent badly. Have to comb them to align to the pads underneath.
Also, bend them little further down then press the chip to the surface to vertically align all legs.
It is messy process with multiple iterations.

I am going off my gut feeling. I remember that 968 chip getting pretty hot and adding a fan helped the data corruption in the past. I traced the memory module connector lines to the 968 chip (they also go directly to the RAMDAC though). I had a junky 968 card to borrow the chip from already. Normally I'd order a NOS 968 chip, but I'm feeling impatient.

I did a practice run with this Trio64V+ chip prior to doing the 968 solder, and had no problem whatsoever. However, the PCB and Trio64V+ chip were both new. I gained confidence from the Trio job thinking the used 968 would be a breeze, but I was mistaken. I didn't have one non-contact and not one bridge on the new Trio64V+ job. Thus I must have bent the 968 pins upon removal and didn't notice.

I think the 968 is QFP-208. The smallest diameter [quality] solder I have is 0.38 mm, which is still too big for using the contact-based soldering iron. Does it come in 0.2 mm sizes? I have some 0.3 mm crap from China that is really awkward to work with.

I see - about the 968.

Just two weeks ago I resoldered the fpu on that 286 - to sxl2 upgrade module, where I had to comb its pins one by one.
Ended up using my phone's camera to zoom in to see better. It is a great magnifying glass - consider giving it a try.
Another thing I did before is use prosumer grade microscope kids don't use anymore - but that's more prep and complications.
Both methods really help to see what is going on from close up.

I have set of very sharp hot ends, but they wear very quickly.
Bought them from Amazon past year. Work pretty good for jobs like yours here.

I think QFP-208 is about as fine as it gets.

Update: I manually soldered the remaining strip of 50 or so pins on the 968, but the corruption issue persists. So much for my gut feeling. The manually soldered side looks a lot less attractive than the others. I bet I reduced the market value of my graphics card with this little swap.

I checked all SMD IC pins for continuity and they were fine.

So you think it is unlikely to be the RAMDAC? Which other component integrates the size difference between 2 MB and 4 MB?

Another update - the results are weird.

I switched the Diamond GT driver to use that provided by Microsoft (I think from the DirectX files). If I use the Microsoft driver, I still get corruption when the MVP-2000 is installed, however, I do not get corruption with the 2 MB upgrade card installed. Note that with the Diamond GT driver (which is needed to use the MPEG-1 decoding features), I get corruption with both the MVP-2000 installed and the 2 MB upgrade card installed.

Since I had less issues with the 70 ns IBM EDO VRAM, I guess I'll remove the NEC 60 NS EDO VRAM and put the IBM pieces back. I'd really prefer to have 60 ns IBM pieces, but best price I could find was around $17 each and I'd need 8 pieces minimum. There's still something off with the card. Heh, maybe it is the connector itself?

Final update:

I went to put the IBM EDO VRAM back onto the MVP-2000 card. I didn't notice, but I had one of the modules oriented 180 degrees. I went to power up the system, and nothing. It was on for about 8 seconds. I powered off, removed the card, and noticed the incorrect orientation of one module. I desoldered, turned 180 degrees, and resoldered. Powered back on and there is image corruption, but more than usual. I pulled the MVP-2000 out and tested it in the PCI card; sure enough, I damaged an IBM module. So I replaced the MVP-2000's IBM module with another one. I power the card up and there's no image corruption, with both the Microsoft and Diamond GT drivers. This seems odd given the previous events.

But, my conclusion is that the MVP-2000 insists on having the IBM EDO VRAM (70 ns). The Diamond Stealth 64 VRAM VLB seems OK to keep the NEC EDO VRAM memory (60 ns). This particular combination yields the least issues with the Diamond GT drivers. Also, as noted previously, NEC memory on the Stealth64 and NEC on 2 MB upgrade card work fine if I use the Microsoft driver.

So I am pretty much back to square one, which was just having some mild image corruption if I used the MVP-2000 to playback MPEG files. Once I stop playback and refresh the screen, the corruption is gone. Also still have the issue of VGA "signal out of range" when I go to shutdown when using the GT drivers. I've never been able to resolve this, even if I create a custom monitor file and limit the refresh rate to 60 Hz.

I'm not sure what was causing the recent mild on-screen corruption with IBM memory on MVP-2000 and IBM memory on Stealth64 when not playing back MPEG files, but NEC on Stealth64 and IBM on MVP-2000 appear to have resolved this. This hardware is weird. Nonetheless, I've put the 10 uF SMD tantalums on my Digikey shopping list for whenever my next order is. I am a bit bummed about replacing the Vision 968 and the less than perfect soldering on one of the edges. If I can find some NOS Vision 968 chips, I'll probably replace it again.

feipoa wrote on 2022-02-24, 14:30:

So I am pretty much back to square one, which was just having some mild image corruption if I used the MVP-2000 to playback MPEG files. Once I stop playback and refresh the screen, the corruption is gone. Also still have the issue of VGA "signal out of range" when I go to shutdown when using the GT drivers. I've never been able to resolve this, even if I create a custom monitor file and limit the refresh rate to 60 Hz.

That's why i thought there is a software issue at play and was skeptical that swapping the main chip will make a difference.
Especially this part:

feipoa wrote on 2022-02-24, 14:30:

Once I stop playback and refresh the screen, the corruption is gone.

pshipkov wrote on 2022-02-24, 20:50:

That's why i thought there is a software issue at play and was skeptical that swapping the main chip will make a difference. Esp […]
Show full quote

feipoa wrote on 2022-02-24, 14:30:

So I am pretty much back to square one, which was just having some mild image corruption if I used the MVP-2000 to playback MPEG files. Once I stop playback and refresh the screen, the corruption is gone. Also still have the issue of VGA "signal out of range" when I go to shutdown when using the GT drivers. I've never been able to resolve this, even if I create a custom monitor file and limit the refresh rate to 60 Hz.

That's why i thought there is a software issue at play and was skeptical that swapping the main chip will make a difference.
Especially this part:

feipoa wrote on 2022-02-24, 14:30:

Once I stop playback and refresh the screen, the corruption is gone.

That was old info. The symptoms had changed recently to show corruption WITHOUT MPEG playback. This is why I started changing components. This detail is buried in there, but I guess it is too buried. I suppose it is possible that the MVP-2000's original memory was having issues, but why wouldn't the NEC memory work well on it? The IBM memory I put back onto the MVP-2000 was not the memory originally from the MVP-2000 - it was from the 2 MB upgrade card.

It continues to trouble me that the NEC memory works fine on the PCI Vision968 card w/MPEG-1 installed (NEC memory), but not on the VLB card. There's more to this story...

Hello

10µF Tantalum is not reason for image corruption.

I think: your VLB card has issuses to driving extras 4 memory chip. I have also this problem whit my homemade 968VL and i have changed resistor on CAS/RAS line. -> Problem are solved

one quesition: Are image corruption come slow about picture and only on area, which it is supported by 2nd 2MB memory ?

regards
matt

Madao: When I had the NEC EDO VRAM installed on the MVP-2000, I mostly had image corruption on only the 2nd MB part of the screen. However, even at 1280x1024x256c, which only uses up to 2 MB, I would see very small bits of corruption on the START button and some other minor areas in Win95c. But with 1280x1280x24bit, the corruption would be on the bottom half of the screen. The corruption would start with a few horizontal lines (on bottom of screen), then after about 30 seconds, it would fill the whole bottom half of the screen.

For some whatever reason, using the IBM *G5B-70 EDO VRAM mostly solved the issue. The MVP-2000 came with IBM *G5D-70, but I replaced it with IBM *G5B-70. I still see corruption on areas surrounding the MPEG-1 playback screen w/*G5B-70 (when using built-in decoder), but it goes away when the mpeg window is closed and screen refreshed. If I put the NEC memory back on the MVP-2000, then bottom half of screen shows corruption with and without mpeg-1 playback. I noticed you are using the TI variant of the memory, but I haven't tried these.

I assume you are referring to RAS' (memory pin 26) and CAS' (memory pin 39) of the EDO VRAM? You previously had 33-ohms and swapped them all to 10-ohms? With two resistors per IC and 8 memory chips, that's 16 resistors. Did you also experiment with 22-ohms and other values to find the value with least reflections?

From your comment on RAS'/CAS' resistor values, it seems that perhaps the IBM memory has more desirable impedence characteristics for the Diamond PCB, that is, compared to the NEC.

Any chance you have found the 86C968 datasheet? I know you located the 964.

Do you have any more homemade VL968 boards? If so, I'd be interested in one.

Side note: I'll probably be assembling your Trio64V+ cards in the next few weeks, one with the Trio64V+, the other with Virge.

EDIT: I presume the circled resistors are the items of interest. However, there are more than sixteen 33-ohm resistor positions; I count 25 here. So I guess I'd find the ones which go to RAS'/CAS' on the onboard memory and external memory and swap them out.

Hi

Oh ok, failure is a bit other than my case. My case: i got overall corrpution, after i have added 2nd 2MB. I have added 10 Ohm resistor instead 33 Ohm on RAS0 (pin 64) issuses is solved.
You can try short this resistor array (RP8) with wire (pin 64, RAS0 ),

Vision964 Datasheet, you can use it, it is electrian similar to 968. I have there a Vision968 datasheet, but it is more like shortform datasheet.

I have few 968VL card left, are you really interessing on this card -> write me a PN.

regards
Matt

OK, thank you for the clarification on the single 968 chipset pin #64 at RP8 to wire to 10-ohm instead of 33-ohm, and not the CAS/RAS pins from the memory itself. I would likely wire a 200-ohm trimmer to these pads and dial in the resistance based on oscilliscope reflections or visible distortion on the screen. Unfortunately, this would require me to solder the NEC memory back onto the MVP-2000 board. Having the IBM memory on the MVP-2000 doesn't cause an issue when NEC memory is installed on the Diamond Stealth64. I'm not sure I'm ready to put the PCB through this abuse right now, but maybe in the future - especially if the symptoms return.

Or perhaps the resistor mod will resolve issues with the temporary corruption with MVP-2000 MPEG-1 playback. I'll update the post if/when I test this out in the future.

pshipkov wrote on 2021-03-30, 00:45:

Something that i remember - related to overlays getting in the way.
Searched online and found this: http://diamond.retropc.se/driver/stealth/64v3 … x0/mvp2k402.txt
There are notes about power saving features and screen savers. That probably was it.

Under "Known Limitations", I found this:

On the Stealth64 Video 3000 Series, in some virtual modes, some desktop noise may appear while panning. This problem is being investigated.

That might mean that this would be a software issue. I think it's about time we'd make a list of all the drivers that are compatible with this chipset. I saw someone mentioning Trio64 and Trio64+. It might be worth it to check if those drivers have anything in common or could even be compatible.....?

I've got 2 of these Diamond Stealth 64 VRAM VLB cards + 2MB addon, both showing artifacts/artefacts (both seems to be correct) under Windows 3.11 and 95 (dotted lines and more corruption, until resizing or moving windows).

Both my cards work at 40MHz and 33MHz bus clock on a Soyo SY-4SAW2 Rev WA3, and show no signs of hanging or artifacts under DOS or games. They only show artifacts under the Windows Desktop Environment. Which seems to be very odd to me.

@feipoa, awesome job on the testing on your card.

InjecTioN: Your artefacts, if they are always occur, are probably bad RAM or bad RAM solder joints. If you lower your resolution and colour depths, do you still see the artefacts?

I was going to begin moving my MVP-2000 + Diamond Stealth 64 VRAM VLB to a slower system. The system the card is in now, an Am5x86-160 can decode these videos in software. I was going to move the MVP + Diamond to my IBM BL3-100 system. Does anyone know if this system is fast enough for the MVP-2000? I figure these MVP-2000 cards, when used on VLB, must have targeted Intel DX2-66 systems. The IBM BL3-100 would be a bit slower than a DX2-66.

Since the Am5x86-160 is fast enough to decode mpeg-1 videos in software, I decided to pull my Diamond graphics card + MVP-2000 and put it in a system which would actually benefit from the decoder card. I placed it in my IBM Blue Lightning BL3 100 MHz system containing the BL3 hacks, Re: Creating a voltage regulated 386 BL3 module from existing parts

Even at only 33 MHz FSB, the S3 968 chip gets rather hot at 62 C. In fact, the whole card gets rather warm with the MVP-2000 installed. Thus, I have added an in-case re-circulation fan. Not the most elegant, but at least keeps the 968 chip under 40 C.

This system is setup with WIN 3.11, WIN 95, NT 3.51, and NT4. Running the MVP-2000 in Windows 95 with an MPEG-1 video, I see that the CPU usage is at about 90%. EDIT: It seems that the Resource Monitor CPU usage indicator isn't really accurate. I ran it again and it shows only 37% usage. Sometimes only 12%. I guess we can only go off of skipped frames and sound.

There were no lost frames from what I could discern. I also ran the same MPEG-1 video without the Diamond MVP-2000 overlay and the skips are quite plentiful.

Next, I wanted to see how slow I could make my system and still play videos with the MVP-2000. Unfortunately, the turbo function on my motherboard doesn't work well with the IBM BL3 installed, thus I have hooked the Turbo switch up to the FSB jumper so I can get 25 or 33 MHz FSB on the fly. Also, I can set 1x, 2x, or 3x in the BIOS, as well as enable/disable L1 and L2 caches.

I am running the following tests in Windows 3.11. I ran the Windows 95 test just to see how much CPU is being consumed. Does anyone know if there is a CPU usage indicator for Windows 3.11?

Some rough figures from this setup, using Landmark Speed v2.0 and quoting the ALU/FPU results.

L1 enabled, L2 enabled
100 MHz = 230/224 (ALU/FPU)
75 MHz = 172/169
33 MHz = 77/129
25 MHz = 57/97

L1 disabled, L2 enabled
25 MHz = 43/91

L1 disabled, L2 disabled
25 MHz = 21/72

I was able to play the MPEG-1 video using all the above combinations, but only did I start to hear some sound skips with the very last configuration (25 MHz, L1/L2 off). Thus, I suspect even a 486 SX-25 or -33 would be sufficient. I looked thru the MVP-2000 manual to determine the minimum system requirement, but there was no mention of it anywhere. The main issue with running the system slower was the horrific delay in loading the Media Player application.

The biggest problem is the way MVP-2000 interfaces with S3 chip using shared memory bus. Artifacts are the results of overloaded bus, probably not designed to be this long and with so many chips hanging off of it. This might even somewhat explain higher Virge chip temperature. Wonder if it ever worked correctly, or maybe what you are seeing is aged silicon issues.
Btw afaik IBM wasnt manufacturing any ram at that point, those are chips rebranded for IBM by IBM.