You don't know how many times I re/designed 8x8, 8-9x14, and 8-9x16 fonts as bitmap constants in Pascal, C, and assembly in high school. Writing programs to extract fonts from CGA/MCGA/EGA/VGA-compatible BIOSes was fun. If you were feeling sporty, you could write a keyboard-activated TSR to the same in another program. It would pause the current program, transfer control to yours (or chain the call to the saved CS:IP of the original interrupt vector at [0000:n*4]), and then you would ordinarily POP DS, POPA/AD, STI, IRET.
And the old Norton Utilities / FreeBSD gpm 512 character drawing trick where 2 code pages were simultaneously visible by sacrificing 1 bit of foreground color. There is an artifact in using it as a graphic cursor because the right most pixel and the one before it are duplicated because the underlying horizontal resolution is 720 px (not 640 as before) and 80 characters wide. Since most text glyphs don't occupy the right-most pixel, there's no harm in cheating and reusing fonts from 640x400 (not 480) pixels. Interestingly, most graphics cards could draw text somewhat properly in graphics modes with int 10h (video bios) or 21h (DOS services) calls, but it was very slow. It was faster to bitblt pre-rendered raster fonts in graphics modes.
Slightly off-topic. I had a Dragon 32 as a kid (less successful rival to the Spectrum) and one of its quirks was that it couldn't display text in "graphics mode".
A big chunk of a lot of listings that you typed in from magazines were "drawing strings" to define all the main a-z chars just to give you a graphics font.
I had a Dragon too, loved it despite its limitations. There was a great type in program in Dragon User that allowed you to switch into one of the graphics modes and type and run BASIC programs in there. Most impressive. (I remember 12 year old me bending my fathers ear clean off waxing lyrical on a long car journey about how clever the program was and why didn't they do this in the first place and maybe the Dragon could have competed with the Spectrum... not being computer minded he must have thought I was bananas, but he humoured me!)
And for the other infamous limitation (no lower case characters in text mode) late in its life Dragon User had another program that set up a semigraphics mode which defined new characters made up from the the individual horizontal scanlines of the standard character set and was able to cobble together serviceable lower-case characters. It then patched the OS to use this mode with the new characters, to all purposes creating an upper and lower case mode.
I was disappointed that my Sinclair ZX81 lacked capabilities to customize fonts. (Only 1k of RAM and hardwired character generator, including 16 2x2 block "graphics".)
So, just in case you're like me still mentally stuck in the 1980s: buyer beware; user defined fonts only applies to those fancy new Sinclair ZX Spectrum models. :-)
The Dragon 32 is interesting in that it's pretty much the same as a TRS-80, but (mostly) PAL instead of NTSC, a centronics parallel port, and a different ROM. To the point that a significant amount of TRS-80 software will run on the Dragon.
The "non-Color Computer" TRS-80 models started off with Level I basic, which was based on the non-Microsoft TinyBASIC.
However even they moved on to a Microsoft BASIC variant: Level II and Level III BASIC were based of Microsofts BASIC-80, but modified to incorporate commands from Level I Basic....
But the TRS-80 Color Computer/CoCo, which is the machine Dragon 32 is actually nearly identical to, used Color BASIC (and later variants), which was based on Microsoft BASIC-69 (69 referring to the 6809 CPU; there was also a BASIC-68 for the 6800), so you're right the TRS-80 variant that was most similar to the Dragon 32 had the same BASIC as the Dragon 32...
The good old days of (almost total lack of) compatibility...
Same with the Acorn Atom. But you could sort of get it working anyway by way of 'drawing' the characters on the bitmap screen (probably a very similar solution).
These are fantastic. For example, this one https://damieng.com/typography/zx-origins/zx-venice/ reminds me of "Lords of Midnight"[1]. Which was an incredible game which pioneered procedural generation so it just seemed vastly bigger than anything else I had played up to then. I never managed to keep my speccy alive for long enough in a single sitting to actually finish the game until one day the cassette just gave up entirely and I couldn't play it any more.
That bitmap fonts are not covered by copyright is something I have often seen stated, and the above reference seems to back it up; since bitmap fonts are not rendered from curves and vectors, there is no underlying putative “software” to claim copyright on.
A bitmap font could still theoretically be covered by trademark or possibly a design pattern, but (IIUC) those are things that have to be applied for, unlike copyright which normally covers a work automatically.
The Wikipedia page suggests that typefaces aren't copyrightable, but individual bitmapped fonts actually may be - which is slightly odd, but I guess the font is the concrete embodiment of the typeface.
Amazing work, props to Damien! As others have mentioned, these fonts gain a whole new audience with the microprocessor community for use with small displays.
This throws me back. I spend hours on my C64 doing pretty much the same, inspired by the text scrollers of various demos. Even printed them out on this continuous paper with the holes on the sides. Getting a readable @-sign while doing a bold font was always a challenge.
It's funny how similar most of these look to those I did. Some styles were pretty much universal back then.
With the recent wget vs. curl discussions fresh in my mind, how would I download all these .zip files with wget? Curl would of course require some sort of parsing, but I would think that wget's mirror option could somehow download just the .zip files.
The mirror option depends on a hierarchy where it can exclude parents. Since the actual downloads are on a different domain, it seems this won't work. A hacky script to do it:
#!/bin/bash
for page in $(curl -s https://damieng.com/sitemap.xml | perl -ne 's/<loc>/\n<loc>/g;while ($_ =~ s#<loc>(https://damieng.com/typography/zx-origins/[^\<]+)</loc>##) {print $1."\n"}'); do
echo "Page is [$page]"
download=$(curl -sL "$page" | perl -ne 'm#(download\.damieng\.com/fonts/zx-origins/[^"]*)#g && print "https://$1"')
echo "Download is [$download]"
wget -qN "$download"
done
Doesn't the -A zip cause it to skip the subpages? That's what I'm saying...the filter is keeping you from traversing main page -> sub page -> zip file.
No if you check the output, or even enable -d, you'll see that it goes through sub-pages. It downloads all the index files into a tmp file so it can parse them for more sub-pages, then deletes them after because they don't match the pattern.
It even goes as far as to download download.damieng.com/fonts/conversions/Micropack.zip, proving that it does traverse domains and sub-dirs, but nothing under download.damieng.com/fonts/zx-origins.
It's really strange, I'm thinking it has something to do with all the .zip archives being linked without a protocol (//download.damieng.com), might be a bug but I'd be shocked if no one had encountered it before.
The process involves me creating a raw 768 byte "ch8" file for the Spectrum then running it through a bash script that creates the .psf and .bdf using psf2tools.
The next bash script uses a bunch of third-party tools and my own PixelWorld open-source .NET tool to generate all the other formats and disk images and then packages them up into a zip and uploads it to S3.
Just a little side-note you might find interesting:
In the home computer era, when 8x8 bitmap fonts had their heyday, displays often had rectangular pixels. So, while the characters look square now, they often did not back then.
Most of the 8-bit machines had quite square pixels (Spectrum, Commodore 64) but machines with multiple resolutions often had modes that doubled the horizontal res (C128, PCW, BBC Mode 3) giving rectangular pixels and by the time the 16-bits hit (Amiga, Atari ST) these modes were commonly the default and square pixels were relegated to "low-res" modes which were used less often.
The Commodore 64 (I still have mine) has a ratio of about 1.3 on NTSC, so not quite your average web-font (which are around 2 or higher), but hardly square.
Cool, thanks! It took longer than I care to admit. They're redrawn on the fly and it also means the 2x and 3x options can render it without upscaling blur.
I thought about setting up my camera and pointing it at my Princeton 15" multisync CRT and scripting a live screenshot of every font but that seemed... overkill.
I'll keep that page in mind, when I build my next Arduino LED-matrix display project.