What the people were talking about: Newer VGA cards often remove the 8x14 font from the ROM to make more space for advanced features. If a program requests the 8x14 font, it will get the 8x16 font instead. All characters of that font will be garbled, mostly containing vertically shifted version of other characters. Your symptom looks clearly different, though: Some characters look fine, and other characters of the same size are completely broken. So it seems like there is a partial font in the ROM, maybe they left some characters in the ROM to get some specific program to work. The font used by that application might indeed be the 8x14 BIOS font.

You should be able to find TSR tools that supply the missing font from main memory. You can test whether they help with your tool.

I tried "Fix8x14" from here: https://www.bttr-software.de/products/fix8x14/

But that doesn't have effect on the problem with these programs. So I think it's not the 8x14 font.

How many different font are in the VGA BIOS which can be missing on the newer ones? Is it possible to see what the different available fonts are between a good working one and a corrupt one?

Hi there. My apologies for intrusion into this topic. I don't know how to exactly fix things, but I have ideas to try out.
Please don't be upset if they don't work. They're just ideas.

a) You can try loading QEMM. It has a Stealth mode which moves Video BIOS and other things around in memory. That maybe fixes memory corruptions/conflicts.
b) Try out a different code page. Normally, German DOS uses CP850 and loads EGA.SYS, ANSI.SYS etc.
In short, it tinkers with EGA/VGA fonts. By REMing them out, CP437 get loaded (US default, code page traditionally stored in ROM).
c) Try another version of DOS which uses a custom VGA font. Like Japanese MS-DOS (DOS/V 6.20).
You can use US and JP command to switch between two code pages (CP437 and Japan/Kanji).
Your program may or may not work in Japanese mode. It's just a try.
d) Use Virtual PC 2007 and MS-DOS 6.22 (VM), if you're running XP (or to a strech Vista/7) on that laptop.
It's not worse than command prompt on Windows. Virtual PC has its own VGA graphics (S3 Trio32/64), so it's unaffected.
e) Use MS-DOS Player, it's a command line tool that lets MS-DOS programs run.
https://www.zophar.net/pc/ms-dos-player.html
f) try to play with MODE MONO and MODE CO40 and MODE CO80 on DOS.
g) Try out custom VGA fonts. They have *.FNT extension, I believe. They replace the standard font in RAM.

Anyway, again, these are just ideas. Wild ideas, so to say.
Ideally, the source of the problem is being found, so that a proper solution can be made out.

Good luck! 😀 🤞

Edit: I have a wild guess were the problem might come from - the BIOS splash screen / boot screen.
Some later PC BIOSes used custom text glyphs to draw GUI elements in text-mode (like a Windows-like mouse cursor or a hour glass on DOS) or for displaying a logo.
Like that Energy Star logo. It usually is assembled out of a dozen of individual text characters that are being custom/modified.
And maybe the standard VGA font wasn't being properly restored after the POST screen was shown for whatever reason.
Anyway, it's just a wild guess. The chance is low that this is really the case. It's just a possibility that crossed my mind. 😅

This program uses graphics mode, and seemigly only some of its own fonts, expecting others to be readable out from video BIOS in designated locations (which most BIOSes try to follow from what I see), where stuff seems not to be found on this particular card. There isn't any TSR that can fix this problem when the program goes directly hunting for the character data, only way is patching the video BIOS shadow but then where will all the code that lives in place of the character data go... 🤣

Tiido wrote on 2023-07-06, 07:59:

This program uses graphics mode, and seemigly only some of its own fonts, expecting others to be readable out from video BIOS in designated locations (which most BIOSes try to follow from what I see), where stuff seems not to be found on this particular card. There isn't any TSR that can fix this problem when the program goes directly hunting for the character data, only way is patching the video BIOS shadow but then where will all the code that lives in place of the character data go... 🤣

The problem with programs hunting for font data at fixed hardcoded addresses ist mostly limited to CGA/MDA applications, trying to find the 8x8 font in the main board BIOS (which only contains basic ASCII, i.e. character codes 0-127).

EGA/VGA introduced an API to retrieve the address of all ROM fonts which is generally used by applications. The TSR program will hook that API and return the 8x14 font from that TSR instead of a crippled or missing 8x14 font in the BIOS. This kind of TSR is known to actually fix most problems with BIOSes lacking an 8x14 font. As EGA introduced an API for retrieving the font addresses, and because applications generally use this API, there is no generally accepted fixed location of these fonts in the video BIOS, so using fixed addresses will fail on a lot of hardware.

In this case, we see some characters (letters) of the font being drawn correctly, whereas other characters of the same font (digits) are random garbage. If the program was expecting the font (8x14 or 8x16) at a address that's not valid on the video BIOS of that system, all characters would display incorrectly. So I am confident that the "bad fixed address" theory does not apply in this case.

Ok, this is good to know. I have been slowly gathering some info about related matters since in my todo list there's to make an actual all new video card and a lot of stuff seems to have to stay in specific locations or compatibility gets harmed and this was the first thought I had. Do you happen to have or point to some more info etc.

Tiido wrote on 2023-07-06, 10:02:

Ok, this is good to know. I have been slowly gathering some info about related matters since in my todo list there's to make an actual all new video card and a lot of stuff seems to have to stay in specific locations or compatibility gets harmed and this was the first thought I had. Do you happen to have or point to some more info etc.

There is some magic going on in the first 256 bytes of the Video BIOS. Nearly all clone cards contain the string "IBM compatible" in them, so I guess some ancient software checks for "IBM" at a fixed location, and they added "compatible" to avoid trademark infringement lawsuits (please no discussions on whether IBM would have a case here or whether adding "compatible" is an effective remedy against an infringement). Other than this, EGA/VGA BIOSes seem to not require fixed locations.

The API used to find fonts is INT 10h, AX=1130: http://www.delorie.com/djgpp/doc/rbinter/id/63/1.html

Video mode parameters and customizable parameters are referred to by the "save table", which is pointed to by a fixed location in the BIOS data area. The position of th save table in the EGA/VGA BIOS is not fixed. See https://stanislavs.org/helppc/video_information.html , especially "EGA / VGA related tables".

mkarcher wrote on 2023-07-06, 20:01:

There is some magic going on in the first 256 bytes of the Video BIOS. Nearly all clone cards contain the string "IBM compatible" in them, so I guess some ancient software checks for "IBM" at a fixed location, and they added "compatible" to avoid trademark infringement

Dumping Video-7 EGA card's bios, in the image I see the following text at the very beginning of the rom: 'Note: Some code expects "IBM" here!', followed by the usual "VEGA BIOS Code, Version 1.08..."
Even back then in 1987 they had no clear idea on why it's there, but apparently it was needed 😀

I was using a MS-DOS bootdisk with empty autoexec.bat and config.sys so it didn't load code pages.

QEMM seem to be installed to hard drive and not for use on a DOS bootdisk. I tried JEMM386 with FreeDOS instead and that doesn't solve the problem.

The same bootdisks works fine on PC's with a "good" video BIOS, so the problem isn't lying in the bootdisk.

The BIOS splash screen is turned off, without difference.

Running the software in a emulator like DOSbox do display it correctly, but the software is for use with a hardware device with doesn't work with a emulator.

This program is clearly using the 8x8 font, and apparently only the digits and the space. Unlike the 8x14 case, this font should be present in all video BIOSes.

But as mkarcher points out, there's another possible source for this font: the lower 128 characters of the 8x8 font are present in the system BIOS itself, too. This goes back to the original IBM PC, where the CGA's character ROM wasn't addressable by the host, but an addressable font was needed to print text while in graphics mode. Unlike the EGA/VGA case (or the CGA's upper 128 chars, normally loaded by a TSR like GRAFTABL), there's no system call or interrupt vector that provides a pointer to it; so for compatibility's sake, it typically appears at the hard-coded location F000:7A6E. See the "Notes" here.

In the unlikely case that the program goes looking for font data there, the problem would be in the system BIOS rather than the VBIOS. A simple test would be to dump the BIOS and check the contents at that address (compared to that from a known-good system, or from DOSBox for that matter). If that's the issue, I guess the only workable solution would be to patch the program itself.

I don't know how to dump the BIOS of the Pentium 4 (a HP Compaq dc7100) which is not compatible with the popular BIOS flash tools.

But I did a test with a old ATI 3D Rage II PCI graphics card which works in a slot1 Pentium 3 board with correct characters. I put this card in the Pentium 4 and the characters are still corrupted. So you're right the problem isn't the video BIOS.

I also find out there's at least one modern PC where the characters are shown correct (and has a floppy drive to boot from): some Athlon II X2 250 on a ASRock N68-GE3 board and a GeForce 8 graphics card.

Is it really the system BIOS? 🙁

Or maybe it's specific HP/Compaq BIOS? A laptop that showed bad characters was a HP Pavilion ze4400 with Athlon XP. And a HP dc5750 desktop with Athlon64 is also bad.

Yeah, since you've eliminated the video BIOS, and there's another PC where it works correctly, that strengthens my suspicion that the program is trying to load those characters from the system BIOS.

It could very well be that specific era of HP/Compaq BIOS firmware... I located a couple of BIOS update downloads for the ZE4400 and the DC5750. The raw .BIN files evidently contain more than just the system BIOS (they're 512k and 1MB respectively), but they're uncompressed, and using a binary image viewer I can't see anything that looks even remotely like an 8x8 font. I guess they didn't really expect users of that era to be running anything which actually needs the BIOS font data (and honestly they were mostly right - I mean, what else would be looking for it... GWBASIC?)

If you really want to, you could dump the BIOS using a utility like NSSI (Tools → Save BIOS), but while that'd make the diagnosis more certain, it won't help with a fix. Hopefully, it'll be simpler for you to just run the software (with its hardware device) on that other machine which does play nice with the text.

The part of the font that *is* provided by the program looks suspiciously close to one of the Borland BGI charsets... does the program contain ".BGI" files, by any chance? Could be interesting to see if "BGIDEMO.EXE" (from one of Borland's DOS compilers) has the same problem.

This thread reminds me of a related issue: Broken 8x8 text mode font on nVidia FX series?. In that case, the BIOS Patcher from rom.by (by default it removes the 8x8 font without warning, and the command line switch to prevent the removal doesn't work 100% reliably) was the culprit even though the OP was misled into looking elsewhere.

The programs don't have BGI files. And not all the PC's on which it's corrupted have nVidia graphics.

I tried a few more PC's. On a HP Pavilion p6550 (Pentium Dual-Core) it surprisingly works fine. But on a HP 8200 Elite (i5) it's corrupt.

On a self-build PC with ASRock K10N78 board and Athlon II X2 it works fine.

I wanted to try some Dell systems but on both a Vostro 400 (Core2Quad) and a Optiplex 9020 (i5) one program gives a black screen and the other program draws pixel-by-pixel very slow. I think the graphics card doesn't support some DOS video modes (both have a modern GeForce GTX1050). And on a Dell Latitude D600 laptop (Pentium M) the program just won't start.

I tried to dump the BIOS with NSSI from the HP dc7100, but it only come up with the attached 64KB file. A don't think the BIOS is just 64KB.

Gmlb256 wrote on 2023-07-19, 14:28:

This thread reminds me of a related issue: Broken 8x8 text mode font on nVidia FX series?. In that case, the BIOS Patcher from rom.by (by default it removes the 8x8 font without warning, and the command line switch to prevent the removal doesn't work 100% reliably) was the culprit even though the OP was misled into looking elsewhere.

Nice - yeah, I bet that's the exact same problem. That one is definitely a BGI issue (as I'm suspecting here), and if it's caused by a BIOS patch overwriting the font area, then BGI must be looking in the system BIOS for parts(!) of its default 8x8 font.

Which makes me curious whether anyone's ever made a patch to fix the BGI code for newer systems with less-compatible BIOSes, maybe by using the 8x8 VGA charset instead... much like Borland executables can be patched to fix the "runtime error 200" issue on fast CPUs. Of course, only Borland could explain why they felt compelled to go with such a back-asswards scheme in the first place.

Fiena wrote on 2023-07-19, 15:24:

I tried to dump the BIOS with NSSI from the HP dc7100, but it only come up with the attached 64KB file. A don't think the BIOS is just 64KB.

That's good - the relevant part is 64KB (segment F000), and I can see that's what your file is, based on the system ID byte at offset FFFE (FC = AT compatible).
And this confirms it, since offset FA6E doesn't have the 8x8 font, nor does it appear anywhere else. Here's DC7100.BIN compared to the same location in a compatible BIOS file:

The lack of .BGI files doesn't rule it out, since the BGI drivers could've been statically compiled into the executable... and that other case has also ruled out the graphics card as the culprit. Based on that and on the 'good' parts of the font, I'd say it's the same issue.