Click above to get retro games delivered to your door ever month!

  Much of the information we've provided in this chapter, particularly
  information on internal mapping of display memory, is meant to help you
  write video information directly into the display memory. But remember
  that direct programming has inherent risks, and you'll find it both safer
  and easier to use the highest available means to control the video
  display. Lower-level means, particularly direct manipulation, can be very
  disruptive.

  More important, it's not always easy to write "well-behaved" programs that
  access video hardware directly. There are several reasons for this. One is
  simply that there is a lot of different video hardware to worry about.
  Apart from the five IBM video subsystems we've discussed here, many
  non-IBM video adapters and built-in video subsystems exist in non-IBM
  computers. If you write a program that programs a particular IBM video
  subsystem directly, the program probably won't be portable to a different
  IBM subsystem or to non-IBM hardware.

  We've already mentioned another reason to avoid direct video hardware
  programming: Multitasking or windowing operating systems must work
  overtime to accommodate programs that directly access video hardware. Of
  course, the designers of newer PC and PS/2 operating environments are well
  aware of the need for good video performance, so modern operating systems
  generally offer faster and more flexible video output services than do
  older systems, such as DOS. Direct hardware programming offers little
  advantage if the operating system's video I/O services are fast enough.

  Also, direct video hardware control can get you into trouble with the ROM
  BIOS if you aren't careful. The ROM BIOS keeps track of the video hardware
  status in a set of variables in the data area in segment 40H. (See Chapter
  3 for a list of ROM BIOS video status variables.) If you program the
  video hardware directly, you must be careful to update the ROM BIOS status
  variables accordingly.

  For example, the simple routine we presented earlier for resetting the CGA
  enable-blink bit bypasses a ROM BIOS status variable. To update the
  enable-blink bit without causing the ROM BIOS to lose track of the video
  hardware state, you would update the ROM BIOS status variable at
  0040:0065H:

  10 DEF SEG = &HB800             ' (same as before)
  20 POKE 0,ASC("A")
  30 POKE 1,&H97
  40 DEF SEG = &H0040             ' address the BIOS data area
  50 POKE &H0065,(PEEK(&H0065) AND NOT &H20) ' update BIOS status variable
  60 OUT &H3D8,PEEK(&H0065)       ' update hardware register

  If you program carefully, controlling the video hardware directly can be
  very rewarding. You can maximize the speed of your video output as well as
  take full advantage of hardware capabilities such as smooth,
  pixel-by-pixel panning or hardware-generated interrupts. But when you
  write such a program, keep the pitfalls in mind.