Running this application in M.E.S.S 0.140,
I got the snapshots below ...

I have a TSR program that simulates some text modes using hercules graphics by hooking INT 10h and intercepting all text display functions. DOSBox's shell bypasses the INT 10h interface and calls its text display function directly, so the simulated text modes don't work properly with the shell; however, programs running in DOSBox that write to the display entirely through INT 10h work fine.

Booting real DOS in DOSBox is the best way to make sure all shell-related output goes through INT 10h. It might not be the entire problem with the program you're trying to use, but it's likely to be at least part of the problem.

Did you try a SVN version of DOSBox? Is this software available for debugging?

I have tried to boot real DOS in DOSBox.
The screen shows the same problem like my first post.
Even the SVN build has the same problem.

Seems like there's a few unhandled CRTC registers being used:

1  23609344: INT10:Function 8E00 not supported
2  23609401: INT10:Function 9100 not supported
3  23688783: BIOS:INT16:Unhandled call DB
4  23688932: INT10:Set Video Mode 7
5  23688932: INT10:Set Video Mode 7
6  23688932: MOUSE:New video is the same as the old
7  23907002: VGAMISC:MC6845:Write 2 to illegal index 8
8  23907083: VGAMISC:MC6845:Read from illegal index 38
9  23907090: VGAMISC:MC6845:Write 48 to illegal index 38
10  23907099: VGAMISC:MC6845:Read from illegal index 31
11  23907106: VGAMISC:MC6845:Write 84 to illegal index 31
12  23907115: VGAMISC:MC6845:Read from illegal index 32
13  23907122: VGAMISC:MC6845:Write 40 to illegal index 32
14  23907131: VGAMISC:MC6845:Read from illegal index 35
15  23907138: VGAMISC:MC6845:Write F to illegal index 35
16  23907163: VGAMISC:MC6845:Read from illegal index 38
17  23907170: VGAMISC:MC6845:Write 0 to illegal index 38
18  23907227: VGAMISC:MC6845:Read from illegal index 15
19  23907234: VGAMISC:MC6845:Write 96 to illegal index 15
20  23907243: VGAMISC:MC6845:Read from illegal index 38
21  23907250: VGAMISC:MC6845:Write 48 to illegal index 38
22  23907259: VGAMISC:MC6845:Read from illegal index 32
23  23907266: VGAMISC:MC6845:Write C to illegal index 32
24  23907275: VGAMISC:MC6845:Read from illegal index 35
25  23907282: VGAMISC:MC6845:Write F0 to illegal index 35
26  23907307: VGAMISC:MC6845:Read from illegal index 38
27  23907314: VGAMISC:MC6845:Write 0 to illegal index 38
28  24050769: VGA:h total 54 end 70 blank (70/54) retrace (43/50)
29  24050769: VGA:v total 334 end 408 blank (408/334) retrace (408/424)
30  24050769: VGA:h total 0.05400 (18.52kHz) blank(0.07000/0.05400) retrace(0.04300/0.05000)
31  24050769: VGA:v total 18.03600 (55.44Hz) blank(22.03200/18.03600) retrace(22.03200/22.89600)
32  24050769: VGA:Width 1120, Height 408, fps 55.444666
33  24050769: VGA:normal width, normal height aspect 2.058824

1120x408... didn't know hercules gfx could do that much resolution. 😀

Can hack it into displaying correctly:

1    case 0x01:      //Horizontal displayed chars
2+      if (val==0x46) val=0x28;
3       if (vga.other.hdend ^ val) VGA_StartResize();
4       vga.other.hdend=(Bit8u)val;
5       break;

0x28 (40) yields 640 horizontal in graphics mode, so why it writes 0x46 (70) is puzzling. It appears the value is hard-coded, not calculated (or miscalculated); and the write mask on the register is 0xff according to docs.

I've only found the program malfunctions on a Hercules/VGA dualscreen machine.
Maybe it misdetects the adapter type in DOSBox?

The application errors out with an "Incorrect display adapter" message in official releases of DOSBox, but the port 0x3bf fix for Spacewar in current source has fixed that.

ET16N.COM is specifically for MDA/Hercules, so there's not much it could misdetect. I wonder how something like this software could work on plain MDA...

Maybe real hardware has a sanity check on the horizontal size?

On real hardware if hdend > htotal the memory address does not increase and thus the same scanlines are repeated on the screen. And even if it did have such a check, why would it choose exactly 640 pixels? 😉

About the dual screen setup - I was able to run it fine with only the Hercules card in the PC. With VGA and Hercules, the latter monitor would desync and the VGA display garbage.

Maybe additional code should be executed that sets the values right?

h-a-l-9000 wrote:

why would it choose exactly 640 pixels?

Because when it writes 0x46 (1120 pixels), the register contains 0x28 (640 pixels), so the imagined sanity-check would be to ignore the weird value.

Was the VGA card you were testing with an S3 model?

The app searches the 0xc000 segment for the string "S3 Incorporated", and actually finds it, even though machine=hercules. So it seems writing 0x46 to index 1, and the illegal index reads/writes mentioned before, are an extra thing it does that it should not.

Made this change in int10.cpp, and the display problem goes away:

1-   INT10_SetupVESA();
2+   if ((IS_VGA_ARCH) && (svgaCard==SVGA_S3Trio)) INT10_SetupVESA();

Not sure if the VESA bios stuff should be set up for the other SVGA card types; but if so, it would probably be better if the OEM string was correct.

Ah, a known problem. Having a video rom where none should be.

Yes, S3 card.

At first blush, while I am insisting on using MB6. What happened to MB6, why eten chinese system won't work for MB6? I need some details, too lazy to dig out everything... 😀