Some Disassembly Required

Special Hardware for Plain old Text.

Last time, I got my VGA circuit displaying an actual image. An off-color, artifact laden, not quite in the right place image, but an image nonetheless. Good enough to push the concept further, if nothing else.

Text mode is exactly what it sounds like: a special mode for displaying text. If you’re wondering why this would be useful, consider that one character of text fits inside one byte. Even the simplest bitmap of a character takes more than one byte.

For a small computer where both memory and CPU cycles are a scarce resource, cutting the work to display text is a big performance booster. It also relaxes design constraints on various bits of hardware; text mode typically allows more parallelism than a bitmap can.

While I consider this particular development a success, let’s just say I have more than a few bugs to work out later on.

---

The Big List

• Time Base Generation- VGA requires a rock-stable timing chain to work. It therefore must be done first.
• Framebuffer and Bitmap Graphics– Without some kind of memory, you can’t display anything useful.
• Text Mode- A specialized graphics mode that allows for more compact representation of tiled graphics, i.e. text.
• Control and Interface- Adding the final bits of glue logic to hook into an external system.

---

Text Mode

Graphics tend to be extremely demanding on memory. Each pixel on the screen is mapped to one or more bits, which have to be accessed and displayed in very short order. As I previously mentioned, a paltry 200x150px display still needs about 4KiB of memory when each pixel is just one bit. For comparison the first home computers had 4KiB of RAM. That RAM had to cover everything, and even a tiny bitmapped display ate a huge chunk of that precious, precious RAM.

Text mode was invented to move resources away from fast RAM. Instead of an all-points-addressable bitmap, the screen is broken into small tiles (e.g. 8x8px) which fit one character. Using the 200×150 example, this reduces the effective resolution to just 25×18.75.

Each one of those tiles has a byte pointing to a particular character bitmap. These are held in a separate memory area, typically a cheap ROM, so it doesn’t compete with the main RAM. Round off the extraneous 0.75 to get a total memory footprint of 450 bytes.

---

Hardware Design

Hardware-wise text mode acts as an indexed array. First the character byte is fetched from the main RAM. This byte is used to index into the character ROM. At this point the pixel and line addresses decode the character like an ordinary bitmap.

Originally I wanted to double-dip, using the same memory for the character string and the bitmap ROM. Unfortunately between the relative complexity, a few week’s hiatus from this particular project, and increasing pressure to strip this breadboard, I decided not to pursue this idea. It’s definitely possible; several home computers allowed this.

Instead I chose to logically separate the character ROM from the input bytes. Lacking a great option to generate those input bytes, I wired in the VGA timing signals. I also had to add an extra signal to load the shift register. Using gates is unnecessary considering the horizontal GAL could easily do this. Gates don’t require me to re-flash the GAL, which won me over.

Also, I never really use those HC20’s for anything.

Clearly this is all sort of hacked together. I’ll have to think about how to add in some RAM next time around.

---

Testing Text Mode

Unlike a bitmap, text mode is very easy to test. All I have to do is replace the ROM contents with a character set, plug it in, watch it go.

This is a very basic ASCII font I’m working on. Due to the incompatible layout of the screen, the displayed results won’t look exactly like this. How does it look?

Not good. The shift register is clearly working, though. Perhaps it’s another file formatting issue. This time I’ll hand code the a test sentence into the ROM.

Hmm. Clearly I’m missing something. Fiddling with the address lines didn’t improve things much.

Time for a more drastic rewiring. I cut the address lines down to four each for lines and bytes. Doing this completely eliminates any addressing issues- I hope.

You know what? Close enough. I got legible text.

Something I can’t show here is that the center of the lowercase ‘l’, the left half of the exclamation mark, the top-center pixel of the ‘W’, and the center of the extra ‘H’ on the left are “pouring” down the screen. I’m not too sure what’s going on there. I suspect a floating line; it only seems to appear when holding the breadboard base plate. I did do a lot of hasty, unplanned rewiring.

Also not explained is the extra row of blank characters between the printed ones. This one is almost certainly just me not quite getting my ROM just right.

---

Future Developments

Text mode greatly reduces the burden on the system. There’s a reason it was part of early computers. For the small 8-bit systems I’m designing this for, it’s pretty crucial.

While it’s called text mode, there’s no reason why non-text characters can’t be displayed. Anything that can be broken into a small set of tiles can be represented. Most 2D games consoles had tiled graphics to improve performance.

Typically a text-mode display allows the foreground and background color to be set. I omitted this for simplicity, but putting it in only requires one or two registers and an inverter.

Putting the character set into ROM saves some RAM, but limits you to one character set. Using RAM for character storage allows for custom characters to be swapped in as needed. Hardware pointers can be used to pull the character set from any memory location, which has even more advantages.

It is entirely possible to mix text mode and bitmap mode. This requires the graphics controller to swap modes mid-frame. Outside the scope of the project as it stands, but I have some fun ideas for later on.

---

Text mode was a mandatory feature for my prototype. It’s marginally more complicated than I anticipated. While I can’t quite get my display working correctly, it would appear that all the trouble relates to the ROM. I have to do some serious rewiring to add RAM in there somewhere, so I’m not too bothered.

Next time I add that RAM, as well as the means to talk to it. At that point I consider this project complete, and suitable for more permanent development.