What Is Text Mode? How ANSI and ASCII Art Files Work in Text Mode

Text mode is a display mode where the screen is treated as a grid of fixed-size character cells rather than a canvas of individually addressable pixels. Each cell holds one character plus attributes such as foreground color, background color, and sometimes bold or blink. ANSI art, ASCII art, and the BBS "artscene" all grew up inside this model, which is why their files store character codes and color commands instead of pixel data. To view them faithfully you need a renderer that understands the original code page and font; to share them as images you convert them, for example with Ansilove, which turns ANSI and related artscene formats into PNG.

Why text mode produced a distinct kind of art

In text mode the smallest unit you can draw is a character cell. You cannot place a dot halfway between two cells, and you cannot use an arbitrary color — you pick from the palette the hardware or terminal offers. That constraint shaped the art:

• Resolution is measured in columns and rows, not pixels. A classic DOS text screen is 80 columns by 25 rows; a BBS might use 80x24 or other sizes.
• Color comes from attributes, not from per-pixel values. A cell's foreground and background are chosen from a limited set (16 colors in the classic PC palette).
• Shading and gradients are faked by choosing characters with different densities (░, ▒, ▓, █) and by mixing foreground/background colors.

This is why text-mode art looks blocky and character-driven, and why the same file can look different depending on the font and palette used to render it.

How text-mode art encodes what you see

A text-mode art file is essentially a stream of instructions to a terminal. Three things are being encoded:

1. Characters. Each glyph is a code point in a code page. The IBM PC world standardized on CP437, which includes box-drawing characters, block elements, and shading characters that ANSI art relies on heavily. If a viewer interprets the bytes as a different code page, those characters turn into the wrong symbols.

2. Colors and attributes. ANSI escape sequences (the "ANSI" in ANSI art) set foreground and background colors and toggle attributes. A sequence like an escape code followed by parameters tells the terminal "from here, draw in this color."

3. Cursor position. Escape sequences also move the cursor to a specific row and column, so the file can paint non-sequential parts of the screen. This is what separates ANSI art from plain ASCII art: ANSI art uses positioning and color, while ASCII art is typically just characters in reading order.

Formats you will encounter

Fonts matter as much as the file. Ansilove's release history shows ongoing work here: Spleen 8x16 was added with full CP437 support, and later synced to Spleen 2.0.0 (which swapped the arrows at positions 1A and 1B). A font change at that level can visibly alter how a piece renders.

Viewing text-mode art vs. converting it to an image

There are two different goals, and they need different tools.

Viewing in a terminal. A modern terminal is not a DOS text-mode screen. It can usually display the characters, but it may not honor the exact palette, the original font, or the original screen dimensions. You get something recognizable, not necessarily pixel-faithful.

Converting to PNG. This is what Ansilove is built for: "a set of tools to convert ANSi and artscene related file formats into PNG images." Conversion freezes the art into an image using a chosen font and palette, so it looks the same everywhere. That is the practical route when you want to archive, post, or compare pieces.

A typical conversion flow looks like this:

1. Get the file in its original format (.ans, XBin, PCBoard, etc.).
2. Run the converter on it, specifying output and any font/palette options you need.
3. Check the result against how the piece is "supposed" to look — especially if it uses a non-default font or a code page other than CP437.
4. Adjust the font or rendering options if characters or colors come out wrong.

The expected result is a PNG that reproduces the character grid, colors, and positioning of the original. The common failure is a mismatch between the font/code page the art was made for and the one the converter used.

Common problems when rendering text-mode art

• Wrong code page. Bytes meant as CP437 render as the wrong glyphs. Box-drawing and shading characters are the first to break.
• Missing or wrong font. If the art was made for a specific font (Amiga Topaz, Spleen 8x16, a custom XBin font), the default font will not match. XBin can carry its own font data, which is why it needs special handling.
• SAUCE metadata ignored. SAUCE records information about a piece, including font. Ansilove's changelog notes a fix for selecting the "Amiga Topaz 1" font from SAUCE metadata — meaning if the metadata is not read, the wrong font is used.
• Palette differences. The same color index can map to different RGB values depending on the renderer, so colors shift.
• Screen size assumptions. Art drawn for one column/row count can wrap or clip if the renderer assumes another.

Practical takeaways

• Text mode = character cells + attributes, not pixels. That single fact explains almost everything about how ANSI and ASCII art look and behave.
• ANSI art ≠ ASCII art. ANSI art uses color and cursor positioning; ASCII art is plain characters.
• The file alone is not the whole picture. Code page and font are part of the artwork, which is why formats like XBin embed fonts and why SAUCE metadata matters.
• To preserve or share a piece, convert it to PNG with a tool that respects the original font and code page, and verify the output rather than assuming the default settings are correct.

If your goal is just to read the art, a terminal viewer is fine. If your goal is fidelity — archiving, posting, or comparing against the original — convert to an image and check the font and code page first.