Typography in 8 bits: System fonts
May 14, 2014 4:04 PM Subscribe
Or maybe you'd just like to browse several hundred Commodore 64 fonts, mostly made for specific video games
posted by jepler at 4:39 PM on May 14, 2014 [5 favorites]
posted by jepler at 4:39 PM on May 14, 2014 [5 favorites]
And who could forget the nigh-illegible 80-column font for Commodore 64, which had 3x7-pixel letters in a 4x8 grid. This wasn't really a text mode, but was simply bit-blitted into the "high resolution" 320x200 graphics mode screen.
posted by jepler at 4:48 PM on May 14, 2014 [3 favorites]
posted by jepler at 4:48 PM on May 14, 2014 [3 favorites]
Oh my god I can download the Amstrad CPC font as TrueType from this.
posted by Jimbob at 4:51 PM on May 14, 2014 [2 favorites]
posted by Jimbob at 4:51 PM on May 14, 2014 [2 favorites]
And all brought to life with your dot matrix printer!
posted by Alexandra Kitty at 4:52 PM on May 14, 2014
posted by Alexandra Kitty at 4:52 PM on May 14, 2014
And who could forget the nigh-illegible 80-column font for Commodore 64, which had 3x7-pixel letters in a 4x8 grid.
O my god, this looks like when you put a pixel correct tiny font like that on a HiDPI mobile phone screen, especially smaller or really high resolution ones like the <5in 1080p stuff.
The emulators don't really do it justice either, as it would be farted out onto a blurry CRT in the C64s case.
posted by emptythought at 4:53 PM on May 14, 2014 [1 favorite]
O my god, this looks like when you put a pixel correct tiny font like that on a HiDPI mobile phone screen, especially smaller or really high resolution ones like the <5in 1080p stuff.
The emulators don't really do it justice either, as it would be farted out onto a blurry CRT in the C64s case.
posted by emptythought at 4:53 PM on May 14, 2014 [1 favorite]
Oh. Em. Gee.
Confess, thank you so very much for this.
posted by PROD_TPSL at 4:54 PM on May 14, 2014
Confess, thank you so very much for this.
posted by PROD_TPSL at 4:54 PM on May 14, 2014
I made a few Commodore 64 fonts in my time as well. It was a weird system to do graphics for. Let me explain. (What follows is entirely old Commodore hacking memories. You might want to move on to a more interesting comment.)
The Commodore 64's memory architecture was rather strange. It contained a full bank of 64K of RAM, but because the processor in it was a MOS 6510 (a slightly improved version of the venerable MOS 6502 used in most 8-bit home computers), which had only a 64K total addressing space, different bits of it were more or less accessible at different times. Particularly, for you were only able to use about 38K of it for BASIC programs.
Most of the rest of the RAM was "hidden beneath" the memory space of other chips, particularly the BASIC and KERNAL ROMs and the addressing space for the I/O registers. Other than the 4K utility area at $C000 (49152), that RAM might as well have not been there unless you were willing to bank switch out the ROMs, and if you did that you were leaving BASIC-land entirely, since by removing them from the memory space you were also separating the CPU from the code needed for normal operation. Generally, if you did that, you were devoting your program exclusively to machine code. I had no good assembler so I was pretty much stuck, mostly, to doing BASIC programs with hand-assembled machine code to optimize slow bits.
But just because the RAM was hidden from reading by the CPU didn't mean it was completely useless. For the system's VIC-II graphics chip also had the ability to read RAM, and it wasn't wired to see the BASIC and KERNAL ROMs at all. It mostly had a full view of the RAM, with the exception of a Character Generator ROM, hidden away by yet another bank switching scheme. The Character Generator was mapped to two places in the addressing space, and at startup the C64 points the VIC-II to the lower of those two images, which is how it displayed character graphics in normal operation.
The VIC-II operated by dividing the 64K memory space into four banks of 16K each, and everything it referenced for generating the display had to be in that bank. (Except for color memory at 53248, which was a special array of 4-bit memory locations inside the VIC-II itself.) Particularly, this included the section of memory used for the screen (starting at $0400/1024 in normal operation) and the chargen image, at $2000/8192. (All these numbers are from memory -- I don't absolutely promise they're right, but I'm quite sure of them, for I used them a lot.)
The problem is, to use your own font, it'll have to go into RAM, and that means finding an empty spot in the first 16K of memory to store it. Since BASIC program storage begins at $0800/2048, that's a problem; any program you write would overwrite your font unless it was extremely short. So what you'd have to do was either move the start of BASIC above your font, or switch the VIC's bank to high memory preferably at the $C000/49152 range. You could remap the screen inside the utility area, and store your font beneath the KERNAL ROM, where the CPU couldn't see it but the VIC-II could, making use of that hidden RAM for a constructive purpose.
One problem with this that I remember is, the RUN/STOP RESTORE keypress that you'd use to get control of the system back in the event your program locks up or goes out of control restored some of these values back to normal but not all. So if you had to resort to it to regain control of the system, you'd have to type a couple of POKEs blind to get the display useable again.
jepler, I used Novaterm for a small period of time to dial up local bulletin boards. I could read that font if I focused, but it wasn't pleasant.
posted by JHarris at 5:13 PM on May 14, 2014 [17 favorites]
The Commodore 64's memory architecture was rather strange. It contained a full bank of 64K of RAM, but because the processor in it was a MOS 6510 (a slightly improved version of the venerable MOS 6502 used in most 8-bit home computers), which had only a 64K total addressing space, different bits of it were more or less accessible at different times. Particularly, for you were only able to use about 38K of it for BASIC programs.
Most of the rest of the RAM was "hidden beneath" the memory space of other chips, particularly the BASIC and KERNAL ROMs and the addressing space for the I/O registers. Other than the 4K utility area at $C000 (49152), that RAM might as well have not been there unless you were willing to bank switch out the ROMs, and if you did that you were leaving BASIC-land entirely, since by removing them from the memory space you were also separating the CPU from the code needed for normal operation. Generally, if you did that, you were devoting your program exclusively to machine code. I had no good assembler so I was pretty much stuck, mostly, to doing BASIC programs with hand-assembled machine code to optimize slow bits.
But just because the RAM was hidden from reading by the CPU didn't mean it was completely useless. For the system's VIC-II graphics chip also had the ability to read RAM, and it wasn't wired to see the BASIC and KERNAL ROMs at all. It mostly had a full view of the RAM, with the exception of a Character Generator ROM, hidden away by yet another bank switching scheme. The Character Generator was mapped to two places in the addressing space, and at startup the C64 points the VIC-II to the lower of those two images, which is how it displayed character graphics in normal operation.
The VIC-II operated by dividing the 64K memory space into four banks of 16K each, and everything it referenced for generating the display had to be in that bank. (Except for color memory at 53248, which was a special array of 4-bit memory locations inside the VIC-II itself.) Particularly, this included the section of memory used for the screen (starting at $0400/1024 in normal operation) and the chargen image, at $2000/8192. (All these numbers are from memory -- I don't absolutely promise they're right, but I'm quite sure of them, for I used them a lot.)
The problem is, to use your own font, it'll have to go into RAM, and that means finding an empty spot in the first 16K of memory to store it. Since BASIC program storage begins at $0800/2048, that's a problem; any program you write would overwrite your font unless it was extremely short. So what you'd have to do was either move the start of BASIC above your font, or switch the VIC's bank to high memory preferably at the $C000/49152 range. You could remap the screen inside the utility area, and store your font beneath the KERNAL ROM, where the CPU couldn't see it but the VIC-II could, making use of that hidden RAM for a constructive purpose.
One problem with this that I remember is, the RUN/STOP RESTORE keypress that you'd use to get control of the system back in the event your program locks up or goes out of control restored some of these values back to normal but not all. So if you had to resort to it to regain control of the system, you'd have to type a couple of POKEs blind to get the display useable again.
jepler, I used Novaterm for a small period of time to dial up local bulletin boards. I could read that font if I focused, but it wasn't pleasant.
posted by JHarris at 5:13 PM on May 14, 2014 [17 favorites]
Back in the early '80s I bought some floppy disks of various fonts from one of those freeware dealers of the time. It was fun figuring out the bitmap formats of the fonts and then using them to print things out on my epson dot matrix printer. This was on an old CP/M Kaypro machine.
The school I was working at back then had some of the early Macs. It came with a font editor. I tried making the smallest possible font and wrote a few things with it in the word processor. I called it "Minneapolis". The convention at the time seemed to be to name Mac fonts after cities. I think I still have it on an old disk somewhere.
A few years later, my first pc compatible computer used Hercules graphics which was 720x350 resolution. I made a little 8x8 font and wrote a C library to write console output to the graphics screen with this font. That allowed me to have a 90 character wide screen by 43 lines for my programs. Fun to show off at the time. I don't have a picture of what it looked like though.
All fun, but I really know nothing about typography.
posted by DarkForest at 5:52 PM on May 14, 2014 [2 favorites]
The school I was working at back then had some of the early Macs. It came with a font editor. I tried making the smallest possible font and wrote a few things with it in the word processor. I called it "Minneapolis". The convention at the time seemed to be to name Mac fonts after cities. I think I still have it on an old disk somewhere.
A few years later, my first pc compatible computer used Hercules graphics which was 720x350 resolution. I made a little 8x8 font and wrote a C library to write console output to the graphics screen with this font. That allowed me to have a 90 character wide screen by 43 lines for my programs. Fun to show off at the time. I don't have a picture of what it looked like though.
All fun, but I really know nothing about typography.
posted by DarkForest at 5:52 PM on May 14, 2014 [2 favorites]
One of my hobbies is reading the data out of old ROM chips. The C64 font PROM shows that the inverse video was stored as a separate piece of memory. Sometimes you find fonts with extra characters, like this Hebrew bitmap font, or other interesting Easter Eggs, like this 8-bit Muybridge in a PID controller or photos of the engineering team in the Mac SE.
posted by autopilot at 6:10 PM on May 14, 2014 [6 favorites]
posted by autopilot at 6:10 PM on May 14, 2014 [6 favorites]
My heart will always belong to Code Page 437. Those glorious 8x8 CGA characters stuffing 80x25 onto a 640x200 resolution screen. Nothing ever looks the same.
posted by Talez at 6:35 PM on May 14, 2014 [3 favorites]
posted by Talez at 6:35 PM on May 14, 2014 [3 favorites]
What I love about metafilter is that this link came up as already visited. I love busting out that amstrad font, even though I never had an amstrad. It just makes certain low special character code shine.
posted by nutate at 6:53 PM on May 14, 2014
posted by nutate at 6:53 PM on May 14, 2014
I've been fine-tuning a setup on Focuswriter to try to replicate my ideal computer-based writing environment while I'm working to polish off the sharp edges and friction in the editing process as I'm attempting to finish revising my damn book.
It's been a while.
The room was dark. I was wearing my giant AKG headphones tied with a long coiled cord to an old Denon tape deck with dimly glowing analogue VU meters and a remote control on a long wire. The monitor, an NEC JB-1201 amber 12" CRT display coupled to my Commodore 64 with a luminance-line cable I soldered myself. The word processor was a program I typed in from a magazine, and did only what I needed, transcribing words as I spooled out the stories.
The words just hung there in the dark, suspended before me in near orange perfection.
All the clouds turn to words.
Hands on those big brown keys, Eno singing in my headphones, a science fiction novel that paused twenty-five years ago unwinding in a clumsy, overwrought narrative.
All the words float in sequence.
I could search for words and passages. I could cut and move sentences and paragraphs, though the barrier to doing so was just enough to be a deterrent to letting fluidity turn wishy-washy.
No one knows what they mean.
I moved on to a more capable, for writing, Kaypro, which added a red dot of light to the words in those suspended nights, then fell into the final embrace of a compact Macintosh that did everything right, except for the glaring, overwhelming whiteness and clutter of options and possibilities.
Everyone just ignores them.
They say these little finicky details, the contours and surfaces of our tools, shouldn't matter, and I want to agree, but I can't, really. I think, sometimes, that maybe I write so much on Metafilter because it is, in some oblique way, a bit like those old floating days—just text floating, inverted, on a darkened field like a story being carved out of the air by just excluding all the parts that aren't the story.
I've downloaded the appropriate fonts, and I'll add them to my precarious revisionist attempt to time travel to the lateish eighties, and I will be wearing the same headphones now plugged into the computer instead of a machine streaming rust-covered polyester tape, and when I turn the lights off, maybe it will be something like it was, when it was just the music and the words and me, floating in space, pulling it all together, though to a different tune, still borne out of nostalgia, because it's
Miller Time at the bar where all the English meet
posted by sonascope at 7:00 PM on May 14, 2014 [7 favorites]
It's been a while.
The room was dark. I was wearing my giant AKG headphones tied with a long coiled cord to an old Denon tape deck with dimly glowing analogue VU meters and a remote control on a long wire. The monitor, an NEC JB-1201 amber 12" CRT display coupled to my Commodore 64 with a luminance-line cable I soldered myself. The word processor was a program I typed in from a magazine, and did only what I needed, transcribing words as I spooled out the stories.
The words just hung there in the dark, suspended before me in near orange perfection.
Hands on those big brown keys, Eno singing in my headphones, a science fiction novel that paused twenty-five years ago unwinding in a clumsy, overwrought narrative.
I could search for words and passages. I could cut and move sentences and paragraphs, though the barrier to doing so was just enough to be a deterrent to letting fluidity turn wishy-washy.
I moved on to a more capable, for writing, Kaypro, which added a red dot of light to the words in those suspended nights, then fell into the final embrace of a compact Macintosh that did everything right, except for the glaring, overwhelming whiteness and clutter of options and possibilities.
They say these little finicky details, the contours and surfaces of our tools, shouldn't matter, and I want to agree, but I can't, really. I think, sometimes, that maybe I write so much on Metafilter because it is, in some oblique way, a bit like those old floating days—just text floating, inverted, on a darkened field like a story being carved out of the air by just excluding all the parts that aren't the story.
I've downloaded the appropriate fonts, and I'll add them to my precarious revisionist attempt to time travel to the lateish eighties, and I will be wearing the same headphones now plugged into the computer instead of a machine streaming rust-covered polyester tape, and when I turn the lights off, maybe it will be something like it was, when it was just the music and the words and me, floating in space, pulling it all together, though to a different tune, still borne out of nostalgia, because it's
posted by sonascope at 7:00 PM on May 14, 2014 [7 favorites]
(More old Commodore musings follow. Sorry to be long-winded.)
The C64's inverse characters are interesting. Yes, they are stored as separate ROM images. What is weird though is that the system contains another way to produce an effect like that, in hardware, that wouldn't have required duplicating the whole character set in ROM. For the VIC-II chip contains the extremely neglected "Extended Background Color" mode, used in exactly one commercial program I could name, and that's because I myself wrote it.
The major limiting factor of graphics of the age, it should be said, is memory. Even at the time it was possible to create hardware that could produce nice graphic effects. All a computer does in producing graphics, for a CRT in any case, is manipulate a one-dimensional video signal with sufficient fidelity that the CRT's display, in interpreting that signal, will produce the desired display image. It's been mentioned several times before in these parts that the Atari 2600 relies on this fact to produce nearly any image at all. Systems with more capable hardware just use higher-level abstractions for that same process, and with dedicated hardware handling it can manipulate that signal with better timing, resulting in better display resolution.
But these are still general-purpose display devices. If you wanted to devote custom silicon to it you could display anything, so long as you didn't care about ever displaying anything else! These are programmable display systems, which should be able to display a wide variety of image. And, directly, the more variety to those images, the more memory you'll need to display them.
Because of this, 8-bit graphics hardware tends to require a tradeoff of memory use to display quality. The C64, for example, contains several "multicolor" display modes, that can display up to four graphics each character cell, instead of the customary one+background color. Many games use them because it's nice to be able to display many colors, but the problem is, this halves the system's horizontal display resolution. That's because each byte switches from describing eight single pixels of character data, one per bit, to four double-wide pixels. That's because two bits are being used to define the color; two bits can produce four possible colors, but you can't get better fidelity than that without using more memory, which would produce other problems with the workings of the chip that they would not have been able to resolve cheaply enough.
Well, another such mode in the chip is Extended Background Color mode. It performs a different tradeoff. It only works in character mode, there's no bitmap support for it. What it does is allow the programmer access to different background colors for different cells. Usually you're stuck with one background for the entire field, a color stored in location 53281. This lets you define three additional colors in locations 53282-53284. But it also has a memory tradeoff: it uses the high bits of each character definition byte in screen memory (by default at 1024) to specify which of the four background colors that cell will use. So, you gain the ability to display any of two colors in each of the character cells on the screen, but because those high bits are ordinarily used in selecting character data, using them for this purpose cuts by three-fourths the number of characters you're able to display, down from 256 to 64, which is pretty harsh.
However, for ordinary use, it's not that harsh really. Because the default character ROM already wastes half of its space with bit-flipped images of the character set! The system could just use Extended Background Color mode to display those characters. You'd still lose 64 characters doing this, but most of those are just line-drawing graphics anyway. You could just offer reverse-video characters at those times when Extended Background Mode was enabled, then use some of the upper 128 for more graphics. There's already built-in support for switching to an alternate character set to display lower-case characters, so it's not a huge stretch to imagine such a feature.
But it doesn't to this, I think largely because of the limited nature of the code in the system's built-in ROMs. Has there ever been a machine, sold with a BASIC in ROM, that so ignored that system's special hardware features? The version of Microsoft Basic, "Commodore Basic V2.0," shipped in the C64 is remarkably lackluster even among its disappointing kin. The language literally has no explicit sound support, no sprite support, no means of drawing high-resolution graphics and indeed no way to activate that screen mode, no way of changing fonts, and many other lacks besides. Literally everything you'd really want to do on the system has to be done with the overused POKE command, which meant doing nearly anything was extremely slow.
posted by JHarris at 7:10 PM on May 14, 2014 [10 favorites]
The C64's inverse characters are interesting. Yes, they are stored as separate ROM images. What is weird though is that the system contains another way to produce an effect like that, in hardware, that wouldn't have required duplicating the whole character set in ROM. For the VIC-II chip contains the extremely neglected "Extended Background Color" mode, used in exactly one commercial program I could name, and that's because I myself wrote it.
The major limiting factor of graphics of the age, it should be said, is memory. Even at the time it was possible to create hardware that could produce nice graphic effects. All a computer does in producing graphics, for a CRT in any case, is manipulate a one-dimensional video signal with sufficient fidelity that the CRT's display, in interpreting that signal, will produce the desired display image. It's been mentioned several times before in these parts that the Atari 2600 relies on this fact to produce nearly any image at all. Systems with more capable hardware just use higher-level abstractions for that same process, and with dedicated hardware handling it can manipulate that signal with better timing, resulting in better display resolution.
But these are still general-purpose display devices. If you wanted to devote custom silicon to it you could display anything, so long as you didn't care about ever displaying anything else! These are programmable display systems, which should be able to display a wide variety of image. And, directly, the more variety to those images, the more memory you'll need to display them.
Because of this, 8-bit graphics hardware tends to require a tradeoff of memory use to display quality. The C64, for example, contains several "multicolor" display modes, that can display up to four graphics each character cell, instead of the customary one+background color. Many games use them because it's nice to be able to display many colors, but the problem is, this halves the system's horizontal display resolution. That's because each byte switches from describing eight single pixels of character data, one per bit, to four double-wide pixels. That's because two bits are being used to define the color; two bits can produce four possible colors, but you can't get better fidelity than that without using more memory, which would produce other problems with the workings of the chip that they would not have been able to resolve cheaply enough.
Well, another such mode in the chip is Extended Background Color mode. It performs a different tradeoff. It only works in character mode, there's no bitmap support for it. What it does is allow the programmer access to different background colors for different cells. Usually you're stuck with one background for the entire field, a color stored in location 53281. This lets you define three additional colors in locations 53282-53284. But it also has a memory tradeoff: it uses the high bits of each character definition byte in screen memory (by default at 1024) to specify which of the four background colors that cell will use. So, you gain the ability to display any of two colors in each of the character cells on the screen, but because those high bits are ordinarily used in selecting character data, using them for this purpose cuts by three-fourths the number of characters you're able to display, down from 256 to 64, which is pretty harsh.
However, for ordinary use, it's not that harsh really. Because the default character ROM already wastes half of its space with bit-flipped images of the character set! The system could just use Extended Background Color mode to display those characters. You'd still lose 64 characters doing this, but most of those are just line-drawing graphics anyway. You could just offer reverse-video characters at those times when Extended Background Mode was enabled, then use some of the upper 128 for more graphics. There's already built-in support for switching to an alternate character set to display lower-case characters, so it's not a huge stretch to imagine such a feature.
But it doesn't to this, I think largely because of the limited nature of the code in the system's built-in ROMs. Has there ever been a machine, sold with a BASIC in ROM, that so ignored that system's special hardware features? The version of Microsoft Basic, "Commodore Basic V2.0," shipped in the C64 is remarkably lackluster even among its disappointing kin. The language literally has no explicit sound support, no sprite support, no means of drawing high-resolution graphics and indeed no way to activate that screen mode, no way of changing fonts, and many other lacks besides. Literally everything you'd really want to do on the system has to be done with the overused POKE command, which meant doing nearly anything was extremely slow.
posted by JHarris at 7:10 PM on May 14, 2014 [10 favorites]
Cathode for iOS, what!??!!
I think this just solved my retrofuturist writing console project.
posted by Doleful Creature at 8:55 PM on May 14, 2014 [1 favorite]
I think this just solved my retrofuturist writing console project.
posted by Doleful Creature at 8:55 PM on May 14, 2014 [1 favorite]
JHarris: "I made a few Commodore 64 fonts in my time as well. It was a weird system to do graphics for. Let me explain. (What follows is entirely old Commodore hacking memories. You might want to move on to a more interesting comment.)"
As soon as I read the first sentence I knew who the author of this comment would be! And I also knew it was going to be rad.
posted by barnacles at 9:09 PM on May 14, 2014 [2 favorites]
As soon as I read the first sentence I knew who the author of this comment would be! And I also knew it was going to be rad.
posted by barnacles at 9:09 PM on May 14, 2014 [2 favorites]
You can't even change the background color without a POKE on a C64. Without a memory map you can do almost nothing.
posted by JHarris at 9:32 PM on May 14, 2014 [1 favorite]
posted by JHarris at 9:32 PM on May 14, 2014 [1 favorite]
Has there ever been a machine, sold with a BASIC in ROM, that so ignored that system's special hardware features?
What was particularly galling was that BBC BASIC on the BBC Micro -- another 6502-based machine -- was so good. Inline assembler! That BASIC, on the C64 hardware, would have been amazing.
posted by We had a deal, Kyle at 9:34 PM on May 14, 2014 [4 favorites]
What was particularly galling was that BBC BASIC on the BBC Micro -- another 6502-based machine -- was so good. Inline assembler! That BASIC, on the C64 hardware, would have been amazing.
posted by We had a deal, Kyle at 9:34 PM on May 14, 2014 [4 favorites]
Without a memory map you can do almost nothing.
It was a good way to sell copies of the Programmer's Reference Guide. (I remember it as being quite expensive -- £20? but of course utterly indispensable.)
posted by We had a deal, Kyle at 9:36 PM on May 14, 2014 [1 favorite]
It was a good way to sell copies of the Programmer's Reference Guide. (I remember it as being quite expensive -- £20? but of course utterly indispensable.)
posted by We had a deal, Kyle at 9:36 PM on May 14, 2014 [1 favorite]
Here's the 16 bit page.
Needs the EGA and MDA/Hercules character sets (or are the same as VGA? I remember a slash through the 0 rather than a dot before VGA).
posted by Pruitt-Igoe at 9:38 PM on May 14, 2014
Needs the EGA and MDA/Hercules character sets (or are the same as VGA? I remember a slash through the 0 rather than a dot before VGA).
posted by Pruitt-Igoe at 9:38 PM on May 14, 2014
I was no hacker, but I had some kind of utility that allowed me to create and use my own custom font on the C64 (mostly for use with my word processor SPEEDSCRIPT (the source code for which I had typed in copying from a magazine (probably COMPUTE!))).
I spent hours and hours fiddling with the letters of my custom font, with no regard whatsoever for consistency or how they fit together, just wanting each individual letter to look rad. It must've been awful.
posted by straight at 1:08 AM on May 15, 2014
I spent hours and hours fiddling with the letters of my custom font, with no regard whatsoever for consistency or how they fit together, just wanting each individual letter to look rad. It must've been awful.
posted by straight at 1:08 AM on May 15, 2014
If you had Speedscript, I would hazard a guess that the font editor you're talking about, straight, is Ultrafont. It was published multiple times; one of them was in the July 1984 issue of COMPUTE's Gazette. The cover of that issue has a screenshot from it, does it look familiar?
When I designed my own fonts, I first used DATA statements of characters (spaces and asterisks, I think) that were converted algorithmically into the font data, were POKEd into place, and then saved that section of RAM as raw data that could be LOADed later with the direct load command (LOAD "FILENAME",8,1). I seem to remember using an editor later, but I don't remember much about it except that it wasn't Ultrafont, which I never got the chance to use. (It was probably an editor published in the disk magazine Loadstar, which I still have most of my issues of, although I'm not sure if any of the disks are still readable.)
posted by JHarris at 1:35 AM on May 15, 2014 [1 favorite]
When I designed my own fonts, I first used DATA statements of characters (spaces and asterisks, I think) that were converted algorithmically into the font data, were POKEd into place, and then saved that section of RAM as raw data that could be LOADed later with the direct load command (LOAD "FILENAME",8,1). I seem to remember using an editor later, but I don't remember much about it except that it wasn't Ultrafont, which I never got the chance to use. (It was probably an editor published in the disk magazine Loadstar, which I still have most of my issues of, although I'm not sure if any of the disks are still readable.)
posted by JHarris at 1:35 AM on May 15, 2014 [1 favorite]
I once had a job which involved, among other things, writing the screen driver and designing a couple of fonts for a prototype Z80 business machine. The specs were ambitious - full bitwise smooth pan and scroll, windowing, and arbitrary character size proportional font support, all on a 4 MHz processor with no hardware support. Plus the screen memory map was reasonably arcane, designed around video-contended cheap DRAM, where successive rows of pixels on screen weren't contiguous in memory. It was basically a mutated ZX Spectrum with a 'proper' hi-res monochrome mode.
By the time I was doing this, I was a reasonably adept (for a teenager) Z80 hardware/software chap and knew most of the video game tricks for throwing shapes around a screen - unrolled loops, stack funnies, alternate register swaps, pre-computed rotation tables and so on - but it's amazing how few are useful when you're having to be insanely flexible. And anyway, I'm no Bill Atkinson.
The damn thing was almost usable, at least in some configurations, and it looked as if with a little extra hardware support for a handful of memory manipulation primitives plus some constraints on acceptable font sizes it could have shipped without being too embarrassing. Didn't ship, because the company folded shortly afterwards, and although I carried on being a Z80 coder for a year or so afterwards the days of 8-bit business machines were gone. (I was involved a little later again in a feasibility study for what would have been an absolutely fascinating cheap ARM-based DTP/music composition computer, in partnership with a company who wrote Archimedes software.This was in the days when the ST was the default musician's tool, and I still think we could have pwnd its arse... but that's another story)
In retrospect: elegant code is not always the right answer; getting immersed in a bounded problem with no distractions and instant gratification at each advance is utterly lovey; designing fonts by hand can be insanely enjoyable; and what years they were, when a teenager could just cut code and make fonts that had a reasonable chance of making it to market with nobody much minded to get in the way. It's probably like that writing apps now in an indy, but back then you could hold the entire system in your head, to gate level, and wake up at 4am with a hardware tweak that by 4pm would be on your breadboard for a 30 percent speed-up in that 'impossible' but essential edge case.
Oh me, oh my. I think it's been an eternity...
posted by Devonian at 1:57 AM on May 15, 2014 [5 favorites]
By the time I was doing this, I was a reasonably adept (for a teenager) Z80 hardware/software chap and knew most of the video game tricks for throwing shapes around a screen - unrolled loops, stack funnies, alternate register swaps, pre-computed rotation tables and so on - but it's amazing how few are useful when you're having to be insanely flexible. And anyway, I'm no Bill Atkinson.
The damn thing was almost usable, at least in some configurations, and it looked as if with a little extra hardware support for a handful of memory manipulation primitives plus some constraints on acceptable font sizes it could have shipped without being too embarrassing. Didn't ship, because the company folded shortly afterwards, and although I carried on being a Z80 coder for a year or so afterwards the days of 8-bit business machines were gone. (I was involved a little later again in a feasibility study for what would have been an absolutely fascinating cheap ARM-based DTP/music composition computer, in partnership with a company who wrote Archimedes software.This was in the days when the ST was the default musician's tool, and I still think we could have pwnd its arse... but that's another story)
In retrospect: elegant code is not always the right answer; getting immersed in a bounded problem with no distractions and instant gratification at each advance is utterly lovey; designing fonts by hand can be insanely enjoyable; and what years they were, when a teenager could just cut code and make fonts that had a reasonable chance of making it to market with nobody much minded to get in the way. It's probably like that writing apps now in an indy, but back then you could hold the entire system in your head, to gate level, and wake up at 4am with a hardware tweak that by 4pm would be on your breadboard for a 30 percent speed-up in that 'impossible' but essential edge case.
Oh me, oh my. I think it's been an eternity...
posted by Devonian at 1:57 AM on May 15, 2014 [5 favorites]
So - were any of these fonts actually designed by somebody who would call themselves a typographer, I wonder? And if so - can they be found?
Like others my own memories of designing fonts at that time (in my case for an LED display using a 7 by 5 matrix) was that the task was left to a programmer and done with a piece of graph paper.
posted by rongorongo at 3:44 AM on May 15, 2014
Like others my own memories of designing fonts at that time (in my case for an LED display using a 7 by 5 matrix) was that the task was left to a programmer and done with a piece of graph paper.
posted by rongorongo at 3:44 AM on May 15, 2014
I once had a job which involved, among other things, writing the screen driver and designing a couple of fonts for a prototype Z80 business machine. The specs were ambitious - full bitwise smooth pan and scroll, windowing, and arbitrary character size proportional font support, all on a 4 MHz processor with no hardware support. Plus the screen memory map was reasonably arcane, designed around video-contended cheap DRAM, where successive rows of pixels on screen weren't contiguous in memory. It was basically a mutated ZX Spectrum with a 'proper' hi-res monochrome mode.
That sounds an awful lot like an Amstrad PCW!
That successive rows of pixels not being contiguous in memory was also a thing on Amstrad CPC, and that fact alone basically stopped me making an effort at assembly programming. I could never quite get my head around how to do efficient maths to convert (x,y) coordinates to a memory address - it seemed to incredibly inefficient, all the additional operations you needed to map it.
posted by Jimbob at 4:04 AM on May 15, 2014
That sounds an awful lot like an Amstrad PCW!
That successive rows of pixels not being contiguous in memory was also a thing on Amstrad CPC, and that fact alone basically stopped me making an effort at assembly programming. I could never quite get my head around how to do efficient maths to convert (x,y) coordinates to a memory address - it seemed to incredibly inefficient, all the additional operations you needed to map it.
posted by Jimbob at 4:04 AM on May 15, 2014
Like others my own memories of designing fonts at that time (in my case for an LED display using a 7 by 5 matrix) was that the task was left to a programmer and done with a piece of graph paper.
And why not? You don't need an architect to design a play pen, do you? When you're working within 7x5, surely anyone calling themselves a typographer would be overkill.
posted by Jimbob at 4:06 AM on May 15, 2014
And why not? You don't need an architect to design a play pen, do you? When you're working within 7x5, surely anyone calling themselves a typographer would be overkill.
posted by Jimbob at 4:06 AM on May 15, 2014
The cover of that issue has a screenshot from it, does it look familiar?
Whoa, that caused one of the most intense nostalgia rushes I've ever had. I spent a stupid number of hours staring at that Ultrafont+ interface. The ads, even the font of that magazine are triggering some surprisingly vivid flashbacks here. Thanks?
posted by straight at 7:48 AM on May 15, 2014 [2 favorites]
Whoa, that caused one of the most intense nostalgia rushes I've ever had. I spent a stupid number of hours staring at that Ultrafont+ interface. The ads, even the font of that magazine are triggering some surprisingly vivid flashbacks here. Thanks?
posted by straight at 7:48 AM on May 15, 2014 [2 favorites]
Ultrafont+
*feels Proustian rush of nostalgia, reminiscing about the “futuristic” 8x8 fonts (typically sans-serifs with gaps in them à la Stop) he clicked in in said program, whose name he had forgotten until now*
posted by acb at 8:06 AM on May 15, 2014
*feels Proustian rush of nostalgia, reminiscing about the “futuristic” 8x8 fonts (typically sans-serifs with gaps in them à la Stop) he clicked in in said program, whose name he had forgotten until now*
posted by acb at 8:06 AM on May 15, 2014
My Amiga 500 came with a font editor called Fed and it was awesome.
posted by tepidmonkey at 9:33 AM on May 15, 2014 [1 favorite]
posted by tepidmonkey at 9:33 AM on May 15, 2014 [1 favorite]
successive rows of pixels not being contiguous in memory
CGA was like this.
VGA had "bit planes" which were a pain. Each pixel was 4 bits, and memory was divided into 4 64k regions, each just containing the information for a single bit. So if you wanted to change a pixel from black (0x0) to white (0xf) you had to OR memory in 4 locations. It explains certain display artifacts you may have seen - for example flashes of red when using Windows in VGA mode.
posted by Pruitt-Igoe at 10:07 AM on May 15, 2014 [1 favorite]
CGA was like this.
VGA had "bit planes" which were a pain. Each pixel was 4 bits, and memory was divided into 4 64k regions, each just containing the information for a single bit. So if you wanted to change a pixel from black (0x0) to white (0xf) you had to OR memory in 4 locations. It explains certain display artifacts you may have seen - for example flashes of red when using Windows in VGA mode.
posted by Pruitt-Igoe at 10:07 AM on May 15, 2014 [1 favorite]
The trick was to spot that contiguous lines were (if I remember correctly) in general 256 bytes apart. Which meant that for quite a lot (though not all) operations that required accessing sequential vertical locations - which you do really rather a lot in bit-mapped text output - you could store the pointer to the character location in one of the 16-bit register pairs and increment the upper byte.
Another trick was to remember that if you could do it in software, you could do it in hardware. If the Hardies would agree. They tended to say "If you can do it in hardware, you can do it in software" and not agree at all, but we got there in the end. (Or rather, we didn't.)
posted by Devonian at 10:49 AM on May 15, 2014
Another trick was to remember that if you could do it in software, you could do it in hardware. If the Hardies would agree. They tended to say "If you can do it in hardware, you can do it in software" and not agree at all, but we got there in the end. (Or rather, we didn't.)
posted by Devonian at 10:49 AM on May 15, 2014
JHarris' comments are giving me some serious pangs of nostalgia. My C64 programming knowledge was pretty much all self-taught and I never quite wrapped my head around how memory worked or how BASIC programs interacted with it, or how exactly machine language related to all of it; I grokked enough to tinker and tweak, but I never had the "A-ha!" moment where it all made 100% sense. But one of the most advanced things I ever did on that machine was to design my own display font that looked more or less like this.
I designed all the glyphs on graph paper in 8x8 grids and figured the hexadecimal bitmasks for each line of each one, and somehow or other I figured out where to POKE all of that into memory and then I think there was another POKE statement to tell the computer where to look for the character data. As JHarris mentioned, it was slloooowwwww... and that was what led me to do learn enough assembly to re-code it and run it instantaneously with a SYS comand. I remember the tremendous sense of accomplishment tempered with the discouraging sense that there was so much more I didn't quite understand... and that was late 1980s/early 1990s, when the C64 was starting to wane towards obsolescence. If I had been just a couple of years younger I might have gotten into serious software development right in high school, instead of taking a hiatus and coming back around to it by way of HTML and web design some years later.
posted by usonian at 12:00 PM on May 15, 2014 [1 favorite]
I designed all the glyphs on graph paper in 8x8 grids and figured the hexadecimal bitmasks for each line of each one, and somehow or other I figured out where to POKE all of that into memory and then I think there was another POKE statement to tell the computer where to look for the character data. As JHarris mentioned, it was slloooowwwww... and that was what led me to do learn enough assembly to re-code it and run it instantaneously with a SYS comand. I remember the tremendous sense of accomplishment tempered with the discouraging sense that there was so much more I didn't quite understand... and that was late 1980s/early 1990s, when the C64 was starting to wane towards obsolescence. If I had been just a couple of years younger I might have gotten into serious software development right in high school, instead of taking a hiatus and coming back around to it by way of HTML and web design some years later.
posted by usonian at 12:00 PM on May 15, 2014 [1 favorite]
I could go on with more stories but it's probably best to save them for the next Commodore thread. The ends we'd have to go through to make up for the lacks of that BASIC. You could load a file directly to a spot in memory by adding ",1" to the end of the LOAD command, but that left the memory pointers a little weird, so I remember you'd not want to do much else in you program after doing the LOADs. (Also, the system has no command for /saving/ memory, so you had to use weird means to create that file in the first place.)
The implications of that were, you'd try to do all your direct memory loading in a stub program that did little else, then load a main BASIC program and run it, which being a normal load would reset those memory pointers, and then the new program could use SYS statements to take advantage of loaded machine language routines, use POKEs to set the graphics pointers to use loaded fonts and sprites, and so on.
However, there's a problem there. You can use a LOAD statement in a BASIC program to load another BASIC program, but that would, understandably, end execution. You'd end up at a READY prompt with the new program loaded in memory. The user would have to enter the RUN command and press Return to start it, which isn't really professional. What to do about that.
The answer is, to POKE the letters 'R', 'U', 'N', and Return into the keyboard buffer yourself, and also POKE the number of stored characters to 4. That way, when program execution ended, the system would think the user entered the RUN command and start the newly-loaded program immediately. And you could hide this from the user by having the stub program set the character color to the same as the background first, so all this would be typed in invisibly.
We had to do all kinds of weird things to get that computer to bend to our will. And, there being no Internet around at the time and me with only the Programmer's Reference Guide and a decent assembler, there were a good number of techniques I never did learn, like how to create a program as a single large machine executable that led off with a one-line BASIC stub program reading something like SYS2049, so running the program would immediately transfer execution to the machine code. I was so envious of programmers that could do that.
posted by JHarris at 2:29 PM on May 15, 2014 [3 favorites]
The implications of that were, you'd try to do all your direct memory loading in a stub program that did little else, then load a main BASIC program and run it, which being a normal load would reset those memory pointers, and then the new program could use SYS statements to take advantage of loaded machine language routines, use POKEs to set the graphics pointers to use loaded fonts and sprites, and so on.
However, there's a problem there. You can use a LOAD statement in a BASIC program to load another BASIC program, but that would, understandably, end execution. You'd end up at a READY prompt with the new program loaded in memory. The user would have to enter the RUN command and press Return to start it, which isn't really professional. What to do about that.
The answer is, to POKE the letters 'R', 'U', 'N', and Return into the keyboard buffer yourself, and also POKE the number of stored characters to 4. That way, when program execution ended, the system would think the user entered the RUN command and start the newly-loaded program immediately. And you could hide this from the user by having the stub program set the character color to the same as the background first, so all this would be typed in invisibly.
We had to do all kinds of weird things to get that computer to bend to our will. And, there being no Internet around at the time and me with only the Programmer's Reference Guide and a decent assembler, there were a good number of techniques I never did learn, like how to create a program as a single large machine executable that led off with a one-line BASIC stub program reading something like SYS2049, so running the program would immediately transfer execution to the machine code. I was so envious of programmers that could do that.
posted by JHarris at 2:29 PM on May 15, 2014 [3 favorites]
(I might even have some details of that wrong, it's been over two decades. I remember in some cases having to actually print a LOAD command on screen myself, cursor back up the screen, then put a Return in the keyboard buffer so the Return keystroke would "hit" the printed command and load the next part of the program. I've forgotten the precise situation in which I'd have to do that, though.)
posted by JHarris at 2:32 PM on May 15, 2014
posted by JHarris at 2:32 PM on May 15, 2014
I spent a stupid number of hours staring at that Ultrafont+ interface.
Which was probably roughly the same amount of time that I spent "making" sprites in Stuart Smith's Adventure Construction Set (mostly making artless, fiddly revisions to the defaults) for the game I was never going to make.
posted by straight at 5:03 PM on May 15, 2014
Which was probably roughly the same amount of time that I spent "making" sprites in Stuart Smith's Adventure Construction Set (mostly making artless, fiddly revisions to the defaults) for the game I was never going to make.
posted by straight at 5:03 PM on May 15, 2014
I played around with ACS too, straight! What a weird interface.
posted by JHarris at 5:12 PM on May 15, 2014
posted by JHarris at 5:12 PM on May 15, 2014
Not to interrupt the Commodore 64 love fest, here's a few font designer links I recall finding on that group of pixel pushers Kaliber 10000 (which is, alas, only a memory). Thanks to the permanence of the web and my still booting original Titanium Powerbook, I give you two great bitmap fonts peeps Flood Fonts (Atlantis, Aquarius, Ninetwist), and Andre Nossek (Hacker (2000), Ivorg (2000), Robotron (2000)). Enjoy typophiles!
posted by xtian at 2:14 PM on May 17, 2014
posted by xtian at 2:14 PM on May 17, 2014
« Older ‘And This Is Free’ (1964) | We Are Such Stuff As Dreams Are Made On Newer »
This thread has been archived and is closed to new comments
Naive young me never saw the potential to troll my dad, though (probably for the best).
posted by spiderskull at 4:36 PM on May 14, 2014 [1 favorite]