13

According to https://en.wikipedia.org/wiki/Adaptive_tile_refresh:

CGA (the previous generation of PC graphics hardware) lacks features for scrolling in hardware

so PC games started featuring hardware scrolling only with EGA.

However, CGA uses a video controller chip (Motorola 6845) that could also be found in BBC Micro and Amstrad CPC. And, if we look at certain BBC Micro games, e.g. Uridium, those games feature quite advanced hardware scrolling by using a programming technique known as rupture.

So the question goes - what exactly prevented CGA era games on the PC from using a similar trick to achieve hardware-accelerated scrolling?

10
  • Maybe it didn't work on NTSC. Also it might work on CGA adapters from one manufacturer but not another.
    – Alan B
    Jul 16 at 9:24
  • 3
    CGA typically output to a monitor, so NTSC probably wasn't the issue. I suspect it's more because programming the CRTC on other machines was really hard, and required very accurate timing, which would be harder on multiple target machines possibly running at different frequencies. Jul 16 at 9:43
  • 1
    That, and the small amount of memory available on CGA. The 8088mph demo uses vertical CGA scrolling, but only works on a 4.77MHz 8088 and only targets the original IBM PC (albeit with a sound card). Some games did assume accurate timing, or at least timing as seen on 4.77MHz 8088s, and don’t run well on anything else... Jul 16 at 9:51
  • @StephenKitt The 8088mph creators say that they were using a timer to sync with the vertical retrace in the vertical scroll scene, so CPU clock might be less of an issue than we probably think. Still I doubt that the timer resolution would be sufficient for reprogramming CRTC within a single scanline. As for the memory though, BBC Micro only had around 20K of video RAM; did the additional 4K make a noticeable difference compared to CGA's 16 KB?
    – DmytroL
    Jul 16 at 10:25
  • 3
    @DmytroL as far as memory is concerned, CGA’s 16K provide only 384 spare bytes (320×200 in four colours uses 32000 bytes), i.e. two lines of pixels; 4K in that context provides quite a bit more room (28 lines exactly with the added 384 spare bytes). Jul 16 at 11:11
14

According to https://en.wikipedia.org/wiki/Adaptive_tile_refresh:

CGA (the previous generation of PC graphics hardware) lacks features for scrolling in hardware

so PC games started featuring hardware scrolling only with EGA.

That paragraph is wrong, or better, it lacks a much needed refinement:

CGA did not provide horizontal hardware scrolling. Continue reading makes it obvious that the author had horizontal scrolling in mind.

However, CGA uses a video controller chip (Motorola 6845) [...],

While the 6845 does not provide a per scan line scroll feature, it does allow to set the screen start address. By advancing this for the length a text (or graphics) line content got scrolled by either line height. With text this is not smooth (per pixel) while for graphics there is no difference.

those games feature quite advanced hardware scrolling by using a programming technique known as rupture.

Well, Rupture is again a different beast, as it is about splitting the screen horizontal in different regions picked from different parts of the graphics buffer.

So the question goes - what exactly prevented CGA era games on the PC from using a similar trick to achieve hardware-accelerated scrolling?

While this is in theory as well possible with an IBM-PC and works fine for 'simple' scrolling of a single region, practical realization of rupture like handling is a 'bit' more difficult as the timing of CPU and graphics are neither synchronised nor does CGA provide easy hooks (like interrupts) to create synchronization. Though, it isn't impossible, so go ahead and impress us :))

4
  • If vertical scrolling was available, does that mean that there's CGA pinball games?
    – knol
    Jul 16 at 12:52
  • 2
    There isn't much to scroll up or down by modifying the screen start address when the visible screen uses all but 300-something bytes of the video memory available. (In fact, you could "hardware-scroll" by just a handful of scanlines in 4-colour-mode)
    – tofro
    Jul 16 at 13:29
  • @tofro True for highest resolution graphics mode. In 100x160 more than 8 K are free and in text mode a lot more is possible. Then again, but isn't that the same for all 6845 based designs, as the chip provides only 14 address lines total?
    – Raffzahn
    Jul 16 at 15:51
  • @Raffzahn In 160x100 (16 colors), you have a 80x100 text mode with 8K characters (all set to 222 decimal, a horizontally split character) and 8K attribute bytes, which also fill the video RAM nearly completely. There is no real 160x100 graphics mode that doesn't need character bytes. Jul 16 at 19:28
14

I did it for a game, but it was a mess.

It was a port of a 2-way fine scroller... by making it a 1-way scroller, we trashed the game pretty badly... it was definitely not faithful to the original. This alone was a disappointment to me and to the client.

Horizontal fine scrolling was simply not on the menu.

It was not achievable. We could horizontal scroll on byte borders, but only by excessive blitting (block transfer). There was too much RAM to move and not enough time. Remember, the IBM PC's RAM throughput was only 1.19 MHz - the same as the Atari 2600 VCS - but with a lot more resolution and thus RAM to move.

I even wrote code that wrote code of a very long sequence of "Load exact address/Store exact address" operations, so we could avoid the CPU overhead of looping and indexing. It just wasn't gonna happen.

Anyway, vertical fine scrolling...

The problem is, you weren't fine scrolling so much as saying which scan line to start rendering the display.

We couldn't very well have the top line jumping up and down, so we told the CGA card to add extra lines, so the rendered display ran past the physical top of the monitor bezel and on past the bottom. It was very hokey, and it didn't overlap fully on every monitor bezel. And of course it was completely unsupported.

Use documented interfaces, or else

But the thing that probably killed the method dead was what has always been drummed into your head by IBM: "don't bit-bang the hardware (much). Only use supported and documented methods of interacting with the display, because we're going to change the undocumented stuff". And of course, that's exactly what they did.

So even if we had made it to market, we would have had trouble with third party CGA cards, EGA and everything that came after. We would've had to buy back a lot of games.

3
  • 2
    Sequence of load/store? Interesting. I wonder why you haven't used any of the string instructions? After all, they delegate the full bandwidth to moving data, essentially allowing to go near 500 KiB/s transfer rate. the bare move might end up close to 1/60th of a second, so still leaving room for other manipulation, wouldn't it? (I did a lot of screen handling using them).
    – Raffzahn
    Jul 16 at 22:46
  • 2
    @Raffzahn I recall being dissatisfied with its performance... we tried everything lol and I came out of the school of 6502 "ride the raster" cycle-counting, so we certainly knew how long each option was taking. Regardless, there just wasn't time to copy the whole raster and the other stuff that needed to happen - the vertical scrolling is itself complex. Jul 16 at 22:56
  • 2
    Sounds strange to me, as any other method (like unrolling with absolute address) eats up 75% bandwidth for instruction fetch, while string operations take in the single % range. Especially if only doing vertical scrolling. Been there, done that, albeit a 25 Hz video in 720x350. so I know they are (almost always) the solution, I'm even more curious why it didn't work out. The 8088MPH demo and its creator discovering string operations is a good documented example as well.
    – Raffzahn
    Jul 17 at 10:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.