I think softcat talks of hardware scrolling using virtual frame buffer, similar to how ega and vga planar modes can - basically moving the viewport through the larger canvas with preallocated pixels.

cga cannot do the above.
maybe some guru nerds can hack in some partial scrolling in a specific cga graphics mode by messing around with the crtc registers, but thats about it.

mkarcher wrote on 2025-09-28, 05:43:

I don't think so. While the CGA has an 8 bit wide memory bus, the logical organization is still a 16-bit system, fetching a 16-bit word per "character interval". Bits 1..12 are generated from the character counter in the 6845, bit 13 is generated by the character counter in text mode and by the scanline counter in graphics mode. Bit 0 generation is fixed (low on the first fetch, high on the second fetch). In Text mode, this 16-bit system will handle one character and one attribute byte per "character", in 4-color graphics mode, it will handle 8 pixels per "character" and in 2-color graphics mode, it will handle 16 pixels per "character". Increasing the start address will cause the image to scroll horizontally by a whole character, which is 16 pixels in 640x200 mode.

Thank you for your reply!
That is, if we make the video adapter's internal structure 32-bit, we can implement a 640x200, 16-color graphics mode on the same 6845 controller. That's 80 "characters" per line, 32 bits each. A character is 8 pixels wide, with 4 bits for the color code.

pshipkov wrote on 2025-09-28, 05:53:

I think softcat talks of hardware scrolling using virtual frame buffer, similar to how ega and vga planar modes can - basically moving the viewport through the larger canvas with preallocated pixels.

cga cannot do the above.
maybe some guru nerds can hack in some partial scrolling in a specific cga graphics mode by messing around with the crtc registers, but thats about it.

Yes, I'm aware that scrolling on CGA is only possible by changing the start address. And there's no way to achieve smooth horizontal scrolling.

SoftCat wrote on 2025-09-28, 21:56:

That is, if we make the video adapter's internal structure 32-bit, we can implement a 640x200, 16-color graphics mode on the same 6845 controller. That's 80 "characters" per line, 32 bits each. A character is 8 pixels wide, with 4 bits for the color code.

That's basically EGA mode 0Eh. Even if EGA uses an IBM designed proprietary 6845-inspired CRTC instead of the more basic original chip, the idea is the same.

SoftCat wrote on 2025-09-28, 22:06:

pshipkov wrote on 2025-09-28, 05:53:

I think softcat talks of hardware scrolling using virtual frame buffer, similar to how ega and vga planar modes can - basically moving the viewport through the larger canvas with preallocated pixels.

cga cannot do the above.
maybe some guru nerds can hack in some partial scrolling in a specific cga graphics mode by messing around with the crtc registers, but thats about it.

Yes, I'm aware that scrolling on CGA is only possible by changing the start address. And there's no way to achieve smooth horizontal scrolling.

Depending on the monitor, you can do finer horizontal scrolling by varying the width of the HSYNC pulse, because many monitors from that era don't actually sync on the rising edge of the pulse.
That is a trick from the Amstrad CPC playbook.

Benedikt wrote on 2025-09-30, 18:53:

Depending on the monitor, you can do finer horizontal scrolling by varying the width of the HSYNC pulse, because many monitors from that era don't actually sync on the rising edge of the pulse.
That is a trick from the Amstrad CPC playbook.

I vaguely remember that the CGA generates part of the horizontal timing in dedicated hardware instead of using the CRTC signals, and the width of the actual sync pulse might not be variable using the sync pulse width register of the CRTC. If this Amstrad trick doesn't work with a CGA card, it might not be a monitor issue, but possibly a CGA design issue as well.

mkarcher wrote on 2025-09-29, 18:53:

That's basically EGA mode 0Eh. Even if EGA uses an IBM designed proprietary 6845-inspired CRTC instead of the more basic original chip, the idea is the same.

Yes, I understand about the EGA 0Eh mode. All EGA modes are possible on the 6845. The video RAM layout will just be different.

Benedikt wrote on 2025-09-30, 18:53:

Depending on the monitor, you can do finer horizontal scrolling by varying the width of the HSYNC pulse, because many monitors from that era don't actually sync on the rising edge of the pulse.
That is a trick from the Amstrad CPC playbook.

The HSYNC pulse width is a multiple of the symbol clock width, which is 16 pixels in 640x200 graphics mode.

SoftCat wrote on 2025-09-30, 22:04:

Benedikt wrote on 2025-09-30, 18:53:

Depending on the monitor, you can do finer horizontal scrolling by varying the width of the HSYNC pulse, because many monitors from that era don't actually sync on the rising edge of the pulse.
That is a trick from the Amstrad CPC playbook.

The HSYNC pulse width is a multiple of the symbol clock width, which is 16 pixels in 640x200 graphics mode.

If I understand it correctly, that CPC trick relies on analog effects in the monitor circuitry that delay the detection of the HSYNC pulse by a tiny fraction of its width.
I will have to try some day whether a similar effect can be observed with a typical CGA setup.
In any case, exploiting such an effect would be much harder than on a CPC that was always bundled with a known type of monitor.

Benedikt wrote on 2025-10-01, 17:35:

If I understand it correctly, that CPC trick relies on analog effects in the monitor circuitry that delay the detection of the HSYNC pulse by a tiny fraction of its width.
I will have to try some day whether a similar effect can be observed with a typical CGA setup.
In any case, exploiting such an effect would be much harder than on a CPC that was always bundled with a known type of monitor.

From what I recall of the CPC techniques (e.g. in Logon System's Amstrad CPC CRTC Compendium), the smooth(er) horizontal scrolling tricks involve two kinds of things:

1. The behavior of the CPC's gate array, which generates the actual sync signals sent to the monitor, in response to those it receives from the CRTC - it truncates or delays the end of its output HSYNC when faced with specific durations of the input (CRTC) HSYNC. The CGA circuitry also sends an output HSYNC which is delayed with respect to the CRTC's, but as far as I know both the delay and the output duration are fixed. (There could always be some exploitable details which I'm unaware of, but they're unlikely to match the behavior of the CPC gate array.)
    
2. 'Just-in-time' interventions, or synchronizing with the CRTC's counters and changing the width and/or position of the HSYNC signal at very specific points of the blanking/retrace period. This is made feasible by the design of the CPC, where the character clock is an exact multiple of the CPU frequency, and I/O cycles are aligned (via wait states) to always fall at a specific point within the character period. Neither of those things is true with the PC and CGA.

If there are any effects relying on analog monitor behavior, they'd be much trickier... the actual retrace doesn't necessarily happen at a predictable time with respect to the incoming sync signal, since it depends on the H-HOLD oscillators (which lock on to that signal to time the deflection of the beam). There's some tolerance involved, and I'm not sure whether the timing is 100% predictable even for a specific monitor.

For smooth horizontal scrolling on CGA, here's a solution. Set the graphics mode to 512x128 2-color or 256x128 4-color with R9 = 1. This will create two video pages. Scroll as follows:
1) Change the contents of the inactive page;
2) Switch pages;
3) Make the same changes on the other page.

Yep, double-buffering (with a smaller viewport) is definitely possible. This was done e.g. in 8088MPH for the vectorballs section.