pshipkov wrote on 2026-06-24, 19:30:

running SCANDISK.EXE actually fixes the 80x25 text mode

what 😮
I would start with another motherboard.

Yeah - my reaction exactly.

This is not a mobo issue - cross checked with other boards. It is the videocard.

Hi,

If running an executable fixes the issue, then the problem most likely is the way the some of the ICs are initialized on the card, my primary guess would be that some registers of the CRTC, or interface to the Character ROM are being wrongly initialized.

If it does the same in another MB then it is most likely an issue with the card itself, if graphics modes work then it is unlikely to be a VRAM issue as graphics modes generally use more VRAM and accesses it more often.

As a possible workaround, if you have MS-DOS installed you can try running:

1MODE CO80

To reinitialize text mode, most likely you will get the same result as with SCANDISK, just not have to run a full application to do it, if it is the case you can put it into AUTOEXEC.BAT and you will get a good screen after the end of each boot process, not having to run a separate application to get a correct display.

Could try changing motherboard cache, or RAM. The screen is written into there before copied to video card memory.

Sounds as if the character part of the rom corrupted or does not read properly.

Scandisk might load a custom font.

Which card is this exactly? I'd agree that it sounds like a bad character ROM. Cards with the 928 generally have a single ROM chip. On TheRetroWeb there are ROMs for Diamond Stealth Pro and Miro miroCrystal 24S ISA. If you have one of those cards, I'd first dump the current content of your ROM, erase (most are UV-EPROMs, if you don't have a UV light, use the sun) and then re-program with the image from TheRetroWeb.

With a different card I might still do the same, just with less certainty (and trying images from both cards instead of just one), which makes the backup of the current content all the more important.

Mode.com co80 messes up the display as during (re)start.
An interesting observation: running mode.com co40 changes the geometry of the elements but font is still wrong.
Running scandisk.exe and exiting causes the 40 column display mode previously set through mode to show properly.

Rest of the components are solid - work fine with many videocards, etc.

Diamond stealth pro rev3 s3 928-p.
I have the same card with s3 928 hat works fine on the same setup (rest of the components).

Changing eprom and bios versions results in the same outcome which indicates that something else is off with the card itself.
About to socket all zigzag chips and test a different set of them to see if that makes a difference.

pshipkov wrote on 2026-06-28, 01:22:

Mode.com co80 messes up the display as during (re)start. […]
Show full quote

Mode.com co80 messes up the display as during (re)start.

Rest of the components are solid - work fine with many videocards, etc.

Diamond stealth pro rev3 s3 928-p.
I have the same card with s3 928 hat works fine on the same setup (rest of the components).

Changing eprom and bios versions results in the same outcome which indicates that something else is off with the card itself.
About to socket all zigzag chips and test a different set of them to see if that makes a difference.

While this means that unfortunately MODE CO80 cannot be used as a workaround this means that the card has a problem with the standard 80 column colour text mode or its initialization, as an additional debug step this can be tried:

1MODE CO40

If this also results in corruption then it is all standard colour text modes that has the problem, not only the 80 column one.

Sometimes debugging takes a lot of steps until the issue can be isolated, socketing the chips can be a debugging step too, but usually more of the memory is used in graphics modes, however the access pattern to the memory can be different so it might be still worth to try.

By Changing EPROM and BIOS version do you mean the MB or the card itself? If the issue is with the character ROM it might reside in a separate chip to the BIOS ROM of the card.

double check my previous response - the notes about 40 columns text mode.

i know the mobo and the rest of the components are 100% fine.
i changed the eprom chip and bios versions on the video card, this ruled out faults from that side.

it is puzzling to me how scandisk.exe fixes things. this indicates a specific videocard inialization issue.

as i said - will socket the vram chips and see if one of them is flaky in some way. if that does not fix it, then the chances of repair shrink significantly.

pshipkov wrote on 2026-06-28, 02:49:

double check my previous response - the notes about 40 columns text mode.

Sorry about that, I somehow didn't noticed that you already checked the 40 column mode.

pshipkov wrote on 2026-06-28, 02:49:

i know the mobo and the rest of the components are 100% fine. i changed the eprom chip and bios versions on the video card, this […]
Show full quote

i know the mobo and the rest of the components are 100% fine.
i changed the eprom chip and bios versions on the video card, this ruled out faults from that side.

it is puzzling to me how scandisk.exe fixes things. this indicates a specific videocard inialization issue.

as i said - will socket the vram chips and see if one of them is flaky in some way. if that does not fix it, then the chances of repair shrink significantly.

While I think a fault with VRAM is unlikely to cause this issue, at least that rules out one of the possibilities, I think the issue is either:

• Character ROM
• Loading of the Character ROM into the memory
• Timing difference between the graphics and character modes.

I find the 3rd one the least likely as in the IBM compatible colour text modes the video memory should be:
8bit character then a byte containing two colour information nibbles(The background colour's 4th bit can be configured as either an index into the colour table or to define blinking), then data repeated until the end of the text mode page.
A timing difference would most likely cause not only character geometry to be broken, but colours to be broken as well.

I have found the tech spec for one of the 928 family chips on the retro web:
https://theretroweb.com/chip/documentation/db … 93186466035.pdf
While I don't know if this is the exact version of the chip on the card, the operating principle most likely stayed the same in the chip family, the most relevant part seems to be in chapter "3.4.2 Backward Compatibility Modes Setup", it is small enough to quote:
1. Character Generator Locking. The VGA BIOS reloads the character generator each time an alphanumeric mode is set whereas non-VGA modes (CGA, MDA, and Hercules) do not. Therefore the character table must be loaded onto plane 2 when the controller is still in the VGA mode.

There are other details about how character modes work in that document, but that might be details linked to a specific revision of the chip, so with other revisions of the 928 it might be not relevant.

Again sorry that I cannot offer more to help.

There are multiple ideas how software can influence whether text mode display correct characters:

• The standard VGA text mode is 720*400, requiring special hardware logic to expand the 8-pixel charactes to 9-pixel characters. The BIOS initializes the character generator by loading the 8*16 characters, and then applying a list of "patches" for characters like "+" and "m" which have special 9-pixel variations that use all 8 pixels for display and rely on the hardware 9-pixel expansion to insert spacing between the characters. If SCANDISK plays around with the character font and tries to reset to the default font on exit, it might forget to ask the BIOS to apply the 9-pixel patches. Assuming the patch list in the video ROM is broken, not applying these patches can generate the issue mentioned in the OP.
• Furthermore, the 8-to-9 logic used in 720*400 mode makes dithered areas look ugly, because the 25%, 50% and 75% dithered "block graphic" characters tile perfectly in 8-pixel fonts, but generate artifacts if expanded to 9 pixels. Some text mode user interfaces purposefully switch to the EGA-compatible 640*350 text mode using an 8*14 font instead of a 9*16 font. SCANDISK might do so and leave the card in 640*350 instead of 720*400.
• The EGA/VGA card can have multiple character sets loaded to video RAM at the same time. The BIOS initializes only the first character set. There is a special mode in which bit 3 of the foreground color is used to select between two different fonts. A program that does not need 16 colors, but more than 256 characters (e.g. to get all 256 standard characters and some "magic" characters that represent a pixel-accurate mouse pointer over the charcters it currently is at) might load the standard font into a second location in video memory as well. If a card accidentally uses the second location instead of the standard location for character fonts, it might display garbage until something is loaded into the second location.

Also, if the issue is related to font loading by the BIOS, the issues should disappear as soon as you use DISPLAY.SYS and MODE CON CODEPAGE to use Codepage 850 instead of Codepage 437, because this will replace the BIOS-provided font by a DOS-provided font. Furthermore, if DISPLAY.SYS is loaded, you should be able to switch to a 43-line text mode (MODE CON LINES=43?). That mode uses the EGA-type 640x350 resolution and an 8*8 pixel font. If the issue is related to a 9-pixel wide font, you should be able to see it in 25-line and 50-line mode, but not in 43-line mode.

Good notes. Thanks.

I don't have ANSI.SYS and DISPLAY.SYS on the SD card. Use DOS in its most cutdown form.
Even if some combination of these drivers and MODE.COM ends-up working that won't be a useful solution for me.

Socketed the VRAM chips, used different set - same problem. This confirms that the issue is not related to any of the main components of the video card.

Took a closer look at what SCANDISK.EXE does.
A small routine establishes text mode 3 and loads 8x8 font from ROM for 43 line EGA and 50 line VGA layouts.
Extracted it in its own executable - basically, what you suggested above, in ~250 bytes.

Still, it is puzzling why things don't work now during normal system initialization as it used to about 2 weeks ago. Nothing changed in the system configuration.