The game fails to set mode 0x203, which is not in DOSBox's VESA or S3-specific mode list, causing the error message. Setting mode 0x103 (VESA 800x600x256) instead works to an extent, but the display is partly messed up and there is a repeated debug warning: "XGA: DrawBlitWait: Unsupported src 3". Tried machine=svga_s3, machine=vesa_nolfb, machine=vesa_oldvbe, loading UNIVBE, and MB6, all with the same result. I guess the mode is just not supported (yet).

LineWars II allows for a custom graphics driver (GRAPHDRV.LW2); I wonder if one was ever made for VESA modes...

Doubt it. If anything, only Patrick Aalto would know. you could email him

Hi ripsaw,

I'm confused by, "The game fails to set mode 0x203, which is not in DOSBox's VESA or S3-specific mode list"

Does the game fail to set that mode, or does it set that mode which is unrecognized by DOSBox?

DOSBox currently does not recognize mode 0x203, and returns an error when the game tries to set it.

Just wait for h-a-l-9000 to post here, he's currently fiddling with dosbox' S3 Vesa emulation.

I think the s3 card LW2 was developed on wasn't even VESA compliant. It's definitely pre-Trio

This is what it looks like with mode 0x103 substituted for mode 0x203:

The lower status portion of the display is correct; the upper portion is partly messed up and flickering.
The flickering looks like page-flipping of misaligned pages.

Works when using ELSA_WINNER1000_2.22.00_86C764_PCI.BIN

No idea why though.
A secret of mode 203h is that its 75Hz.

> "XGA: DrawBlitWait: Unsupported src 3"

1Index: src/hardware/vga_xga.cpp
2===================================================================
3--- src/hardware/vga_xga.cpp	(revision 3684)
4+++ src/hardware/vga_xga.cpp	(working copy)
5@@ -686,6 +686,9 @@
6 								case 0x01: // Src is foreground color
7 									srcval = xga.forecolor;
8 									break;
9+								case 0x03:
10+									srcval = XGA_GetPoint(xga.waitcmd.curx, xga.waitcmd.cury);
11+									break;
12 								default:
13 									LOG_MSG("XGA: DrawBlitWait: Unsupported src %x",
14 										(mixmode >> 5) & 0x03);
15

By "works" do you mean it displays correctly, or that it just succeeds in setting mode 0x203? Because when I load that bios image, the mode change works (odd thing: debug log message says 792x600), but the display is messed up much worse than setting 0x103 instead of 0x203. The DrawWait change doesn't make a visible difference, probably because the screen is too garbled to tell. Any other secrets that you are you using?

Oops, I used the MB6 sources as I was too lazy to enable ldgfxrom in the SVN build. Seems there is something else from it needed too.

> odd thing: debug log message says 792x600
This is a +1 issue with the blanking register: ... end 100 blank ( 99 ...

> The DrawWait change doesn't make a visible difference
I think I had spotted one but now I'm not so sure anymore... black areas around vessles in certain circumstances.

The planet does not show up on a real hardware Trio64 (the bastard).
The bottom area with the shield/armor display (which was swiped from Wing Commander 😉 ) is not fully correct in DOSBox.

This is the change in MB6 that makes it work with the BIOS:

Index: src/hardware/vga.cpp =================================================================== --- src/hardware/vga.cpp (revisi […]
Show full quote

Index: src/hardware/vga.cpp
===================================================================
--- src/hardware/vga.cpp (revision 3684)
+++ src/hardware/vga.cpp (working copy)
@@ -65,7 +65,7 @@
switch (vga.s3.misc_control_2 >> 4) {
case 0:
if (vga.attr.mode_control & 1) { // graphics mode
- if (IS_VGA_ARCH && (vga.gfx.mode & 0x40)) {
+ if (IS_VGA_ARCH && ((vga.gfx.mode & 0x40)||(vga.s3.reg_3a&0x10))) {
// access above 256k?
if (vga.s3.reg_31 & 0x8) VGA_SetMode(M_LIN8);
else VGA_SetMode(M_VGA);

Here's a TSR program that adds partial support for mode 0x203 (800x600x256 @ 75Hz) in DOSBox 0.74. There is still the problem with the missing XGA:DrawWait operation, and the status meters don't have their interior blocks, but I don't know of anything else that's not working. Only tested with LineWars II, of course. Run DOSBox with the -noconsole parameter or the log messages from the XGA warning will cause slowdowns (it may happen in some places, anyway).

@hal: the ELSA bios uses mode 0x4b internally for mode 0x203, and even writes it as the current mode in bios data; but it doesn't write it to 0x3ce index 5... if it did, your patch to vga.cpp wouldn't be needed. The highlighted blocks in the status meters are shown very briefly when the flight screen is first drawn, but then disappear. Maybe the thermometer bars are drawn with a masking operation (or/xor) that isn't working.

Hmm did you figure out which of the register values of mode 0x103 are wrong?

If I set mode 0x103 instead of 0x203 and then:

Write 0x80 to 0x3d4 index 0x13
Write 0x00 to 0x3d4 index 0x50

The display looks OK. Some other stuff is needed to get 75Hz, but don't know if that's really important or not.

Hi!

I only just ran accross this thread, sorry for being a few months late!

Very interesting (and humbling) to see my old LW2 game getting special support in DOSBox! Thanks for your interest and work on it! 😀

The S3 hardware that I targetted in LW2 was the original S3 911/924 adapter, and I also had to make some changes later on to be able to support adapters up to 864. However, on adapters later than 928 the Linear Address Window handling was changed, and I used that to draw the planet directly to the graphics adapter RAM, so the code disables direct graphics memory access in adapters later than 928.

I still have the full source code of LineWars II, and can post the S3 -relevant parts if those are still needed or useful? For example, this is the part that tries to determine the adapter type:

1        ;-------
2        ; Get chip revision:
3        ; AH = 81h = 86C911
4        ; AH = 82h = 86C924
5        ; AH = 90h = 86C928 Rev A
6        ; AH = 91h = 86C928 Rev C / Rev D
7        ; AH = 94h = 86C928 Rev D / Rev E
8        ; AH = A0h = 86C801/86C805 Rev A or Rev B
9        ; AH = A2h = 86C801/86C805 Rev C
10        ;-------
11        mov     al,30h
12        out     dx,al
13        inc     dx
14        in      al,dx
15        mov     ah,al
16        dec     dx                      ; DX = 3D4h
17        cmp     ah,90h
18        jb      i_old_s3
19IF 1
20        cmp     ah,0C0h                 ; 0C1h = S3 864
21        jae     i_old_s3
22ENDIF
23        ;-------
24        ; Modify code for 86C801/86C805/86C928
25        ;-------
26        mov     cs:[s3_NOP_or_AND],0FE24h       ; { and al,0FEh }
27        mov     cs:[s3_NOP_or_OR],010Ch         ; { or al,1 }
28        ;-------
29        ; 801/805/928: CPU Base Address bits 18 and 19 = 0 (use only 1 MB)
30        ; Note: 801/805 Rev B error: Accessing CR51 using word I/O accesses
31        ; occassionally causes the display to jump.
32        ; Solution: Use 8-bit I/O when accessing CR51.
33        ;-------
34        mov     al,51h
35        out     dx,al
36        inc     dx
37        in      al,dx
38        and     al,11110011b            ; bit18 = 0, bit 19 = 0
39        out     dx,al
40        dec     dx
41        ;-------
42        ; 801/805/928: Set Linear Address Window into 0A000h
43        ;-------
44        mov     ax,0A5Ah                ; OUT_CRT 05ah,00001010b
45        out     dx,ax
46        mov     al,59h                  ; OUT_CRT 059h,00000000b,11111100b
47        out     dx,al
48        inc     dx
49        in      al,dx
50        and     al,11111100b
51        out     dx,al
52        dec     dx                      ; DX = 3D4h
53i_old_s3:

Patrick "Pate" Aalto

DOSBox-X developer here:

I got the Line Wars II S3 acceleration working properly by modifying the 800x600 mode (mode 0x203) to have 1024 bytes per scanline instead of 800 bytes per scanline.

I don't see any attempt by the game to change the "offset" register to manually program 1024 bytes per scanline, so I'm curious why a 800x600 mode needs to be arranged that way to render properly?

Did the S3 card BIOS at the time program 800x600 mode in any unusual way?

For example, DOSBox-X has code to emulate the S386c928 and the Windows 3.1 drivers for that card have an odd 24-bit SVGA mode that aligns the bytes per scanline to a power of 2, and it expects the BIOS to set it up that way when it uses that mode.

Also according to "XGA: DrawBlitWait: Unsupported src 3" it's trying to XGA rect draw combining video memory with... video memory. What's the purpose of that? The graphics seem to render properly if that is ignored regardless.

https://github.com/joncampbell123/dosbox-x/issues/5124

TheGreatCodeholio wrote on 2024-07-16, 17:43:

I got the Line Wars II S3 acceleration working properly by modifying the 800x600 mode (mode 0x203) to have 1024 bytes per scanline instead of 800 bytes per scanline.

That's exactly what the tweak mentioned in my previous (a mere 13 years ago) post does. Maybe the 1K "stride" of the lines allows efficient programming at a cost of inefficient use of video memory -- the LW2 developer didn't really know why it's like that when I asked but he mentioned it made some things easier.