Incorrect font size (intermittent)

[bdhirsch-code]

Question

I have also observed an extremely intermittent problem running our Borland compiled DOS business application in both DOSBox and DOSBox-X (running in Windows 10). The application polls the keyboard and a serial port when “resting” on the main home screen in a “roll your own” screensaver mode. The screen is kept black to conserve battery power until the user presses one of the keys, and our application will “wake up” and display the home page text. The problem is that sometimes the text appears to shrink from normal 12-14 point type to a small screen font size (~6-8 point), and the application doesn’t respond to serial port inputs either. When restarting the application everything goes back to normal.

The Windows event log doesn’t provide any clues, and the device manager reports all is normal with the serial port. Because this only rarely happens I haven’t been able to isolate the cause. We haven’t observed this behavior when running the application in native MS-DOS or ROM-DOS. Any thoughts?

Have you checked that no similar question(s) exist?

• [X] I have searched and didn't find any similar question.

Code of Conduct & Contributing Guidelines

• [X] I agree to follow the code of conduct and the contributing guidelines.

[bdhirsch-code]

I'm wondering if this could be related to our application running out of file handles or memory. Displaying the correct font most likely involves loading a font file, and if the OS has run out of file handles or memory I could see that corrupting the display of text.

[rderooy]

DOS does not load files in the background.

If you boot a guest OS DOS disk image (MS or PC-DOS), and run the application from there, do you experience the same issue?

Also, what output= option are you using? Did you try to use output=ttf?

[bdhirsch-code]

I suspect our Borland compiled application may be running low on whatever memory it's looking for (upper, extended, etc.), and not correctly reading CHR font information from the disk file into memory variable locations. I haven't attempted to boot a guest OS, but that's on my list today. I've tried all of the output options, including ttf. No change. The application doesn't use TrueType fonts, it uses CHR font files.

[bdhirsch-code]

Besides, unlike DOSBox, DOSBox-X isn't changing the Windows display resolution to 640x480, so the only way my application runs full screen is by using a different output (opengl), changing the Windows resolution to 800x600 (it won't go as low as 640x480), and then turning scale on. TTF output won't scale.

[rderooy]

Most text based DOS applications just use the standard video adapter font, and those should work fine with output=ttf. The application will not be aware that the output is being rendered with a TTF font. But if the application uses a graphical video mode and draws its own fonts, then that will not work.

[grapeli]

Besides, unlike DOSBox, DOSBox-X isn't changing the Windows display resolution to 640x480...

It may behave exactly like dosbox. By changing the configuration file:

[render]
char9=false

or directly from the menu Video---->Text-mode---->Allow 9-pixel wide fonts

or directly from the command line config -set char9=false

or directly at startup dosbox-x -set char9=false.

TTF output won't scale.

If you increase the size of the TTF font under DOSBox-X, the window will change its size. Set ptsize = as you see fit. ptsize=9 - window very small ptsize=29 -a large window

[bdhirsch-code]

The application uses a graphical video mode.

From: Robert Sent: Friday, September 30, 2022 11:30 AM To: joncampbell123/dosbox-x @.> Cc: bdhirsch-code @.>; Author @.***> Subject: Re: [joncampbell123/dosbox-x] Incorrect font size (intermittent) (Issue #3766)

Most text based DOS applications just use the standard video adapter font, and those should work fine with output=ttf. The application will not be aware that the output is being rendered with a TTF font. But if the application uses a graphical video mode and draws its own fonts, then that will not work. — Reply to this email directly, view it on GitHub https://github.com/joncampbell123/dosbox-x/issues/3766#issuecomment-1263720416 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ASV7MBHKC7TTGNFXJS2G3ADWA4BQ3ANCNFSM6AAAAAAQZFU6ZE . You are receiving this because you authored the thread. https://github.com/notifications/beacon/ASV7MBDKU7GLEAIPDLV6AWDWA4BQ3A5CNFSM6AAAAAAQZFU6ZGWGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSLKLL6A.gif Message ID: @. @.> >

[bdhirsch-code]

When you said, "If you boot a guest OS DOS disk image (MS or PC-DOS), and run the application from there, do you experience the same issue?" do you mean running the MS or PC-DOS command shell from the DOSBox-X prompt or actually booting an img file? For our application, I need to mount a couple of host directories for the application to use. These directories contain data that the application changes. In the past we used ROM-DOS for an embedded OS, but now we need to take advantage of features of DOSBox so that we can utilize a USB device that Windows exposes as a virtual COM port.

[bdhirsch-code]

Because the application behaves normally for the first few hours, I'm going to spend today eliminating Windows processes to see if one of them might be interfering with the program's operation over time. There has to be some type of memory leak or scheduled action that's causing this. I've played around with many DOSBox-X config settings and haven't found anything that prevents the problem from rearing its head after a few hours.

[bdhirsch-code]

Well, I ran the application within DOSBox-X with a minimal set of Windows services running and the problem still exists. I exited the application while continuing to run the DOSBox-X window (full screen) and then executed the application again. Everything goes back to normal when I do that so whatever is corrupting the environment only does this intermittently or there's some type of cumulative effect that slowly deteriorates the environment and resets itself upon exiting the application.

[rderooy]

I think you are on the wrong track. Eliminating host processes should not have any impact.

If possible, try to set machine=vgaonly, assuming the program runs in a VGA graphical video mode.

And yes, I did mean to actually boot DOS. You can expose host folders in the latest DOSBox-X to a guest OS as a virtual HDD. e.g., https://dosbox-x.com/wiki/Guide%3AInstalling-Windows-95#_host_folder_mounts

[bdhirsch-code]

Running in vgaonly mode doesn't solve the problem. I ran the application in windowed mode (not fullscreen), and turned on logging. Almost immediately the following log shows this message about once per second:

LOG: Serial1: Errors: Framing 0, Parity 0, Overrun RX:13 (IF0:0), TX:0, Break 0

The application is using a Serial to USB adapter (which is why we need DOSBox) for the serial port. This is our config for the serial ports:

serial1 = directserial realport:com4 serial2 = directserial realport:com1

The com4 port is the serial to USB adapter, and the com1 port is an actual serial port.

If this helps in any way, I would love to know what to do. If not, I will try to figure out how to boot ROM-DOS and expose host folders, which are on separate physical drives within the computer. One folder will become the "C" drive, and the other will become the "D" drive.

[bdhirsch-code]

When the font switched and the serial port became inactive, the error messages stopped. If I exit the application and re-enter without terminating DOSBox-X, the process repeats.

I do get the initial message:

LOG: Serial 1: Desired serial mode not supported (38400,5,n,1)

[rderooy]

5n1? That is a rather strange mode. 8n1 was the most common type, meaning (8) data bits, (N)o parity bit and (1) stop bit. Some older hardware would require (7) data bits, but I have never seen 5.

[bdhirsch-code]

Yeah, I know. It should be handshaking using 9600,8,n,1, or 38400,8,n,1. It's a serial smart card reader attached to a serial to USB converter using virtual com port 4 in Windows.

[bdhirsch-code]

OK, I can trigger the problem by performing the following steps:

1. Run the program in windowed mode (not fullscreen)
2. Resize the window (stretch the window horizontally or vertically)
3. I immediately see the "LOG: Serial1: Errors: Framing 0, Parity 0, Overrun RX:13 (IF0:0), TX:0, Break 0" error in the log screen repeat about once per second
4. After about a minute or two, the same error message stops repeating. The screen is now showing the incorrect Borland Graphics Interface (BGI) font (CHR file), and the serial port will not respond when a smart card is inserted.
5. Our application is continuing to run (hasn't crashed) because a DoWhile loop continues to run, polling the keyboard.
6. If I exit our application and re-execute, all is back to normal again.

[bdhirsch-code]

I presume that RX:13 is the program (or DOSBox-X) sending out carriage returns through the serial port.

[bdhirsch-code]

While I observe the wrong font and unresponsive serial port behavior when running the program fullscreen, I don't know why the overrun errors are triggered if the window isn't resized.

[bdhirsch-code]

I don't appear to be the only user to have observed this behavior...

https://sourceforge.net/p/dosbox/patches/249/

[bdhirsch-code]

And this: https://www.vogons.org/viewtopic.php?t=36768

[bdhirsch-code]

I found this information about the FTDI chipset (which is what we have to do the serial to USB conversion). It appears as if DOSBox-X (and DOSBox) are trying to send a carriage return (Char13) to the serial port using 38400,n,8,1. I'm not sure why this is happening. Our application correctly uses 38400,n,8,1. The FTDI chipset apparently communicates by default at 38400,n,5,1 and so DOSBox-X is causing an overrun, which eventually corrupts the Borland Graphics font interface and also stops communications with the serial port.

---

Just an FYI for any other RR members else checking this thread in relation to USB-Serial adapters and the different chipsets specs. I wanted to share the following from my personal experiences with figuring out which USB to Serial adapter to use and why one chipset adapter seems to work in some instances and why the other chipset adapter may not.

Uniden 898T the serial to USB that would works is US Converters model XS8801 - uses FTDI chipset

Uniden MR-8100 (if using DOSBox to connect a Windows 10 or higher computer) the serial to USB that would work is a Trendnet model TU-S9 - uses Prolific chipset.

[Explanation] The FTDI chipset adapter uses a protocol of 5 data bits whereas the Prolific chipset adapter uses the more common 8 data bits. (For connecting to the MR-8100 ), this protocol difference means that when DOSBox starts up and tries to open the COM port specified in the DOSBox config file, it will open the port using a protocol setting of "9600, 8, n, 1" and since the FTDI chipset uses "9600, 5, n, 1" DOSBox will not be able to open the COM port.

When trying to use the FTDI chipset adapter with DOSBox you will get the following error on screen (8100 program by SK Consultants) "Serial1: Desired serial mode not supported (9600, 5, n, 1)".

[bdhirsch-code]

What's probably happening is our application within DOSBox-X is causing the FTDI chipset to begin sending carriage returns that aren't being acknowledged, thus filling the chip's buffer and causing a buffer overrun. When this happens the chipset is most likely suspending communications until the buffer is emptied.

[bdhirsch-code]

What I do know is that we don't experience these buffer overruns when running native ROM-DOS. So I have two questions regarding booting ROM-DOS:

1. Will this avoid whatever DOSBox-X is doing that is triggering the serial port overrun?
2. Will DOSBox-X have the drivers to redirect the FTDI Serial-to-USB port (COM4) to COM1 for the DOS application?

The overrun seems connected to resizing the DOSBox-X window, although it even happens within an hour or two of running the application full screen.

[bdhirsch-code]

I will start a new bug report because I believe this problem would happen to any Serial-to-USB adapter used with Windows.