You've heard of Text Mode. You've seen that "Windows Command Prompt" thingee that persists even in 64-bit versions of the operating system, and you are completely mystified. If you want to know what the heck Text Mode is, read on.
The original Color Graphics Adaptor (CGA) hardware let you manipulate characters and colors as they applied to unit cells. Each unit cell allowed you to set exactly one character and one "color attribute." The character is one of a specific brand of Extended ASCII, known as IBM Code Page 437. All 256 values of the character-code byte represent a unique character. The "color attribute" is broken down into three pieces: a foreground color (bits 0-3), a background color (bits 4-6), and a blink flag (bit 7). You can set the foreground (the actual character color) to one of 16 colors. You can set the background (the non-character portion of the cell) to one of 8 colors. Finally, the blink flag determines whether the character portion of the cell stays visible versus periodically blinks off (shows the background color instead). It's really that simple. Just take a pattern and repeat it however many times as can be supported over the whole page. It lets you paint a page with a lot of character/color possibilities. More importantly, it lets you paint a page on the cheap: even 80-column display requires no more than 80x25x2 bytes of memory per page, which works out to 4,000 bytes total. In the early days of computing, transferring graphics to the screen on the cheap was very important. For example, if you wanted to print the word "Hello" on the screen, it would only require 5x2 = 10 bytes transferred (1 character and 1 color attribute for each of the letters of "Hello"). With relatively slow CPUs, you could simplify basic text operations significantly. But you still need to organize the cells. Hence, video modes.
The long and short of text mode on classic IBM PC is this: you have two fundamental switches for how you can display text on the screen. Color or Monochrome, and 40-column or 80-column. These decisions are manifested as...
Basically, the user settings at the beginning of ZZT (and of Kroz, for that matter) determine which mode is picked. Mode 2 is picked for monochrome, and Mode 3 is picked for color. Super ZZT is a different beast entirely. Modes 2 and 3 are used for the menus, but the game actually uses Modes 0 and 1, since the game requires 40-column view. This doesn't actually describe all the different possible text modes. One very-overlooked mode is Mode 7. No, not that Mode 7, SNES junkies. It's exclusive to the Monochrome Display Adaptor, or MDA. Mode 7 not only allows variations on monochrome intensity, but also formatting specs like underlined text, blinking text, and reverse foreground/background. Various user interfaces in business applications of the 1970s and 1980s would find such displays useful, because you didn't need more than glorified text to represent something spartan and to-the-point. Sometimes, these stoic, monochrome displays would be given a green tint. Because, green. ZZT does not use Mode 7. ZZT keeps things simple.
CGA and MDA had other modes that let you modify individual pixels. But because memory was at such a premium in the old days, the colors available to these modes were quite sparse. Colors were limited to only four in the so-called graphics modes, which is a far cry from the 16 that can be shown in text modes. The name of the game was this: the higher the resolution, the worse your color choices were. The original ZZT was designed to be compatible with every display adaptor. If you wanted 16 colors, it had to be text mode. But the moment you try varying the pixels themselves, and not just the character cells? There go your color options. But there is another dimension to this. Most of the BIOS services and I/O ports available for IBM hardware provided only bare-bones functionality. No fancy blitting DMA services. No sprite control. No blast processing. Transferring pixels on your own with that early hardware? Slow. Transferring whole characters at once on your own? Fast. I should note that there were always possibilities of unchaining the hardware, accessing undocumented video modes, and "simulating" extra colors via stippling. But these techniques were not widely known or used, and they carried compatibility risks with all the "clone" hardware in existence.
Text mode isn't used much anymore because modern user interfaces have proven themselves consistently better for most tasks. Nearly every computer screen that you see nowadays makes use of some sort of "graphics mode" with individual pixels that can be modified. Most user interfaces also support a general "windowing" philosophy, with interfaces and sub-interfaces that are movable and resizable. However, text mode is elegant and straightforward. Things are easy to harmonize when text characters are locked to unit cells and color options are limited. With text mode, many of the things you constantly have to worry about when deciding how to render graphics, such as resolution, color depth, time to render, effect of shape overlaying, etc., simply disappear altogether. You are left with only a few options as to what you can display. The result is that the output becomes focused, pertinent, measurable, and concise. By virtue of these facts, ZZT is also focused, pertinent, measurable, and concise. Admit it. You like text mode.
I love text mode. I miss when interfaces were all text-based by default. The loss of the "file" menu in modern interface design disappoints me, although I appreciate that the "hamburger menu" and "gear menu" are convenient new tools for developing for small screens.
To enter a comment, log in using the ZAPTCHA.
