C64 TrueType: About our C64 Fonts


Our TrueType package is the result of a couple years intermittent frustration with the TTF included in DirMaster, which is itself a modified version of an earlier external source. Realizing that we had started with a somewhat troublesome implementation to begin with requiring frequent fixes to shifted or otherwise incorrect glyphs prompted the idea to create a new TrueType representation from scratch. Execution of the idea was started after a survey of other existing C64 TrueType attempts turned up (in our opinion, see below) numerous deficiencies, aside from finding that no effort addressed all the possible use cases that a C64 TrueType font could be deployed for.

Our Goal, or, What Makes a Good C64 TTF?

Our TrueType package aims at addressing the following elements that in our opinion combine to answer the question, "what makes a good C64 TTF?".

  1. Accuracy: There are 304 unique glyphs present in C64 character ROM. Does the TTF actually contain every C64 glyph? Is every glyph accurately outlined? For monospace representations, is every glyph outline positioned to match their bit shapes in character ROM?
  2. Efficiency: Are there more than 304 glyphs (or 307, including ".notdef", ".null", and "CR" as recommended for meeting the TrueType spec) in the TTF? If so, is their inclusion justified? Additional glyphs without a practical purpose should be avoided. There is no need for duplicated glyphs.
  3. Valid: Does the TTF validate against the TrueType specification or other relevant standards? For this purpose we have used validation features in FontForge, FontCreator, and Microsoft's Font Validator to judge other attempts and to refine our own.
  4. User Friendly: Any C64 TTF package meant for "general use" ought to make that use as seamless as possible: does the TTF behave as expected in typical usage scenarios (for example, in Microsoft Word re: smart quotes and horizontal ellipses)? Does the TTF react sensibly to underline or strike-through modes? Is the TTF baseline properly set to cohabit nicely with other fonts in the same document?
  5. Multi-functional: Ideally the TTF(s) provided can be used in different situations. Is there a variable width version for giving documents and web pages a retro but readable appearance? Can the TTF be used in a coder's editor with full ASCII coverage? Can the TTF be used easily by programmers to map from PETSCII encoding or character ROM indices to the proper glyphs?

There are other interesting aspects to the use of a C64 TrueType font that factor in to overall quality and usability. Did you know that modern web browsers will not display a glyph outline for U+007f (ASCII delete)? They'll rarely display a glyph outline for U+00AD (ISO-8859-1 soft hyphen). This is expected behavior! The implication is that trying to map C64 glyphs against a PETSCII encoding based at U+0000 is doomed from the start, at least if you're interested in a TrueType font that is fully usable on a web site. So, even excepting control codes, you'll have to provide some software-based mapping from a PETSCII encoded document in order to display all possible glyphs. Therefore it makes much more sense to use Unicode Private Use Area and provide a simple translation from the PETSCII bytes to Unicode - it might as well be a direct mapping (i.e. $xx -> U+E0xx).

A final bit of C64 character ROM trivia you may not be aware of: the commercial at-sign has a different shape in its reversed form! Take a close look and you'll note that the reverse at-sign contains an odd pixel in the glyph shape. The implication is that relying on software to produce a reversed display of C64 glyphs is not adequate - at minimum you must provide a proper reverse at-sign glyph in your TrueType outlines or address the different pixel in your renderer.

Is a New C64 TrueType Solution Needed?

Before spending the effort in realizing our own TrueType package we searched around this past year for C64 TTF variants. A survey of what we found is below. Problems we cite are not exhaustive but serve as examples, and take this not as an indictment of past efforts that helped push us forward but as a justification for why we are putting our own effort up. Indeed even our own modification of the ubiquitous Devin Cook series has and continues to have its share of issues which is a major motivation for this project.

"PET SCII set 1", "PET SCII set 2" by Henk Hensing
see: http://home.hccnet.nl/h.hensing/c64_nostalgia/letters.html
Two TTFs mapping C64 glyphs to a PETSCII encoding starting at U+0000; the first maps the upper+graphics glyph set and the second maps the lower+upper glyph set.

  • U+0000 / PETSCII is a bad combination (see above re: U+007F / U+00AD)
  • incorrect glyph shapes (e.g. round corner glyphs, U+00A5, U+00A7)
  • missing glyphs (e.g no checkmark, no reverse glyphs)
  • unnecessary duplicate glyphs (e.g. U+0060 = U+0063)

"CBM-64" by Matthew Sew Hoy
see: http://kofler.dot.at/c64/
A TTF mapping C64 glyphs to ASCII & ISO-8859-1.

  • many non-C64 glyphs (almost the entire ISO-8859-1 space)
  • U+0060 (ASCII grave accent) appears instead as the chickenhead logo
  • U+005E (ASCII carat) is still mapped as the C64 up arrow glyph

"Adore64" by ck!
see: http://come.to/freakyfonts
A TTF mapping C64 glyphs to ASCII, including a few additional glyphs to complete the ASCII space (braces, carat, etc)

  • incorrect glyph shapes (e.g. single quote)
  • Font Validator reports multiple checksum errors

"C64 Basic" by Howard Kistler
see: http://www.dreamcodex.com/fonts.php
A TTF mapping C64 glyphs to ASCII

  • incorrect glyph shapes (e.g. exclamation, ampersand, '5')
  • there are no lower case letters; upper case glyphs duplicated

"CBM", "CBMShift" by Christian Vogelgsang
see: contained in VICE and DiskImagery64
Two TTFs mapping C64 glyphs to a PETSCII encoding starting at U+0000; the first maps the upper+graphics glyph set and the second maps the lower+upper glyph set.

  • U+0000 / PETSCII is a bad combination (see above re: U+007F / U+00AD)
  • incorrect glyph shapes (e.g. exclamation, double quotes, ampersand, j)
  • unnecessary duplicate glyphs (e.g U+00A7 = U+00AA = U+00E7 = U+00EA)
  • no reverse glyphs

"Commodore 64" (v5.1 - 6.2.1) by Devin Cook
see: http://simplythebest.net/fonts/fonts/commodore_64.html
A TTF mapping C64 glyphs to ASCII encoding starting at U+F000, including a few additional glyphs to complete the ASCII space (braces, carat, etc); further includes a lot of strange non pixel glyph shapes.

  • incorrect glyph shapes (e.g. exclamation, double quotes, h, i, j)
  • unnecessary duplicate glyphs (e.g. U+F0B4 = U+F094)
  • no reverse glyphs
  • Font Validator reports checksum errors, misoriented contours, etc
  • Font Validator reports pre-program error ("Storage location not written to")

"Commodore 64" (v6.3) by Devin Cook, The Wiz/Style
see: contained in DirMaster v2.1/Style
A TTF mapping C64 glyphs to ASCII encoding starting at U+F000, with extra glyphs (forward slash, tilde, braces, etc)

  • incorrect glyph shapes (e.g. U+F040, at sign)
  • unnecessary duplicate glyphs (e.g. U+F05F = U+F0A4)
  • no reverse glyphs
  • Font Validator reports misoriented contours, etc
  • Font Validator reports pre-program error ("Storage location not written to")

"Commodore 64 Pixelized" by Devin Cook
see: http://www.dafont.com/commodore-64-pixelized.font
A TTF mapping C64 glyphs to ASCII & ISO-8859-1, as well as some U+2xxx

  • many non-C64 glyphs (almost the entire ISO-8859-1 space)
  • incorrect glyph shapes (e.g. exclamation, double quotes, h, i, j)
  • no reverse glyphs
  • Font Validator reports duplicate knot, illegal characters in PS names, etc

"CommodoreServer" by Gregory Alekel
see: http://www.dafont.com/commodoreserver.font
A TTF mapping C64 glyphs to ASCII encoding starting at U+0000 and U+F000; includes an almost complete set of C64 glyphs "custom mapped" to work with author's website. Special note: the only attempt that correctly outlines the non-reverse and reverse at-sign!

  • missing glyphs (e,g, character ROM indices $1df,$1e9)
  • incorrent glyph shapes (e.g. character ROM index $169)
  • incorrent glyph position (e.g. character ROM index $01c)
  • unnecessary duplicate glyphs (e.g. U+0060 = U+0063, U+0062 = U+007d)

There were also a couple references to a TTF made by scener Slartibartfast a few years ago but we're not able to locate a released version.

The existing TrueType attempts are single purpose oriented. A couple are used within specific software applications, one is for use with a specific website - those could be used elsewhere but one also has to conform with the arbitrary mapping used by their authors. Existing TTFs designed to map to ASCII/ISO-8859-1 don't include most other C64 glyphs like box drawing characters. We understand these were designed that way - with only ASCII/ISO-8859-1 in mind - and that's fine, but limited. "Adore64" is an older effort with mostly correct glyphs and would be very close for the sole purpose of a mapping to ASCII, but thats it - it's missing over 200 other glyphs from character ROM so it's hardly complete. "CommodoreServer" is the newest effort we found and makes a leap forward over others with accuracy (at-sign mastery!) and efficiency, but still has errors and a fairly unusual mapping scheme that isn't a "direct" translation to character ROM indices or PETSCII encoding. None of the existing attempts has sought to provide a variable width representation of the C64 glyph shapes. So, yes, we think there is room for another attempt at a broader solution.

How Our C64 TrueType Package is Better

It is accurate, or at least we claim that our glyph outlines are correct and that they reproduce every unique character ROM shape. Tell us if we're wrong!

It is efficient. "C64 Pro Mono" and "C64 User Mono" contain no non-C64 glyphs other than the six additional outlines needed to complete the ASCII set (left & right brace, carat, grave accent, backslash, and tilde). We feel those outlines are justifiable additions in order to provide a complete ASCII mapping that is particularly useful in code editors. "C64 Pro" and "C64 User" contain a few additional glyphs (U+2026, horizontal ellipses and Unicode em space glyphs at U+200x) that we feel are justified by the enhanced usability they provide for proportional use. We've taken care otherwise to make sure there are no duplicated glyph definitions.

It is valid. We've tested our files and the only remaining issues are reasonable and explainable: Font Validator cites TTF files with a GASP version 1 as an error but version 1 is now part of the spec. It also cites intersecting contours - the solution could be adjusting the corners of the glyph outlines by 1 unit to avoid intersections but we assert that such corner point "intersections" are not an issue that needs correction. We conform with other recommended practices: units/em is a power of two, PANOSE values are valid and sensible, and so on.

It is user friendly. Although we've avoided creating more non-C64 glyph outlines than we felt was absolutely necessary for ASCII coverage, we've been very generous with Unicode and CP-1252 mappings. For example, "C64 Pro", "C64 User", and their "Mono" variants contain mappings to ensure that smart quotes and horizontal ellipses behave as one would expect when typing in Microsoft Word, U+0092 (apostrophe) is mapped to the C64 single quote, and so on. A complete table of Unicode mappings we have used can be found here. Underline, strike-through, super and subscripts all behave as one might expect.

It is multi-functional. "C64 Pro" and "C64 User" fill a longtime gap by providing for the first time a faithful representation of the legendary C64 font in a variable pitch form, great for enhancing the readability of text while maintaining retro 8-bit heritage and a more compact presentation. "C64 Pro Mono" and "C64 User Mono" are mappings to ASCII that can be drop in replacements in your favorite assembly text editor for anyone who wants to keep the CBM flavor while cross developing. "C64 Pro" and "C64 Pro Mono" both provide complete ASCII coverage and Unicode/CP-1252 coverage where possible, but still includes all 304 glyphs from character ROM mapped at Unicode Private Use Area, U+EExx and U+EFxx. In fact, with "C64 Pro" you can mix and match variable pitch text with monospaced "8 bits wide" glyphs using just one TTF. "C64 Elite Mono" contains the 304 character ROM glyphs mapped at U+EExx and U+EFxx corresponding to their logical ROM index, but also 4 additional mapping pages that correspond directly with PETSCII encodings for the printable characters in upper+graphics, lower+upper, reverse upper+graphics, and reverse lower+upper modes. These mappings start at U+E0xx, U+E1xx, U+E2xx, and U+E3xx respectively. We've even provided ready-to-use .eot (Embedded OpenType) and .woff (Web Open Font Format) files corresponding to each TrueType font for persons who want to embed our outlines on their website.

We can't currently think of any need not fulfilled by our C64 TrueType package. If you can, let us know!

Coding c64? Check it out...

The Turbo Assembler Homepage

Your best source for Turbo Macro Pro information and the famous Turbo Assembler archive


Codename: Xider

Stay tuned.

Coming soon...