Like his follow-up tweet says, "The second Keen trilogy used a better trick -- just keep panning and redrawing the leading edge, letting the screen wrap around at the 64k aperture edge." So instead of only panning within the width of one tile it pans the width of the whole segment.

jmarsh wrote on 2020-12-18, 11:32:

Like his follow-up tweet says, "The second Keen trilogy used a better trick -- just keep panning and redrawing the leading edge, letting the screen wrap around at the 64k aperture edge." So instead of only panning within the width of one tile it pans the width of the whole segment.

Yes, that is indeed what his tweet says. But the question remains: why does work in CGA? And if the trick is so simple, why wasn't it used before?

If you watch recordings of CGA gameplay it's noticeably less smooth, the scrolling granularity is at least 4 pixels.

There's a description from Romero of how Keen 4-6 work on EGA/VGA, and how it differs from the first trilogy: http://www.vcfed.org/forum/showthread.php?306 … 5724#post225724

CGA has a modifiable start-address register, but not a panning register, and that trick isn't very useful without one. So on CGA it falls back to maintaining the larger scrollable area (IIRC) in system RAM and copying to video RAM as needed. Meaning it just works differently on CGA, and on slower systems there's an obvious speed disadvantage to this method.

Why wasn't it used before? Probably because the later engine debuted on Keen Dreams, which was again done for Softdisk and needed to run on CGA, unlike Keen 1-3.

Thanks, that makes sense. That page refused to come up in a Google search for some reason, possibly because it doesn't mention Carmack at all.

Hi, good evening! ^^
I could be wrong, but I assume Keen engine also uses the dual-page feature of EGA.
That feature also works on VGA/SVGA cards, but apparently only in EGA mode(s).

Here's an example of another DOS program that uses it.:
https://www.youtube.com/watch?v=M2q5r3aNIyA

Jo22 wrote on 2020-12-19, 16:02:

dual-page feature of EGA.

I'm not sure what you're talking about, and I don't really see anything particularly helpful in the video you linked to. What is "dual-page" supposed to mean?

If you're referring to the concept of having (at least) two full screens or "pages" in video memory (i.e. double buffering) and using "page flipping" (displaying one "page" while the other "page" is being redrawn/updated), then yes, all the Keen games (except for the CGA versions) use that concept. Pretty much any 320x200 EGA game I know uses that to avoid flickering when redrawing the screen.

Have we gained any programming technique or intelligence over the past 30 years that could enable the CGA scrolling to be done better now?

or are the hardware limitations already exhaustively explored?

K1n9_Duk3 wrote on 2020-12-19, 21:36:

[..]

If you're referring to [..]

Yes. :)

Shreddoc wrote on 2020-12-19, 21:53:

Have we gained any programming technique or intelligence over the past 30 years that could enable the CGA scrolling to be done better now?

or are the hardware limitations already exhaustively explored?

For Keen I don't think you could get a huge improvement. Maybe a few small tweaks in case they didn't exactly go all the way on optimizing the CGA version (understandably).

You could maybe make it faster using the start address register, but without a panning register that goes in 8-pixel increments, so it's extremely jerky (unless done very fast as in Prohibition). Or you could make it smoother by keeping multiple copies of every graphic asset AND the screen buffer in RAM, and bit-shifting each one so you could scroll in <4 pixel increments, but that will naturally be slower and hog even more memory. I guess CGA Keen is mostly limited by how much it has to draw.

CGA cards generally only had 16k of video memory. That's just tiny bit larger than what is needed to store one single screen of 320x200 pixels at 4 colors (or 640x200 pixels at 2 colors). 4 colors means that you need 2 bits per pixel to store that color information (2² = 4). At 320x200 pixels, that makes 128,000 bits = 16,000 bytes. There's basically no video memory left to do any cool tricks with. Well, technically the CGA cards should have 16,384 bytes of memory, so there should be some free space, but I'm not even sure if CGA cards have any reprogrammable controllers that would enable tricks like the ones Carmack used for the Keen games (the most important being a variable start address, a variable "virtual screen width" and a pixel panning feature).

If I understand VileR's post correctly, CGA does at least have a variable start address, but the card would also need to "wrap around" at the end of the video memory to provide a decent method of doing smooth scrolling without having to redraw the whole screen. I'm not sure if CGA cards can do that, since not even all EGA-compatible cards handle that "wrap-around" correctly (that's why Keen 4-6 and Keen Dreams have that so-called "SVGA compatibility mode"). The strange odd/even line split in the memory layout of the 320x200 pixel CGA graphics mode might also be a problem when it comes to wrap-around:

bytes 0 to 7999: lines 0, 2, 4 ... 198
bytes 8000 to 8191: unused
bytes 8192 to 16191: lines 1, 3, 5 ... 199
bytes 16192 to 16383: unused

Without pixel panning and a variable virtual screen width, the smoothest thing you can do in CGA would be pure vertical scrolling. This could be done efficiently in hardware (assuming the video memory wraps around correctly), by simply drawing the new lines for the top or the bottom of the screen as they "scroll" into view and then updating the start address to move the entire screen up or down by 1 or 2 lines. Or you could just implement it by having a bigger screen buffer in main memory and copying the appropriate section of that block into video memory for each frame, like the CGA Keens do it.

Personally, I never had a PC with a CGA or EGA card. Every PC I ever used had at least an (S)VGA card in it, so there's really no way for me to test the true capabilites of a CGA card.

K1n9_Duk3 wrote on 2020-12-19, 23:42:

CGA cards generally only had 16k of video memory. [..]

Hi, now that you mention this, I *vaguely* remember that the address space was 32KB in theory (at least), but due to a flaw in the
addressing mechanism (incomplete decoding) of the IBM CGA, 16KB was all that could be effectively used.
If memory serves, some of the addresses would repeat at some point.
If that wasn't the case, CGA could do things like 640x200 in 4 colours.
Depending on how we look at it (was the restriction to 16KB intended or a bug ?),
this circumstance would make, say, Plantronics, PC1512 or the Olivetti/AT&T graphics fixed or "full" versions of CGA. 😉

Anyway, it has been a while since I tinkered with CGA.
Since I have got no real computer at hand at the moment,
I can't really look up the details. 😅

Jo22 wrote on 2020-12-20, 04:09:

Hi, now that you mention this, I *vaguely* remember that the address space was 32KB in theory (at least), but due to a flaw in t […]
Show full quote

K1n9_Duk3 wrote on 2020-12-19, 23:42:

CGA cards generally only had 16k of video memory. [..]

Hi, now that you mention this, I *vaguely* remember that the address space was 32KB in theory (at least), but due to a flaw in the
addressing mechanism (incomplete decoding) of the IBM CGA, 16KB was all that could be effectively used.
[...]
Depending on how we look at it (was the restriction to 16KB intended or a bug ?),

There is no flaw that reduched the amount of usable memory on the CGA card. While you are right that the reserved address space for color video solutions is 32KB (as is the reserved address space for monochrome video solutions), the original cards provided by IBM did not make use of the whole address space. Instead, they just both had as much memory as required for a single page in their highest-resolution display mode. For the MDA, it meant 80 x 25 characters, 2 bytes each = 2000 characters, 2 bytes each = 4000 bytes required, so that card shipped with 4KB of RAM. For the CGA, it meant 640x200 pixels, 1 bit ech = 128000 bits = 16000 bytes, so that card shipped with 16KB of RAM. The reason for this minimal amount of memory is just keeping the price low, as memory was very expensive those days.

On the other hand, there might be a perceived flaw on the CGA card that it claimed the whole 32KB memory space reserved for color video, even though it only had 16KB to offer, preventing a different plug-in card to use the address space between BC00 and C000 for purposes unrelated to the CGA card. As the complete B800-C000 area was reserved for color video cards, and outside of the area intended for ROM extensions, it wouldn't make much sense to reclaim that area to different cards, though, so the flaw (if the CGA actually doesn't decode A14, which might very well be true) doesn't have any practical consequence.

Don't confuse the design of the IBM PC, where the video RAM is located on the graphics card, and the card is thus limited to the amount of memory that's soldered on the card with the designs of contemporary 8-bit home computers that shared memory between the processor and the graphics system, so the CGA card had no way of using more than 16KB of memory except if more memory was soldered to that card. The advantage of the IBM system with dedicated graphics RAM is that high-bandwidth modes like the 80x25 text mode of the CGA cards (it needs a memory throughput of 3.5MB/s) didn't impact processor performance. This is especially important because the 8088 is starved on memory performance in many real-world applications even without any wait states being added by concurrent access (and the measurable performance difference you can obtain by slowing down RAM refresh proves this point). The CGA card at 3.5MB/s maxed out what its memory access system could handle, and that's why you get snow if you access video RAM during text display in 80-column mode: The processor in that case steals video memory access cycles from the graphics card, so the graphics card works with the data the processor read/wrote instead of the data it would have needed for correct display.

Shreddoc wrote on 2020-12-19, 21:53:

Have we gained any programming technique or intelligence over the past 30 years that could enable the CGA scrolling to be done better now?

or are the hardware limitations already exhaustively explored?

If by "better" you mean more than 4 colors, there's VileR's Commander Keen 4 Composite CGA Patch and MagiDuck.