I appreciate the effort @kcgen , but frankly, it was better before. Before this change only a single scanline was glitching, now it's an entire row, so it's worse. See attached video (just remove the second .zip extension).

If there's always gonna be glitching with the current DOSBox-side text output method, it's best to restrict the artifacts to a single scanline.

glitch.avi.zip

Cool text demos, but as we were saying, proper emulated DOS programs are different, those are expected to work without artifacts anyway.

Before this change only a single scanline was glitching, now it's an entire row, so it's worse.

This was deliberate because the smallest "logical unit" in text modes is a text cell, so switching from per-line to per-row chunks (or "atomic row changes") means we'll only see row-level changes, and never slice through the middle of a text character (or strange effects like that).

But yeah - if we're just trying to shrink this region of change (as the frame is updated); then pixel-lines is the way to go.

Cool text demos, but as we were saying, proper emulated DOS programs are different

I wasn't booted into real MS-DOS; so the text demo was making INT10 text calls into DOSBox's emulated DOS routines, and from there the drawn text is render to the VGA side where this per-line chunked behavior is seen.

(In the videos, you will also see there's no tearing or sub-row slicing; and the demo is using a real text mode).

But regardless, I'd rather the per-line updates anyway 😅

I wasn't booted into real MS-DOS; so the text demo was making INT10 text calls into DOSBox's emulated DOS routines, and from there the drawn text is render to the VGA side where this per-line chunked behavior is seen.

(In the videos, you will also see there's no tearing or sub-row slicing; and the demo is using a real text mode).

Ok, but do we get any slicing/tearing artifacts with these text demos prior to this change, when rendering by scanline? I think not, we established that the probable cause for text tearing at the DOS prompt is that our emulated DOS prompt implementation does "weird things" and doesn't quite go through the normal "emulation pathways" like regular DOS programs do, unlike our DOS commands.

Can you post the names of these demos, links to them, or the demos themselves? Then I can also test if there's any tearing when rendering by line as before.

But regardless, I'd rather the per-line updates anyway 😅

Let's take a step back 😄 I brought this up because the single scanline glitches annoyed me in our DOS prompt only. I never encountered these glitches on any other text programs, just with our DOS prompt.

So, if running actual DOS programs that use text mode never glitch anyway with per scanline rendering (to be tested if you send links to the demos), then this change only magnifies the problem with the DOS prompt. So yeah, then it's worse because it's more noticeable now and more distracting 😄 Am I missing some benefits of the per-row rendering here?

Before I close it out, I did a deeper dive into what's happening as the frame level.

Notice that DIR isn't affected by this issue despite both it and LSjust printing text using WriteOut(char*), so what's going on?

DIR, stepping per-millisecond

1. DIR step 1

   

2. After tapping Enter, DIR prints all of its content within the same millisecond moment in time:

   

   There are no intermediate steps.

LS, stepping per-millisecond

Now let's see how LS behaves:

1. LS step 1, just before pressing Enter

   

2. Ater pressing Enter, LS prints an initial new line causing the entire frame to scroll up one row:

   

3. There's still more time spent here.. notice the cursor at the bottom is just starting to be drawn in. We're now several milliseconds in:

   

4. Finally LS prints all its content, causing the frame to scroll up even more rows:

   

So the big difference is that LS has three visible drawing events, all of which can drive frame updates. These seems to appear (nearly) instantly, but it's really doing things in proper sequence: scrolling content up and then re-drawing in the new scrolled stated.

Can you post the names of these demos, links to them, or the demos themselves? Then I can also test if there's any tearing when rendering by line as before.

Yup - that one is textro

So, if running actual DOS programs that use text mode never glitch anyway with per scanline rendering (to be tested if you send links to the demos), then this change only magnifies the problem with the DOS prompt.

I'm still digging; what I've concluded so far is that the our DOSBox-side commands (like LS and DIR) are able to use WriteOut(char*), which is a DOSBox API that interfaces with the real text frame content.

Basically, we can call WriteOut("hello world") and instantly inject text right into the DOS console; and this is very fast and independent of CPU cycle count.

Compare that with DOS-side programs - if they want to print text, they use INT10H interrupt, which DOSBox emulates.

Both text pathways ultimately terminate in the same BIOS text frame handling code.

Am I missing some benefits of the per-row rendering here?

I don't think so!

(more to come.. :-)

Couple of ideas:

• Don't instantly inject text into the DOS console, just go through the normal channels as other DOS programs (i.e., BIOS interrupts, or write characters to the raw video memory the same way actual programs do)
• Just render a single "slice" (part) for text modes. Or would that break any weird text mode demos? I don't think so, but would need testing.

The first option seems better to me.

Compare that with DOS-side programs - if they want to print text, they use INT10H interrupt, which DOSBox emulates.

Just for clarification @kcgen: many programs write character codes to the text mode video memory area directly (starts at B8000h on VGA). In the DOS days, I just maintained my own 80x25 / 80x50 buffer and then flipped the whole thing to the vmem on vsync in one go on VGA. Much faster than the BIOS interrupts and you have more freedom manipulating your character buffer directly.

I'm sure the text mode demo does the exact same thing, so it's quite impossible to get the same glitchy behaviour with it.