Greetings, LQ. I've searched Google a bit and searched the forums here but didn't find anything yet. I have a circa 1997 PC for retro gaming with a CF -> IDE adapter so I can "multiboot" by simply swapping CF cards. This PC is an i430TX, 128MB RAM, AMD K6/233, SB16 CT2260, S3 Virge/GX 4MB, Voodoo1 4MB, and DFE 530TX+, and the monitor is a Dell E177FP.

In MS-DOS + Windows 3.11 everything works fine. Windows runs 1024x768x16 using the S3 Virge SVGA driver. Opening a DOS prompt windowed and fullscreen work. When I exit Windows to DOS there is no problem. Even with UNIVBE loaded no problems.

I first noticed the problem in OS/2 Warp 4. It uses the GRADD (SciTech) S3 Virge driver and runs 1024x768x16. The main GUI is fine, opening a DOS prompt in a window is fine, but opening it fullscreen produces the tearing effect - vertical on right side of screen and some characters appear to be overlapping or missing. I'm guessing this is tearing - it might be something else. See the attached photo.

Here's the Linux part...
I booted Wolvix Linux 1.1.0 which uses Xorg 6.9.0, the s3virge driver, Fluxbox 1.0rc3 and kernel 2.6.21.5. It boots to the console where I login and type startx to launch Fluxbox. Fluxbox and X apps work well running 1024x768x16. I exit X back to the console and experience the same tearing at the same righthand position. I tried 16, 15 and 8 bit color depths. When I change the driver in xorg.conf from s3virge to vesa the tearing does not occur.

Yesterday I installed Slackware 4.0 to another "disk". XFConfig is configured for my card and monitor, X is pointed to XF_S3V, and using the "accel" driver. startx launches KDE 1.1.1, KDE works well and I personalized the background+colors, exit to the console and have the same tearing again. Again I tried both 16 and 8 bit color depths with no change.

I found one place online that mentioned vertical striping in DOS, but this was permanent beginning at boot time and caused by a leg of the gpu bent and shorting against the adjacent leg. Still, I pulled the card and inspected it closely, also taking the opportunity to clean the card edge.

Other things I have tried are disconnecting the Voodoo card and swapping the monitor with a StarLogic 15 inch LCD. At this time I don't have another VGA cable to swap with; however, the cable I am using was previously used on my main PC (GTX 260, 1280x720x32) with no problems.

I know this is probably an odd scenario and any ideas are appreciated. Thanks.

Attached Thumbnails

 

'Ah, yes, I remember it well…'

I had a K6 dual boot, and think I had an S3 Virge in it. PCI or ISA? For some crazy reason, X never cleaned out all those crappy drivers nobody uses anymore, so you may be in luck. Your distro should have xf86-video-s3virge, or something like that.
It's probably a better driver.

If the driver doesn't sort it, de-stress your video. Try 800x600 at 60 hz or slower, and work up from there. Also trawl through /var/log/Xorg.0.log to see your driver in use, and dmesg for errors. You're definitely in 'trailing edge' technology

I like the fact you are running OS2 warp. I ran 3(?) back in the day when I bought my first computer and discovered how horrible windows 3.11 was. As I remember, warp was very nice.

Thanks, business_kid. The Virge is PCI. Wolvix produces an Xorg log but there are never any errors in it because there were no problems while in X. The problem is happening after X is closed, returning to the console. In Slackware 4.0 I cannot find an XFree86 log. I can try 800x600, but wouldn't 1024x768 8bpp be low enough stress? Any 1990's SVGA card with 1MB could handle that. 2MB is enough for 1024x768 16bpp and my card has 4MB, and the monitor has a max resolution of 1280x1024.

I did suspect the "s3virge" driver in Xorg in Wolvix (2003, iirc). That's why I tried Slackware 4.0 (1999) with XFree86, when the driver's date would be much closer to the hardware. In Wolvix I did run X with the generic vesa driver and it exits to the console correctly. In Slackware 4.0 I have not yet tried a different driver but I could try the generic XF_SVGA.

@sevendogsbsd, thanks. Warp is a solid+stable OS. Mine is Warp 4.52 with all the fixpacks, with FAT32 and 2TB support. However, it is not the "better DOS than DOS" that it claimed to be - at least not for gaming. For instance, it won't play any DOS/4GW game with sound.

I've seen errors resembling your image when trying to get Quattro Pro and Paradox for DOS working after most of the video card manufacturers they supported were defunct. The only cards I found acceptable after the death of Trident and Tseng were ATI. Most of the good SVGA text modes were supported only by proprietary BIOS calls. VESA fell short by focusing on graphics modes.

If it was mine I'd remove the S3 and Voodoo and put something else in. When I was using socket 5 and socket 7 motherboards I was first using Trident and later Tseng ET6x00 PCI cards, first with DOS/DesqView, later with Warp. I'm still using Warp's progeny, ever since I got AGP, later PCIe, now with Radeon rv380 (X600) and rc410 (Xpress 200). All my K6-2/3 boxes that still worked when last tried have ET6x00 PCI.

If I couldn't find a PCI Radeon to put in I'd try a Rage or Matrox. The OS/2 crowd was high on Matrox back when I was using PCI video, might still be for those with the old hardware still running. Scitech really improved things. If you can get a Matrox or ATI working in OS/2, then Linux should be also be a "Snap".

1 members found this post helpful.

Thanks, mrmazda. I can try that during the weekend. The only spare pci cards i have are a 2mb Trident 9200 and a 64mb Matrox Epica. I have seen a lot of cheap 8mb RageXL on amazon.

The Epica I'd never heard of before. It's not in the SDD support list:It's probably too new for Scitech on MCP, but maybe good news for use with XFree.

The Epica TC2 is indeed a newer card, HD, dual head. I can't find any pre-2000 drivers for it. When I dug my Trident out of the box this morning I see it is 9680, not 9200.
I was just browsing Amazon this morning and snatched a 4MB Millennium II for $1.88! For now I'll wait until it arrives. Back in the day I mainly used Trident cards until AGP came along and I moved to nvidia.

With the Epica in your box, it's probably worth running lspci -n, getting the pci id and checking if it registers as any other card, e.g. the Matrox Millenium, which would give you a driver for it.

In the process of collecting the above, I managed to produce the same screen corruption shown in the OP. That PC has onboard Intel video. I stuck the Matrox in to fetch the device ID, and got no video with the VGA cable connected to it. I had to move the cable back to the onboard and make a BIOS setup change. That enabled me to choose from the Grub menu and see initial post messages, but at mode switch time it went black. In order to do what needed doing, I had to connect a display to each VGA output. The vttys worked on the onboard video while X worked on the MGA video. Weird.

My Matrox card arrived, and with a pleasant surprise - it includes the 4MB upgrade already attached I installed it today, booted Slackware 4.0, and ran XF86Setup. After setup I examined the XF86Config and it is now using the "SVGA" driver. With the S3 Virge it was using the "accel" driver. I launched startx in 1024x768 16bpp and the system froze after a couple of mouse clicks. So I changed it to 1024x768 8bpp and it works nicely now, and it solved the console text problems when leaving X.

The same freezing also happens in Windows for Workgroups 3.11 when using the Matrox driver but a generic vesa driver works at 1024x768 16bpp. Maybe I could try with the Voodoo card removed... I haven't booted OS/2 yet.

business_kid, the Epica was detected as an Epica with its correct id. mrmazda, thanks again. Not only does this card fix the mode switching corruption, it also crushes the S3 Virge in DOS game performance. Lol

You could try $(terminfo) and $(setterm) to fiddle with modes. Assuming that your console was okay before running X. There's also clear and reset to bring consoles back to normalcy. I seem to remember fiddling with those BITD, probably for the ascii playback for mplayer, or some (s)vga graphics while in the console. You might also check the lsmod output before and after X. Using rmmod / modprobe -r on "new" entries could restore sanity. Still assuming that the console was fine BEFORE X was used. Recalling that the framebuffer driver was used before X which launched the proprietary driver, and that the proprietary driver was used after X. Which was often buggy as all hell.

Not sure why you're using such and old box for retro games. There's tons of modern ways to run those old games on newer hardware. At a tenth or less the heat output / power consumption. I setup win95 on an old PII box about a decade ago. Which was painful at best as that old CHIP and the slow SIMM ram, it basically took four hours to do anything useful. When I'm used to setting up a fresh linux install and being booted into it in less than twenty minutes.

Shadow_7, thank you for the ideas. As to why: nostalgia. I know there are emulators and vm's and source ports. But there is something more satisfying about feeling the 90's software on period correct hardware. This is also the first pc I built in 1997, rebuilt using mostly the same parts that have stored in my closet. I didn't use Linux until 2003 so I am curious to explore an early Slackware and KDE 1.x, and I might experiment with dosemu.
Less heat? My K6-233 uses only a simple socket7 heatsink+fan without thermal paste, and the disk drives are replaced with CompactFlash cards. Slackware 4.0 boots in ~5 seconds Win95c on this box boots in less than 1 minute and Quake2 runs 20-30 fps at 640x480

I think I still have a KDE 1.0 book around here somewhere. Back when IT was promising and each book your read could mean another $1 per hour in wages. KDE was my first DE, but once I found other options, all of which were more perform-ant, I couldn't go back.

Just be aware that the m/b hardware is integrally different than stuff now, being backwards compatible. The 2.2 kernels were a lot better than 2.0 as regards interrupts.