The BMOW display circuitry supports bitmap fonts, with each character on an 8×16 pixel grid. When I first built the hardware, I used an 8×16 font from X-Windows, but I never cared for it much. Here’s what it looks like:

It’s a serif font, more at home on a printed document than on a computer screen. Notice how lower-case hij all run together, as do klmn, #$, and other font glyphs. Zero is taller than the other numbers. The period/decimal point is in the left portion of the glyph cell instead of centered, which looks very odd for a fixed-width font when it’s used as a decimal point. All the character strokes are one pixel wide, giving it a narrow feel. There’s one pixel of empty space between most characters, horizontally and vertically, so it also feels a bit crowded.

I decided to try some new fonts to replace the X-Windows one, but 8×16 fonts aren’t common. Instead, I tinkered with some classic computer fonts.

This is a slightly modified version of the character font from the Apple II series of computers. The Apple II font glyphs are 7×8, so I inserted an extra empty column into each glyph, and scaled it up to twice the original number of rows vertically, to get 8×16 glyphs. Like the X-Windows font, all the character strokes are one pixel wide, giving it that same narrow feel. The characters themselves are also pretty narrow, with most being only 5 pixels wide, providing 3 pixels of space horizontally between adjacent characters. Most characters are 7 pixels tall (14 after scaling), leaving 1 pixel (2 after scaling) of space vertically between adjacent characters. A lower-case letter with a descender will actually touch a capital letter on the line below it. I burned this into BMOW’s character ROM and played with it for a bit, but it just didn’t look right.

Ah, this is more like it. This is the 8×8 font from the Atari 8-bit computers, scaled up to twice the height vertically, to get 8×16 glyphs. It’s big and bold, with all the character strokes two pixels wide. The characters themselves are wider too, with most of them being six pixels wide, providing two pixels of space horizontally between adjacent characters. Most characters are actually shorter than the Apple II ones, though: 6 pixels high (12 after scaling), leaving 2 pixels (4 after scaling) of space vertically between adjacent characters. I burned this into BMOW’s character ROM, and was fairly happy with the results. My only real regret was that by scaling up an 8×8 font to make an 8×16 font, I was effectively throwing away half of BMOW’s vertical resolution.

My solution was to retouch the Atari font by hand, taking advantage of the addition vertical resolution compared to the original to make curved edges look smoother. You can see the result here. In the process of smoothing the letters, I actually made them slightly bolder than they were before, so now this is an extra-bold in-your-face style font. I’m pretty happy with it overall, as it’s nice and legible, and has a good retro-8-bit style to it.

Here’s a photo of BMOW running MSBASIC with the final font:

I showed off BMOW to an old college friend the other day. He and I did all the digitial electronics labs together at MIT, where I learned what little I know about how to build a computer. Sadly, he seemed to think I was a little insane for all the energy I’ve put into this project, but I have to admit my demo was a little underwhelming. It didn’t help that MSBASIC crashed when I tried to show it off.

Yes, the random crash bug with string manipulation came back. Again. I’d earlier thought it was 100% present with one version of the code, and 100% absent with another, but it started happening intermittently with the “good” version of the MSBASIC code. Six months ago I would have set up the logic analyzer again, and gone digging for the source of the bug, but I couldn’t bring myself to do it this time. My previous investigations had suggested that memory at $149F was getting overwritten or misread somehow, so I made a very quick and ugly “fix” to the MSBASIC code to avoid that location altogether. In fact, I relocated the whole program image to begin at $1500, wasting about 5K of RAM. That seems to have resolved the problem, but it’s a pretty ugly fix. This bug will almost certainly come back to bite me again later, under other circumstances and at a different memory location.