superfury wrote on 2025-06-24, 21:37:

So you push the horizontal retrace past the horizontal total? Won't that just increase the scanline counter too soon? Or is that exactly the target? Thus increasing the scanline counter without retrace, increasing it twice each scanline to skip the unwanted character row?
So basically let it trigger retrace start, moving total down to create a short period, retrace out of bounds to prevent triggering it... But active display will occur for one character clock, unless I'm missing something?

Yes, that all sounds correct. The active display does indeed occur for one character clock, but it's hidden in the part of the overscan area that's behind the monitor's bezel. It can be seen if the monitor's horizontal size control is set too small, though.

reenigne wrote on 2025-06-16, 13:04:

4148 per frame. Or 4266 with DRAM refresh disabled (115.2 hdots per iteration and 112 hdots per iteration respectively). The answer is the same no matter what the video mode is (the CGA wait states are not dependent on mode).

And how many bytes can be transferred in 1 second to video RAM on EGA and VGA? If you just transfer bytes, without bothering with the color mask and bit mask.

SoftCat wrote on 2025-06-24, 21:56:

And how many bytes can be transferred in 1 second to video RAM on EGA and VGA? If you just transfer bytes, without bothering with the color mask and bit mask.

That's more difficult to answer. What machine, and what EGA or VGA card? I can test my IBM VGA card in my 5160 if you like, but I'm fairly sure that it can saturate the bus (or very nearly) so about 356kB/s with REP MOVSW. But most EGA and VGA cards are in faster machines.

reenigne wrote on 2025-06-25, 11:35:

That's more difficult to answer. What machine, and what EGA or VGA card? I can test my IBM VGA card in my 5160 if you like, but I'm fairly sure that it can saturate the bus (or very nearly) so about 356kB/s with REP MOVSW. But most EGA and VGA cards are in faster machines.

Thank you for the information and your desire to help!
I think there is no need to check. It is more or less clear to me that the entire screen cannot be updated in one frame.

I have another question. What if R9 = 2 or 3 is set in CGA graphics mode? Am I correct in understanding that with R9 = 2, lines with numbers 3*k and 3*k + 2 will be the same? And with R9 = 3, lines with numbers 4*k and 4*k + 2 will be the same, as well as lines with numbers 4*k + 1 and 4*k + 3?

SoftCat wrote on 2025-06-25, 19:02:

I have another question. What if R9 = 2 or 3 is set in CGA graphics mode? Am I correct in understanding that with R9 = 2, lines with numbers 3*k and 3*k + 2 will be the same? And with R9 = 3, lines with numbers 4*k and 4*k + 2 will be the same, as well as lines with numbers 4*k + 1 and 4*k + 3?

Yes, that's correct. The RA0 (lowest bit of scanline number within row) is used to select between the 0xb8000-0xb9fff and 0xba000-0xbbfff pages in graphics modes. The RA1 and RA2 bits are only used in text mode, and the RA3 and RA4 bits are disconnected completely.

reenigne wrote on 2025-06-25, 23:27:

Yes, that's correct. The RA0 (lowest bit of scanline number within row) is used to select between the 0xb8000-0xb9fff and 0xba000-0xbbfff pages in graphics modes. The RA1 and RA2 bits are only used in text mode, and the RA3 and RA4 bits are disconnected completely.

Got it, thanks.
So if you set R9 = 15 in text mode, the characters will be duplicated vertically?

SoftCat wrote on 2025-06-26, 19:41:

So if you set R9 = 15 in text mode, the characters will be duplicated vertically?

They will!

reenigne wrote on 2025-06-26, 19:44:

They will!

Thank you for your reply!
This site stopped opening for me, so I didn't reply for a long time. Now I'm logged in via VPN.