29

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?

7
  • 6
    There were programs for the Apple II (using hires aka bitmap, not "tiles" aka text-mode chars) which used proportional fonts (and also non-standard characters, e.g. Hiragana/Katakana). Not sure if that matches your criteria, though I'd count the Apple II as "8-bit computer"
    – dirkt
    Sep 14 '18 at 10:49
  • 5
    @JeremyP It doesn't realy matter, as long as it's about text having the same colour over more than a single letter ... like a line or such :))
    – Raffzahn
    Sep 14 '18 at 12:09
  • 2
    I don't think this is quite what you are looking for (because your main text refers to displays, though the actual question does not), but I am 99% certain that some versions of WordStar - including I am pretty sure the 8-bit versions - used proportional fonts when printing on certain printers. Sep 14 '18 at 15:40
  • 4
    @manassehkatz - that's an interesting point. There was a selectable proportional printing mode in Epson-compatible printers, and any software that had an appropriate font metric table would be able to make use of that to produce proportional printed output.
    – Jules
    Sep 15 '18 at 17:09
  • 2
    The games Room Ten (Pete Cooke/CRL) and Dark Star (Simon Brattel/Design Design) had particularly nice proportional fonts
    – scruss
    Sep 16 '18 at 1:19
28

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 enter image description here

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

10
  • Oh, right, totally forgot about that.
    – Raffzahn
    Sep 14 '18 at 12:35
  • Now, while it may be considered as out-of-the-box for software, it's still a third party development and add on to existing machines - like the CPC series, which may have been the most widespread users of GSX.
    – Raffzahn
    Sep 14 '18 at 13:51
  • @Raffzahn GSX was shipped with the Amstrad machines - just like CP/M. The ROMs in the Amstrads, nearly everything Amstrad made in terms of computers, was third party development - So what? I'm afraid I miss a point in your comment.
    – tofro
    Sep 14 '18 at 13:56
  • 1
    I used one for maybe all of ten minutes, as a child back in the '80s so excuse my ignorance: per Wikipedia, LocoScript — the bundled PCW word processor — also appears to support proportional fonts? And that's really the piece of software that entire machine is designed for. (EDIT: re "out of the box" and assuming it's in reference to Raffzahn's answer, the PCW being from 1985 might exclude it from the "(back then)" clause, being eight years after the Apple II; I have no strong opinion)
    – Tommy
    Sep 14 '18 at 15:13
  • 2
    @Tommy LocoScript did "support" proportional fonts - But not on the screen, only on the printer. The screen displayed proportional fonts just like fixed-size fonts and you could only see the final print result - when printing. Even if the original question doesn't explicitly mention screen display rather than print, I'd guess that would not answer the question.
    – tofro
    Sep 14 '18 at 15:17
17

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.

7
  • 2
    This answers the question, which sought any example, so I don't fancy writing my own answer. But here's a ZX Spectrum example (from about 3:28): youtube.com/watch?v=wFo-KRnMtFw&feature=share ; in general every significant 8-bit computer got some attempt at DTP software, and that almost invariably has a go at proportional fonts. I'll bet GEOS and GSX even have the feature built in.
    – Tommy
    Sep 14 '18 at 11:55
  • 2
    @StephenKitt Before GEOS on the C64 theree where Multiscribe and Mousedesk on the Apple II.
    – Raffzahn
    Sep 14 '18 at 12:10
  • 2
    @Raffzahn indeed, GEOS came to mind because it was rather well-known back then (at least in my circles — I only encountered Apple IIs in the late 80s), not because it was the first. Sep 14 '18 at 12:14
  • 7
    I'm confused why color imposes any requirement. In most situations where text is used, there is no need for color to vary by character or even by word. Surely it matters if you want to do that, but it's a specialty use, not an assumed requirement. Sep 14 '18 at 16:43
  • 1
    @StephenKitt Yes, It was. I tried it on the Apple II, and it was quite interesting - except, at that time I had already an Atari ST with GEM (plus a PC to compile stuff I sold to PC users with way to much available money :))
    – Raffzahn
    Sep 14 '18 at 21:47
14

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 retail box

GEOS desktop v2.0 running on the Commodore 64

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.)

A sample of proportional fonts as rendered by a GEOS application

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:

11

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

Skool Daze screenshot
(source: worldofspectrum.org)

5
  • 2
    Please sir, I cannot tell a lie, user3570736 answered this question.
    – Tommy
    Sep 14 '18 at 17:06
  • 3
    There was also a utility library published as a type-in in Your Spectrum issue 20 (live.worldofspectrum.org/infoseek/magazines/your-spectrum/20#48) which you could use to easily add the facility to your own programs. I used it several times ... very handy.
    – Jules
    Sep 14 '18 at 18:31
  • 1
    Disassembly of routine from Skool Daze that does it: 1, 2, data table with character widths
    – kolen
    Sep 20 '18 at 23:13
  • 1
    Skool Daze came out in 1984. The first games I remember having proportional fonts were apparently other games that came out in 83/84 by Crystal Computing or Design Design, notably in the high-score tables. I'm having trouble verifying which game used it first though. Here it is in Dark Star: youtu.be/G960XjUE9uM?t=1 Jun 10 at 4:55
  • This is the only pic I can find of the proportional font in 1983's Halls of the Things high-score table: photos.1highscore.com/… - The in-game fonts were not proportional. Jun 10 at 5:09
11

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.

8
  • 1
    It’d be helpful to edit for accuracy now that another user has posted a counterexample.
    – Davislor
    Sep 14 '18 at 17:47
  • 1
    The accepted answer, about the Amstrad.
    – Davislor
    Sep 14 '18 at 21:05
  • 5
    The Amstrad had “out-of-the-box” support for proportional fonts in its OS. You even left a comment saying it had slipped your mind. So I was wondering if you were planning to edit your earlier answer, which still says that no 8-bit computer supported proportional fonts out of the box.
    – Davislor
    Sep 14 '18 at 21:14
  • 1
    GSX was never part of the DD1 package - The CPC464 with only 64k of memory and CP/M 2.2 wouldn't have been capable of running it. It was, however, part of the CPC6128 and PCW packages that supported CP/M 3.0 and, thus, RSX extensions like GSX - "out-of-the-box" and in no way aftermarket.
    – tofro
    Sep 17 '18 at 17:33
  • 1
    +1 for HRCG. Everybody at my school loved it. Ah, memories!
    – cjs
    Jul 30 '19 at 11:41
3

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.

3

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.

1

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.

4
  • but they look so nice! And if you thought doing proportional Latin text was hard, give a thought to the Arabic ROM MSX developers who had to deal with numbers that run from left-to-right, but letters that run from right-to-left ...
    – scruss
    Oct 24 at 13:51
  • Nice for some things, not for others. That's why we have the 'code' tag for showing code in posts! Oct 24 at 18:59
  • Code doesn't need to be in monospace, it's a fairly recent convention. ACM/IEEE papers used to typeset Algol code with variable spacing and proper fonts, even substituting typographic symbols. Coding in proportional fonts might help get away from "1 char = 1 byte" thinking
    – scruss
    Oct 25 at 12:25
  • @scruss Sorry, but the coding I do (in assembler) does have to be monospace in order to be readable. This also applies to the most popular programming language in the world, Python, and other languages that use spaces for indentation. Furthermore, "reading numbers and punctuation marks is a lot easier when they're evenly spaced." creativebloq.com/features/the-best-monospace-fonts-for-coding Why would I want to 'get away from "1 char = 1 byte"' thinking"? Oct 25 at 20:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.