86Box/86Box

CL GD5434 (Diamond SpeedStar 64) corrupt full screen DOS window in Windows 3.11

Teppic1 opened this issue · 26 comments

What happened?

When restoring a full screen DOS window the display is completely corrupted. Returning it back to a window and the screen is fine, switching back corrupts again. It happens on all resolutions/depths.

Using Diamond's Windows 3.1 driver (1995) from here:

http://vogonsdrivers.com/getfile.php?fileid=833&menustate=0

I noticed this is also the case with the Windows SVGA driver on all the Cirrus Logic SVGA cards, which as far as I know should work fine with that driver.

7DcuObu

Configuration file

[General]
vid_renderer = qt_software
force_43 = 1

[Machine]
machine = isa486
cpu_family = i486dx2
cpu_speed = 66666666
cpu_multi = 2
cpu_use_dynarec = 0
fpu_softfloat = 1
time_sync = local
fpu_type = internal
mem_size = 8192

[Video]
gfxcard = cl_gd5434_diamond_a3_isa

[Input devices]
mouse_type = msserial

[Sound]
fm_driver = nuked

[Network]
net_01_link = 0
net_02_link = 0
net_03_link = 0
net_04_link = 0

[Storage controllers]
hdc = ide_isa
cassette_mode = load

[Hard disks]
hdd_01_parameters = 17, 15, 900, 0, ide
hdd_01_fn = images/msdos6.vhd
hdd_01_vhd_blocksize = 1024
hdd_01_speed = ramdisk
hdd_02_parameters = 17, 15, 900, 0, ide
hdd_02_fn = images/storage.vhd
hdd_02_vhd_blocksize = 4096
hdd_02_speed = ramdisk
hdd_01_ide_channel = 0:0
hdd_02_ide_channel = 0:1

[Floppy and CD-ROM drives]
fdd_01_type = 35_2hd
fdd_01_turbo = 1
fdd_02_type = 525_2hd
fdd_02_turbo = 1
fdd_01_image_history_01 = Speedstar64 Windows3.1 Driver Disk ver2.04.IMA

Operating system

Windows 10

CPU

i7 7500

86Box version

5437

Build architecture

Windows - x64 (64-bit)

Build type

  • New recompiler
  • Debug build

Download source

Official website (Jenkins, GitHub)

Additional context

Floppy image with driver

Speedstar64 Windows3.1 Driver Disk ver2.04.IMA.zip

Also tested CL GD5426 (Diamond SpeedStar Pro) with Diamond's drivers for that card and the exact same problem occurs, though this seems buggier as it also won't work in anything except 640x480.

This appears to be a regression, since I recall this working correctly.

I tried v3.7.1 and had the same problem there, both with the Diamond driver and the Windows SVGA one.

I did some more testing and found that restoring the window does also corrupt the image sometimes (and then it permanently corrupt for both), e.g. DOS editor:

nq3yjyt

There doesn't seem to be a problem if you select 16 colours with the Windows SVGA driver. Microsoft's notes say that the cards are supported with 256 colours however. On the Diamond driver you cannot select lower than 256 colours.

What was the last time it worked properly? Bisect then.

I went back as far as v3.0 and the problem is identical with both drivers.

The problem is the same with all the CL cards with the SVGA driver as well on this version.

Ok, it happens only when the corresponding PIF is run, but not when the DOS .com file is run directly.

Do you mean File->Run command.com from Program Manager? As it still happens for me that way.

Also, does this happen in other emulators just in case? (for a bare test)

PCem 17 doesn't support the Diamond GD5434. The driver doesn't work properly on the 5434 supported (it ignores settings changes and only displays 640x480), but you do get the same corruption.

Any other emulator?

I don't know of any others that would support the Cirrus chipset.

Something I did notice that might be helpful is Microsoft says the OAK OTI77 card is supported by the SVGA driver as well, and that has identical corruption.

This fixes the issue with the Windows SVGA driver, but the issue is still present with the Diamond drivers.

After a bit of testing, the problem isn't fixed with the Windows drivers either. Still corrupt.

If you run just a basic DOS prompt with the SVGA driver it appears to work. However it you run any full screen program, e.g. edit, it's permanently corrupt in both modes.

Jq4SWIZ

With the Diamond driver there's no change from before.

Try the latest build once it finishes compiling.

Ok, with build 5469 and Diamond drivers:

The full screen DOS window is mostly ok but there's a white square showing which seems to vary based on the pointer from Windows:

5Fi6LKe

And when going back to windowed mode, there's now some corruption that wasn't there before (top of the screen and the fonts):

msACw2K

And with the Windows SVGA driver on the current build the corruption is back on the basic DOS prompt like before.

Try now, and I've personally tested both ends, they work fine.

On 5470:

With Diamond drivers, testing 800x600:

The DOS screen white square has gone away and it's showing a fixed Windows pointer instead (not the DOS mouse pointer). It only shows this if the Windows pointer is in the upper area of the screen when you switch.

The corruption in Windows is still there.

With SVGA driver everything seems ok.

On 5470:

With Diamond drivers, testing 800x600:

The DOS screen white square has gone away and it's showing a fixed Windows pointer instead (not the DOS mouse pointer). It only shows this if the Windows pointer is in the upper area of the screen when you switch.

The corruption in Windows is still there.

With SVGA driver everything seems ok.

You sure about the corruption in Windows?

Monitor_1_20240207-004904-511

No bugs here.

Ok, I checked again and the corruption seems to happen only in 16m colour mode. On 256 and 64k it looks fine.

(Both 640x480 and 800x600)

02gwLV4

Try now.
(Note: now it must work since I've personally tested the true color mode myself).

The latest build gets rid of the corruption in Windows but brings back the DOS corruption (both modes) when you run a program like edit.

Also breaks the DOS switching on the SVGA driver again.

Try now, it must work.

Try now, it must work.

Looking good.

Tried SVGA (256 colours) and Diamond (256 and 16m) and both are switching back and forth without any corruption, and I can't see any Windows corruption either. I tried normal DOS and using edit.

The only thing that might be wrong is the Windows cursor appears fixed in place still when you switch to full screen DOS mode. Maybe it's a bug with the driver itself? (though it doesn't happen with the SVGA driver).