The artifacting reduced by 95% when using the 33 MHz front-side bus on the Daewoo board, compared to 40 MHz on the Asus board. Whether the artifacting is due to an overloaded bus on a long/crowded PCB, or due to or ageing silicon, I don't know, but I suspect the former. I don't think Diamond had a whole lot of sales with the MVP-2000 targeting the VLB platform. Looking through the manual, the VLB variant notes show up in the addendum.

Even with the artificating, it only shows up temporarily on the screen surrounding the overlay box. Once you refresh the desktop, the artifacting disappears. It would be interesting to test the same MVP-2000 board in a PCI system with a 40 MHz FSB.

Any idea who IBM was buying the VRAM from in 1994-1995?

Speaking of the VRAM, the NEC memory I had ordered had some of the surface print ruined (evident on page 2). This was because the manufacturer had placed tape over the IC's to hold them onto a foam backing board. I'm not sure why they weren't sold in tubes. Possible fakes? Removing the tape pulled some of the wording off. I was able to fix the wording, for the most part, using some thermal grease and isopropyl. The lack of consistency in the black colour on the casing of the IC makes me suspect they are fakes. Has anyone seen this non-homogeneous zone in the black plastic casing on memory modules?

Shown below are the fixes. Goofed up RAM print is on page 2 of this thread, here: download/file.php?id=131329&mode=view

Got no idea about the artifact issue, sorry, but back on the software front, wasn't Xing MPEG player the one that came with S3 boards? Or was that the one for boards only with scaling support, not decoding support? Anyway, it's the one that sticks in my mind the most.

BitWrangler wrote on 2023-04-09, 04:53:

Got no idea about the artifact issue, sorry, but back on the software front, wasn't Xing MPEG player the one that came with S3 boards? Or was that the one for boards only with scaling support, not decoding support? Anyway, it's the one that sticks in my mind the most.

Well, if it was, I certainly didn't see any acceleration being used when I tried playing mpeg videos with Xing MPEG player.

As I said problem with this design is everything and a kitchen sink communicating on a shared memory bus. Garbage on screen happens when something is able to sneak its way into Video ram chips which are not being addressed at the time.
The way I read the thread at first everything was fine with VLB card, and VLB card + memory expansion, and only some minor artifacts showed up at the bottom while playing video (not counting overheating and overclocking VLB). Now I lost the plot somewhat and dont know what happened after memory swaps, but it sounds like everything went bad until you restored old ram on the VLB card?

Afaik when movie is being decoded the only data movement on that bus is:
- compressed stream being send to decoder, probably using some special fixed address outside of any Video ram range or dedicated /WE signal.
- video data being scanned out for output on the screen
at no point in time does _anything_ write to video ram.

Potential causes when movie is being decoded:
- [bad timings, reflections, crosstalk] somehow being interpreted by some ram chips as Write Enable signal
- power supply sag resulting in slow data retention loss. This one is less likely because reads internally refresh/rewrite ram contents, and just scanning out screen is half of the refreshes this ram requires (16ms vs 8ms).
- overall bus overloading resulting in lower signal strength across whole S3 bus driver and marginal signal levels, /WE is active low so sagging could trigger some more sensitive or further away chips?

One thing that comes to my mind is looking up ram datasheet, identifying /we pins
https://www.datasheetarchive.com/pdf/download … &term=uPD482445
https://datasheetspdf.com/pdf/541818/IBMMicro … ics/IBM025171/1
pins 24 25, now tracing them out to memory expansion connectors, putting a scope on appropriate pins on those connectors and looking whats going on there.
From what I remember Madao was building his own VLB S3 Vision/Virge card from scratch so he might be the best source of information about expected levels/slew-rates.

Clarity on the plot:

1) Diamond VLB with IBM memory and IBM 2 MB memory module has no artifacting (because MVP-2000 decoder card not installed)

2) Diamond VLB card with NEC memory and NEC 2 MB memory module has no artifacting (because MVP-2000 not installed)

3) Diamond card MVP-2000 decoder card shows artifacting with IBM memory and with NEC memory only when using the overlay video window. Swapping from IBM 70 ns to NEC 60 ns did not help with artifacting.

4) I noticed some additional issues with the MVP-2000 decoder card having the NEC memory installed, that is, I saw some artifacting when not using the decoder card. This never happened before. Possibly some memory incompatibility, a bad RAM module, or a bad solder job. These SMD chips are pretty easy to solder and I would be surprised if it was a bad joint. I put the IBM memory back onto the MVP-2000 card and the non-overlay-related artificating is gone. Still have just the overlay artifacting.

5) I am currently using the Diamond card with 4x NEC memory chips on the VLB card and 4x IBM chips on the MVP-2000 card. It is only the MVP-2000 which didn't like the NEC memory.

6) Moved the VLB+MVP2000 to a new, slower system, using the IBM BL3-100 at 33 MHz FSB, rather than the Am5x86-160 at 40 MHz FSB. The artifacting almost disappeared entirely.

Another user here, elianda, also has this hardware combination. His website: https://retronn.de/imports/hwgal/hw_graphics_ … 2000_front.html When discussing with him in private, he didn't notice any artifiacting on his, I think, DX2-66 system. Thus, I suspect there is some aspect of my particular hardware which does not cope well with 40 MHz. I pulled my MVP-2000 from a PCI card. I think user elianda got his with a VLB card, but I'd have to check my notes on this. However, I was also using a SCSI VLB card on my Am5x86-160 system, and the L1 was in WB mode.

I think I have some Samsung and OKI branded 60ns EDO VRAM (256Kx16) I could try on the MVP-2000, but I don't really want to disturb the RAM again when the hardware is working well at 33 MHz. The extreme artifacting I showed photos of with Am5x86-160/40 does not occur on my BL3-100/33 system. I might get a blue pixel here and there.

EDIT: I checked my parts bin. Aside from the IBM 025171LG5B-70 and NEC D482445GW-60, I have some desoldered OKI MSM5416263-60, which is also EDO, 256kx16, and SOP64. According to the datasheet, they also came in 50 ns.

I have an idea for easy quick hack to check if its /WE - very weak pullups on /WE signals going to ram chips. Starting with something super safe like 10Kohm pulling to 5V.
Madao card project - S3 Vision 968 VLB replica he had to fine tune ras line termination resistors to get rid of artifacts.

I'm not sure if I would classify this as a quick hack. There are two WE# pins per memory module, with 4 modules on the VLB card and 4 modules on the MVP-2000 card. That's 16 resistors and 16 bodge wires. I'd also need to setup a system for 40 MHz since my current system is fine at 33 MHz.

only two /WE signals on 968 and whole card

I didn't check how they are connected. They are all ganged up, I take it?

I might try this bodge if symptoms persist at 33 MHz, or if I'm feeling adventurous and want to setup a testbed for 40 MHz in the future. I'll keep it in the back of my mind.

I guess you could see if they were on the edge at 40 by sticking them in a socket 7 or slot 1 system that does 83Mhz with no fixed PCI clock and seeing if they're worse at 41.5. Could be bus noise on that particular system.

VLB card so no pentiums 😀
I would also trace /CAS /RAS lines and look for termination resistors (as Madao suggested), maybe there are some on MVP-2000 and one is damaged

rasz_pl wrote on 2023-04-09, 22:29:

VLB card so no pentiums :)
I would also trace /CAS /RAS lines and look for termination resistors (as Madao suggested), maybe there are some on MVP-2000 and one is damaged

Yeah, it is on my list still. I haven't forgot about Madao's suggestions. But before I would do anything, I would want to put the MVP-2000 onto a PCI system and see how it performs w/PCI @33, 40, and 50 MHz.

Good to hear you are finding better home for this one.

Just remembered something - disabling hidden refresh (decoupled refresh) can potentially improve on visual artefacts in some cases.
Did you try that ?

pshipkov wrote on 2023-05-06, 07:27:

Just remembered something - disabling hidden refresh (decoupled refresh) can potentially improve on visual artefacts in some cases.
Did you try that ?

I don't recall, but I'll keep that in mind. I've already moved the MPEG-1 decoder card to my IBM BL3-100 system, which at 33 MHz FSB, doesn't have the artifact issue.