S3 Trio64 and S3 Virge fixes/undocumented features

Post new patches here!
Post Reply
twilen
Posts: 3
Joined: Fri 14 Aug, 2020 9:21 am

S3 Trio64 and S3 Virge fixes/undocumented features

Post by twilen »

I found following bugs and undocumented features when I implemented Amiga CyberVision 64 and CyberVision 64/3D emulation using PCem S3 Trio64 and S3 Virge emulation. Not sure if any PC software depends on these.

S3 Trio64: CGX4 driver unexpectedly sets all blitter clipping values to 0xFFF and expects blitter to not clip anything. (Weird, isn't it?)

S3 Virge: monopattern first horizontal bit is bit 7, not bit 0. ("mono_pattern[y*8 + x] = virge->s3d.pat_fg_clr;" -> "mono_pattern[y*8 + (7 - x)] = virge->s3d.pat_fg_clr;" and so on, without this change pattern is unaligned.)
S3 Virge: blitter undocumented feature. CGX4 (again..) uses ROP D=S in rectfill mode (Virge documentation says source must not be used with rectfill, only pattern is allowed). Rectfill works correctly if both source and pattern equals pattern color instead of setting source=0. ("uint32_t source = virge->s3d.pat_fg_clr, dest, pattern = virge->s3d.pat_fg_clr;"). I assume linedraw also works identically but I can't test it.
S3 Virge: s3_virge_recalctimings() does not recalculate svga->hdisp, if resolution changes on the fly, vga->hdisp *= (svga->seqregs[1] & 8) ? 16 : 8; is not executed and in some situations width of screen becomes very small.

Both also don't emulate 0x3C2 VSYNC bit 7 or support vsync interrupts. (I guess PC boards rarely if ever used these)

(No patches, sorry. I needed other updates to remove other PCem dependencies and I didn't want to create patches that don't fully apply)
twilen
Posts: 3
Joined: Fri 14 Aug, 2020 9:21 am

Re: S3 Trio64 and S3 Virge fixes/undocumented features

Post by twilen »

S3 Trio blitter: SRC-BASE/DST-BASE was unimplemented. This is used by Picasso96 driver if 4M VRAM model. (S3 blitter is quite strange..). Also clipping region apparently should use unsigned values. When driver does blit that crosses 2M "border", it sets SRC/DSTBASE to 2M, then uses negative start y-coordinate. This would get clipped incorrectly if signed comparison is used. (NOTE: patch most likely won't merge cleanly due to reasons described above. sorry)
Attachments
s3trio_blitter.patch
(12.95 KiB) Downloaded 15 times
Post Reply