There aren't many games that use the alternate scanlines, but I know of a couple:

Indenture uses 200 scanlines with a custom font, but I made a workaround for it here.

Wrath of Earth uses 350 scanlines with a custom font in its installer and exit screens, but it's mostly a cosmetic issue, not really important:

Because there are few games that need the feature, I didn't think support would be added internally, so I made a TSR program that acts as an extension to DOSBox's video BIOS in order to support the alternate scanlines. An archive is attached that contains a few text mode utilities that I made, including the TSR.

SCANRES.COM is the resident program that should be loaded prior to running anything that tries to change the scanlines.

CGA.COM, EGA.COM, and VGA.COM are programs that simply switch the DOS text display to 200, 350, and 400 scanlines, respectively; and SCANRES.COM must be loaded for them to work.

CLR.COM is a program to use in place of the CLS command. DOSBox's CLS sets mode 3, so you loose the current mode and any loaded font; but this program uses the scroll window function to clear the screen, as real DOS does, and the current mode and font are preserved.

*X*.COM are a bunch of programs that set a variety of text screen dimensions, including some pretty large ones.

I've only tested the utilities with machine=svga_s3, so anything else might not work. At some point I plan to roll up all these little programs into a single program that takes a command line parameter, but I haven't gotten around to that project yet.

well as our hardware emulation already supports the scanlines, I don't see a reason why our int10 loadfont couldn't support it. After all your text utils are rather small

@ripsaw8080

I tested your small tools.
I don't see any better behaviour.
The same thing happens as with my program.
If you run cga.com for example, you get a box inside the box.

Oh, when the DOSBox runs in fullscreen mode, than it works if I load
scanres before.

And with vgaonly it is not working correct. I got additional vertikal lines.
But with svga_s3 it works as you said.

Beard

The other stuff is just for changing things from the command line. All you need for that emulator is SCANRES.COM loaded in memory beforehand. It works both in windowed and fullscreen mode; you've probably made some mistake if it isn't changing the display.

@QBix, the TSR is small, but assembly is like that. The changes to loading fonts is rather small, only changing how the rows-on-screen is calculated with the variable amount of scanlines. The most significant stuff is in setting the mode, where the crtc regs need to be set differently depending on the scanlines.

@ripsaw8080
you are right. At my first test I used vgaonly as machine.
With svga_s3 and your scanres it works in both, windowed and fullscreen version.

Beard

@ripsaw, you don't happen to have that as C patch do you ?
although changing setmode is a bit tricky, but could be tested

@beard: I tried machine=vgaonly, and the utilities all work OK there, including with that emulator. Not sure what you did wrong, but try it again if you like. The 9 column font matrix makes some custom fonts look a bit odd with gaps and duplications in the 9th pixel column, but I guess that is normal.

@Qbix: It looked to be complicated to implement as a patch, and I wasn't encouraged because of its marginal applicability to games. The TSR was relatively easy to make because it lets DOSBox do most of the work, and just touches up a few things after returning from the internal INT 10 functions.

Hi ripsaw8080,

that's the problem with vgaonly!
It is a 8 by 8 font and it is handled like a 8 by 9 font.
So I get also the "one missing pixel" on the screen.
With svga_s3 it is handled correct.
I attach a small game which shows it easily.
Copy it in the same directory as the emulator.
If the emulator runs, press F9 to load and execute a file.
Choose the game and press enter.
Skip the intro with the space key.
(oh, on a real PC the intro is smooth scrolling, because it waits until the
VBlank signal of the VGA card)

The squares are normally closed.

With svga_et3000 it is ok.
Same with svga_et4000.
Same with svga_paradise.
Same with vesa_nolfb
Same with vbe_oldvbe

So only vgaonly has this "fault".

Best regards,

Beard

Ah, I misunderstood. I thought you meant it wasn't working for the double height issue.

I investigated a bit, and I think that when using 200 or 350 scanline emulation, the vga sequence clocking mode register should have bit 0 set for 8 clock characters, so you only get the 9 wide font with 400 scanlines. Seems that vgaonly pays attention to that clocking bit, but the other vga types don't, so that accounts for the difference.

A new version of scanres is attached which appears to handle the character width correctly with machine=vgaonly, and it also fixes an issue with mode 7 (monochrome text). Handles everything I've thrown at it so far.

This should be about it - thorough testing welcome.

Looks good, hal, and thanks for taking the time to work on it. Ran it through the stuff I've been testing with, and came up with a couple of issues:

- 200 line mode does not calculate the number of on-screen rows correctly. Either CurMode->sheight should be 200, or some double-height adjustment made to the INT10_LoadFont() calculation:

1real_writeb(BIOSMEM_SEG,BIOSMEM_NB_ROWS,(CurMode->sheight/height)-1);

- Setting 200 or 350 scanlines and then mode 7 gives invisible characters; not sure why that would happen... maybe font load issue?

@h-a-l-9000
I think at the end of your diff file is something wrong.

Fontload is still only possible for VGA and EGA.
So the

1if (CurMode->type==M_TEXT) {
2-		if (IS_VGA_ARCH)

should still be inside.
(with || for EGA)

Beard

P.S.: At the moment I can not compile DOSBox 🙁 so I can not really test something.

@beard: Activating some font when setting a text mode is always necessary. Loading *user* fonts is already limited to EGA/VGA:

1   case 0x11:      /* Character generator functions */
2      if (!IS_EGAVGA_ARCH)
3         break;

That's about INT10_SetVideoMode - but this part of the function will only be reached for EGA and VGA ( if (!IS_EGAVGA_ARCH) return INT10_SetVideoMode_OTHER(mode,clearmem); above).

I changed the sheight, however this is also used by the mouse and int10_misc and thus may have some side effects.

It turns out real BIOS ignores the scanline settings in mode 7.

Updated patch attached.

Unless I'm mistaken, the mouse is using sheight for gfx cursor, so shouldn't impact text modes...?

The state info in int10_misc appears to be for INT 10/1B, so maybe the question is: does real BIOS show 200 or 400 scanlines when in 200 scanline emulation?

It's used twice in mouse.cpp, once in a M_TEXT branch.

Don't know what problem it might cause, but I tried some textmode programs with mouse interfaces using 200 scanline emulation, and don't notice a difference.

EDIT: looked at Ralf Brown's info for BIOS data 0x488 and 0x489, and it suggests the lines emulation stuff uses those two bytes in a more complicated way; but what you've done in your patch is easier to follow 😀

BIOS reports 200 scanlines in 8x8 font mode, so that part is fine.

The backward compatible textmode feature may seem more useful to the DOSBox devs if more games are known to use it. I learned of a couple more games that use 350 scanlines with custom fonts: Labrynth of Zeux and MegaZeux. The former is a standalone side-view action/puzzle game, while the latter is a game-creation-system along the lines of Kroz and ZZT that still has an active community with ports to modern systems. These games use VGA features (palette stuff at least) and therefore work best with VGA, but they use 14-line fonts to maintain backward compatibility with EGA.

The games were originally shareware, but are now freeware. Community site: http://www.digitalmzx.net

@h-a-l-9000: your patch works OK with LoZ, but is causing MegaZeux to hang at startup. It is looking for bit 3 (vsync) of port 0x3da to show up, but it never does. The vsync appears to be used for a palette fade effect. I circumvented the hang with the DOSBox debugger, and the game seems to run fine after that. I tried the last DOS version by the original author (2.51), and the last community-made DOS version (2.70), and I suspect it's going to be the same for all versions. There is no hang (but the typical font glitches) without the patch. If you'd like to try it out, grab one of the DOS versions from the site noted above under the "MZX Versions" link.

Update: fix the TODO, also fixes MegaZeux.

I've checked what the S3 and ET4000 BIOS do with the values at 488h and 489h, they match my implementation more than what is described in the interrupt list. They additionally change 488h depending on the selected vertical scanlines.