First post, by coolhaken
Hi,
The ETEN Chinese System supports Hercules card.
A file named as ET16N.COM is the main program.
I can run it in DOSBox 0.74 , but the screen doesn't display correct.
Please look the snapshot below:
Hi,
The ETEN Chinese System supports Hercules card.
A file named as ET16N.COM is the main program.
I can run it in DOSBox 0.74 , but the screen doesn't display correct.
Please look the snapshot 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?
1+1=10
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:
23609344: INT10:Function 8E00 not supported
23609401: INT10:Function 9100 not supported
23688783: BIOS:INT16:Unhandled call DB
23688932: INT10:Set Video Mode 7
23688932: INT10:Set Video Mode 7
23688932: MOUSE:New video is the same as the old
23907002: VGAMISC:MC6845:Write 2 to illegal index 8
23907083: VGAMISC:MC6845:Read from illegal index 38
23907090: VGAMISC:MC6845:Write 48 to illegal index 38
23907099: VGAMISC:MC6845:Read from illegal index 31
23907106: VGAMISC:MC6845:Write 84 to illegal index 31
23907115: VGAMISC:MC6845:Read from illegal index 32
23907122: VGAMISC:MC6845:Write 40 to illegal index 32
23907131: VGAMISC:MC6845:Read from illegal index 35
23907138: VGAMISC:MC6845:Write F to illegal index 35
23907163: VGAMISC:MC6845:Read from illegal index 38
23907170: VGAMISC:MC6845:Write 0 to illegal index 38
23907227: VGAMISC:MC6845:Read from illegal index 15
23907234: VGAMISC:MC6845:Write 96 to illegal index 15
23907243: VGAMISC:MC6845:Read from illegal index 38
23907250: VGAMISC:MC6845:Write 48 to illegal index 38
23907259: VGAMISC:MC6845:Read from illegal index 32
23907266: VGAMISC:MC6845:Write C to illegal index 32
23907275: VGAMISC:MC6845:Read from illegal index 35
23907282: VGAMISC:MC6845:Write F0 to illegal index 35
23907307: VGAMISC:MC6845:Read from illegal index 38
23907314: VGAMISC:MC6845:Write 0 to illegal index 38
24050769: VGA:h total 54 end 70 blank (70/54) retrace (43/50)
24050769: VGA:v total 334 end 408 blank (408/334) retrace (408/424)
24050769: VGA:h total 0.05400 (18.52kHz) blank(0.07000/0.05400) retrace(0.04300/0.05000)
24050769: VGA:v total 18.03600 (55.44Hz) blank(22.03200/18.03600) retrace(22.03200/22.89600)
24050769: VGA:Width 1120, Height 408, fps 55.444666
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:
case 0x01: //Horizontal displayed chars
+ if (val==0x46) val=0x28;
if (vga.other.hdend ^ val) VGA_StartResize();
vga.other.hdend=(Bit8u)val;
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?
1+1=10
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?
1+1=10
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:
- INT10_SetupVESA();
+ 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.
1+1=10
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... 😀