Proportional fonts on 8-bit computers

Question

Many 8-bit computers had video systems that provided tiles, and when these were available, they were the obvious ways to display text.

However, some 8-bit computers such as the ZX Spectrum and Amstrad CPC, only had bitmap displays. If you are using a bitmap anyway, the possibility arises of using a proportional font. Sure, it would be a bit slower to render text, but for many purposes, surely worth it. Yet all the 8-bit programs I can find, still used a fixed width font.

Were there any 8-bit programs (other than font demos) that used a proportional font?

Answer 1

Digital Research produced as one of their early attempts into graphical desktops (on their way to GEM) a basic portable graphics library - GSX. GSX did actually support proportional fonts, both in print and on-screen, and was included with the CP/M support in Amstrad machines running CP/M Plus. GSX was supported by two of DR's own applications, DR Draw and DR Graph that were available for the range of enhanced Amstrad machines (CPC6128, PCW), although at a pretty high price.

GSX later evolved into GEM, DR's MS Windows counterpart on CP/M 86 and Atari STs

So, this is definitively "out-of-the-box" support for proportional fonts, both in applications and a system-wide extension.

Technically, GSX is an RSX (Resident System eXtension, the DRI, not the Amstrad Basic term) and will thus only work on CP/M 3.0

Answer 2

Just the first (of many) example of using proportional fonts on Commodore64: https://youtu.be/k2NRlsopoOU?t=441

You couldn't really use a proportional font on the Spectrum because the colour attributes were one background and one foreground for each 8x8 square. That meant that, practically speaking, each letter had to be by itself in an 8x8 cell.

With the reasonable limit of every word of its own color, it is quite possible though. Just have the space between words wide enough to absorb attributes boundary or place color change in those spaces that do absorb the boundary. The previous example also shows that.

Note: Commodore 64 also has the bitmap mode very close to the one ZX Spectrum has. It is exactly that mode shown in the link above.

Answer 3

Back in 1986, a company called Berkeley Softworks released a GUI desktop environment called GEOS for the Commodore 64. It was later ported to the Commodore 128, the Commodore Plus/4, and Apple II.

GEOS was obviously inspired by the classic Mac OS desktop. It implements all the basic elements one would expect from such environment, such as a pointer-driven UI with icons, windows, pull-down menus, a shared clipboard, and – yes – proportional fonts of many sizes, families and styles.

It even had things like system-wide printer drivers, support for memory expansion cartridges, and input drivers for mice. (Mice were not common peripherals for the 8-bit home computers, but they were available, and if you purchased one, you could use the system pretty much just like a Mac or an Amiga. The hardware was, of course, more limited, but the basic feel to the desktop/GUI user experience was similar.)

The font engine in GEOS is bitmap-based. Fonts come in many sizes but all sizes are pre-drawn/rendered bitmaps. Font editors and additional font packs were also available. More about the technical details here:

https://www.lyonlabs.org/commodore/onrequest/geos/geos-fonts.html

GEOS came bundled with geoWrite (a word processing application) and geoPaint (a paint program), and a number of utility programs, all of which used the font engine provided by the OS.

Several additional applications were available as separate purchases, such as geoCalc (a spreadsheet application), or geoPublish (a desktop publishing application, i.e. a full-fledged page layout application for print design!)

You can find a lot more information about GEOS on these sites:

• https://www.commodore.ca/history/company/turks_geos.htm

• https://www.lyonlabs.org/commodore/onrequest/geos/index.html

Answer 4

The games Skool Daze and Back To Skool used proportional fonts for text on the ZX Spectrum.

_{(source: worldofspectrum.org)}

Answer 5

No 8-bit computer (back then) supported proportional fonts out of the box, but there where some programs on almost every bitmap-capable 8 bit computer. I this would include the Spectrum.

For the Apple II, support was added by Apple rather early. Already the Apple DOS Toolkit included a utility called HRCG or High Resolution Character Generator, which moved character drawing onto high-res bitmaps and into software (*1). While, AFAIR, it originally only supported fixed-width fonts, soon other programs used this to display at least part of their output in proportional-width.

When the Apple II Mouse was introduced, first for the IIc and later the basic II, it came with MousePaint, a MacPaint clone for the Apple II using proportional text on screen and in menus (*2). The availability of a mouse also triggered a lot of other programs trying to do what the Mac showed on an Apple II. Most notably maybe MultiScribe for the II (*3) and MouseDesk.

Another example for add-on software enabling proportional fonts would be DR's GSX, the graphic extension (*4) for CP/M, which was also adapted to several Z80 machines including the Amstrad CPC and Commodore 128. It was also the core component for GEM on the Atari ST and PC.

And then there was GEOS. It enabled C64 programs to use proportional text and exchangeable fonts. Soon also ported to the Apple II.

So, bottom line: No, it hasn't been used out of the box, but later tools added this capability to 8-bit computers.

---

*1 – It was slow (compared to text mode) and it ate up memory, but it was also AWESOME.

*2 – Not to be confused with MouseText, a character set change for the Apple IIc and Enhanced IIe introducing some graphic elements into the character set, allowing character-based software to display a simplified GUI. Funnily enough, soon programs used HRCG with Mousetext to draw the same elements using the graphics characters, but also add other graphic elements.

*3 – Which got a second life as BeagleWrite after their company was bought by Apple and integrated into Claris.

*4 - It was much more than just an average graphics library. Beside being made to the GKS standard, it also includes features for multiprogramming and windowing.

Answer 6

Even if one is using a bitmap mode, a routine to draw tile-based graphics that are aligned with byte boundaries can be much faster than one which isn't thus restricted. Suppose one wants to draw an 8-pixel wide character at a location that is displaced by two pixels from an aligned position. Code to do that would end up having to look something like:

loop:
    lda (src),y
    asl
    rol temp
    asl
    rol temp
    ora (dest,x)
    sta (dest,x)
    inc dest
    lda temp
    and #3
    ora (dest,x)
    sta (dest,x)
    clc
    lda dest
    adc #rowSpacing
    sta dest
    dey
    bmi done
    bcc loop
    inc dest+1
    bcs loop
  done:

By contrast, when drawing an aligned tile, the code would look like:

loop:
    lda (src),y
    sta (dest,x)
    dey
    bmi done
    lda dest
    adc #rowSpacing
    sta dest
    bcc loop
    inc dest+1
    bcs loop

Bearing in mind that a separate version of the shifting code would be needed for each of the eight different amounts by which bytes would need to be shifted, it should be clear that bit shifting graphics will be much more time consuming than showing bit-aligned times.

Answer 7

Other replies already give examples which use proportional text, so I won't add to them.

However, I want to challenge the claim that "[s]ure, it would be a bit slower to render text, but for many purposes, surely worth it." To do it right (rather than cheating in a demo) is more than "a bit slower".

Look at how text rendering is done with 8x8 fonts on an 8x8 grid: compute (or possibly have already cached) the address of the top of the character cell at the cursor, loop over the character glyph and write it to the framebuffer, adding the appropriate stride to the pointers. The stride is typically 1 or 256 which is very cheap to add. A reasonable implementation would probably unroll that loop into 20-ish instructions which complete in a few tens of microseconds.

For proportional fonts, much more work needs to be done. One has to shift the character glyph to align with the pixel-granularity cursor, read the framebuffer, apply a mask, merge the glyph, and write it back again. There is the further complication that glyph straddles multiple bytes so the process needs repeating. Some of this can be precomputed, but it's quite obviously a lot more work because it's juggling a lot more data and touching the framebuffer at least twice and often four times more.

I've just written a throwaway BASIC program to use the BBC Micro's VDU5 mode which writes text in its graphics mode (that is, pixel positioning with full AND/OR/XOR effects, as opposed to just blatting into character cells). It took about 5 seconds to fill the screen, versus the usual fraction of a second. Acorn's MOS graphics stuff isn't exactly the fastest, but this order of magnitude difference is indicative.

One reason for such bad performance is that the shifting is quite expensive since 8 bit CPUs—and even the 68000—do not have a barrel shifter and so has to shift one bit position at a time which is slow. The Amiga used its blitter for text rendering since the blitter can do multi-source reading, shifting, masking, and writing back as fast as memory bandwidth will allow. Without the blitter, it would be as slow as the original Macintosh which had to do it in software; and would appear much slower because the Amiga has a higher-resolution display.

Answer 8

Sure, it would be a bit slower to render text, but for many purposes, surely worth it. Yet all the 8-bit programs I can find, still used a fixed width font.

For some purposes it would be worth it, but many others it wouldn't. Ever seen ASCII art rendered in a proportional font? Using a fixed width font makes it much easier to get even spacing and line text up vertically.

It also means that text can be printed over other text knowing that it will completely cover it (if it has the same number of characters). With a proportional font you have to clear the area first and then position the cursor where you want the text to appear, rather than just printing over the top.

Calculating the position of centered text or how much text will fit in an area is also much more complicated. Depending on the kerning rules you may need to go through the motions of rendering it just to determine the width in pixels, then decide what to do if it is too long or too short.

If you are moving a cursor through text it jumps different distances depending on the character width, and its own width may also change, which might make it hard to see on narrow characters (especially on a TV or large dot-pitch color monitor which were commonly used with 8 bit home computers). A block cursor is more visible, but may go over closely kerned adjacent characters, which looks messy. When moving the cursor vertically it jumps sideways, which also looks messy.

Porting programs from a fixed width machine to one with proportional fonts can be particularly problematic. Most 8 bit computers had a version of BASIC that worked with fixed width fonts, and many programs that users might want to type in expected it. Even on more a powerful machine like the Commodore Amiga, having to deal with all the complications of a proportional font can be a pain, especially if the user can freely choose different system fonts which the application has to honor.

So one big reason that you might not have found any 8-bit programs with proportional fonts is that most of the time they were not worth it, due to both the performance hit and extra programming effort required.