I believe mode 54h (132x43) was changed to the 8-line font because that's accurate to real S3 video cards, but mode 55h (132x25) still has the 16-line font. As a result the 132x86 text with mode 54h and loading the 8-line font is no longer possible, but you can still get 132x50 with mode 55h. The VESA text modes are separate and not related to the SVGA text modes.

You can create any combination of display size (within reason) and font (even custom fonts) that you want by correctly setting the CRTC registers and writing appropriate values into BIOS memory, but it's obviously more involved than just requesting BIOS to set a particular mode number. See here for an example.

ripsaw8080 wrote:

I believe mode 54h (132x43) was changed to the 8-line font because that's accurate to real S3 video cards, but mode 55h (132x25) still has the 16-line font. As a result the 132x86 text with mode 54h and loading the 8-line font is no longer possible, but you can still get 132x50 with mode 55h. The VESA text modes are separate and not related to the SVGA text modes.

You can create any combination of display size (within reason) and font (even custom fonts) that you want by correctly setting the CRTC registers and writing appropriate values into BIOS memory, but it's obviously more involved than just requesting BIOS to set a particular mode number. See here for an example.

I do realize this is an old thread, but I think it's important. Not only was mode 54h changed to 8-line font, but the corresponding VESA text mode 10Ah was also set up with 8-line font in the same commit. Now while this might seem like a logical thing to do at first, it does cause a problem. As an example, the program VACSID (which is something like Cubic Player, but for SID files) has a 132x43 mode (it doesn't support 132x50 or 132x60) which doesn't work properly because of this (it computes the amount of lines separately and ends up assuming there are 86 lines). Now you might say "VACSID doesn't even work at all in Dosbox anyway", but it does work in the Daum build. Besides, this is just an example, there might be other programs that are affected too.

My suggestion would be to change mode 10Ah to 16-line font (or at least add an option to the config file to switch that), it's not meant to be a hardware specific mode anyway, so the argument that S3 cards work that way doesn't really apply there.

If someone here wants to change this and recompile the Daum build, here's what you need to change in the file int10_modes.cpp, first the old line, then the new one:
{ 0x10A ,M_TEXT ,1056,688, 132,43, 8, 8, 1 ,0xB8000 ,0x4000, 160, 449, 132,344, 0 },
{ 0x10A ,M_TEXT ,1056,688, 132,43, 8, 16, 1 ,0xB8000 ,0x4000, 160, 800, 132,688, 0 },

After this, the TEXTUTIL tool for 132x86 will work again after a minor modification (use mode 10Ah instead of 54h).

But in the end, this is just a workaround. For the next Daum version, I'll need to patch the files again. So I'd really appreciate it if this could be changed in the regular Dosbox SVN. I'd do it myself, but I don't think I have the access rights to do a commit there, and even if I did, I wouldn't just change something without asking first.

AJN wrote:

Now while this might seem like a logical thing to do at first, it does cause a problem. As an example, the program VACSID (which is something like Cubic Player, but for SID files) has a 132x43 mode (it doesn't support 132x50 or 132x60) which doesn't work properly because of this (it computes the amount of lines separately and ends up assuming there are 86 lines).

VACSID is working for me in SVN with the 132x43 textmode, and it does not assume there are 86 rows. It has an option specifically labled as "132x43", but nowhere is "132x86" even mentioned. It's understandable that you'd appreciate the 86-row display using the 8-line font that it allowed as a consequence, but it was nonetheless incorrect for DOSBox to use the 16-line font for 132x43. You can, of course, patch the source to use the previous behavior for your own builds, but hexediting of binaries is discouraged.

AJN wrote:

Now you might say "VACSID doesn't even work at all in Dosbox anyway", but it does work in the Daum build.

Actually, VACSID works in vanilla SVN DOSBox if you hack the weird character it uses in the "_VACSID_.DSC" filename (underscores used to denote where 0xFA was originally used). I don't know what Daum does; perhaps it adds 0xFA to the allowed list.

ripsaw8080 wrote:

VACSID is working for me in SVN with the 132x43 textmode, and it does not assume there are 86 rows. It has an option specificall […]
Show full quote

AJN wrote:

Now while this might seem like a logical thing to do at first, it does cause a problem. As an example, the program VACSID (which is something like Cubic Player, but for SID files) has a 132x43 mode (it doesn't support 132x50 or 132x60) which doesn't work properly because of this (it computes the amount of lines separately and ends up assuming there are 86 lines).

VACSID is working for me in SVN with the 132x43 textmode, and it does not assume there are 86 rows. It has an option specifically labled as "132x43", but nowhere is "132x86" even mentioned. It's understandable that you'd appreciate the 86-row display it allowed as a consequence, but it was nonetheless incorrect for DOSBox to use the 16-line font for 132x43. You can, of course, patch the source to use the previous behavior for your own builds, but hexediting of binaries is discouraged.

AJN wrote:

Now you might say "VACSID doesn't even work at all in Dosbox anyway", but it does work in the Daum build.

Actually, VACSID works in vanilla SVN DOSBox if you hack the weird character it uses in the "_VACSID_.DSC" filename (underscores used to denote where 0xFA was originally used). I don't know what Daum does; perhaps it adds 0xFA to the allowed list.

Interesting. Yes, you're right, it works in EmuCR R4000 when I rename the dsc file and hack the exe accordingly. I didn't expect that at all. So the reason for this misbehavior is actually the Daum build. Well, in that case it's obviously not necessary to change anything. And here I thought I found something helpful. Oh well ...

Say, is the 8-line font thing actually normal for the 132x43 mode? Or is that a special property of the S3 card? I assumed the latter, but now I'm not so sure anymore.

Also, I still don't understand how that special character in the file name caused VACSID to crash. Could you explain that? And in which file is that "allowed list" where I could add that character?

And finally, I understand why exe hacking would be discouraged ... but it was the fastest way for me to fix the problem, and I'll keep it private. I also removed the hex patch part from my previous post, recompiling is definitely better. I'll try that again later. Also, I might try Dosbox-X too, I just found a binary for Windows.

AJN wrote:

is the 8-line font thing actually normal for the 132x43 mode? Or is that a special property of the S3 card?

The 8-line font is quite normal for anything more than 25 rows of text, except perhaps on specialized displays such as portrait orientation types used for word processing. If you are skeptical, you can load compatible video BIOS ROM images and VESA drivers in DOSBox SVN and set the modes you're interested in to see how they behave regarding fonts, row counts, and line counts.

43 rows is historically related to 350-line EGA displays. The normal 25-row textmode used the 14-line font: 25*14=350, and loading the 8-line font: 43*8=344.

AJN wrote:

I still don't understand how that special character in the file name caused VACSID to crash. Could you explain that?

When DOSBox encounters a character that is not allowed in a filename it returns an error to the DOS program attempting to create or open that file. VACSID aborts when its attempt to create or open its .DSC file fails.

AJN wrote:

in which file is that "allowed list" where I could add that character?

Certain non-alphanumeric characters allowed in real DOS can be problematic in the filesystems of host platforms, and DOSBox's internal DOS emulation filters some (but not all) of them out for local folders mounted as emulated drives. The filter is in the DOS_MakeName function in dos_files.cpp; however, even if a character you add to the allowed list there works on your host OS, that does not guarantee it will work correctly on other platforms.

BTW, if you boot a disk image with real DOS in DOSBox then weird characters in filenames becomes a non-issue, because in that environment real DOS is free to do most of the things that it allowed.

Update: Just tried Dosbox-X, same problem as in Daum. The bottom part with the message is missing. I attached a screenshot. Strange ...

ripsaw8080 wrote:

43 rows is historically related to 350-line EGA displays. The normal 25-row textmode used the 14-line font: 25*14=350, and loading the 8-line font: 43*8=344.

I see! I thought it might be something like that, but I forgot. But the 30-row mode should still be with 16-line fonts, right? Because there's also a 60-row mode.

ripsaw8080 wrote:

BTW, if you boot a disk image with real DOS in DOSBox then weird characters in filenames becomes a non-issue, because in that environment real DOS is free to do most of the things that it allowed.

Does that also work if I just mount the disk file and not boot from it? Because if I boot, some things are not available, like the virtual Z drive.

AJN wrote:

Update: Just tried Dosbox-X, same problem as in Daum. The bottom part with the message is missing. I attached a screenshot. Strange ...

SVN has improvements related to updating certain BIOS and video hardware parameters after a font is loaded; those might not have been adopted elsewhere (yet).

AJN wrote:

But the 30-row mode should still be with 16-line fonts, right? Because there's also a 60-row mode.

Yes, it relates to standard VGA line counts: 25*16=400, 30*16=480.

AJN wrote:

Does that also work if I just mount the disk file and not boot from it? Because if I boot, some things are not available, like the virtual Z drive.

Nope, because you can have local folder drives and image drives mounted simultaneously. Either you use the internal emulated DOS or you boot real DOS, with all of their inherent abilities and restrictions.

I noticed the screen height value of mode 10Ah is still set to 688, which means it actually is possible to get 132x86 by programming the CRT controller. A bit more difficult than I thought, but it was still fun and also interesting. Here's the result, made with debugx in 132x86 text mode, and tested with the latest SVN build. 😀

I made a small change to the file and uploaded it again. Nothing major, but I did overwrite the bits 4-6 of the vertical retrace end register before. Now those bits are preserved. It seemingly didn't really make a difference in this case (the bits were zero before, and the byte I wrote also had zeroes in those bits), but you never know ... maybe they are not always zero.

Just looked it up, they are used to increase the refresh cycle per line from 3 to 5 (bit 6) and to enable or disable the vertical retrace interrupt IRQ2 (bit 5 and 4). So they probably are important.

A good reference can be found here: http://read.seas.harvard.edu/cs261/hwref/ibm-vga.txt

And getting back to the original question (although it's probably too late now), it's actually quite simple to switch the font size, so I made some tools for setting 8x8, 8x14 and 8x16. That's all the predefined fonts, but of course it's possible to make your own, maybe even with a height different from 8, 14 and 16 (not sure yet). But changing the char width is probably not possible.