very nice article, love the background info on what's being done. been looking at implementing a simple font renderer for some bare metal software and something like this would be awesome to try and save some resources!
Breaking the physical limits of fonts
21–24 of 24 posts
Re: Breaking the physical limits of fonts
#22Earlier quoted context omitted.
Meanwhile, those of us still slumming it on our TI-99/4As were stuck with a word processor that didn't even try. Not only was TI-Write stuck in 40- (or perhaps 32-) column mode, but they didn't even bother changing the TI's default font, which mapped lowercase code points to small-cap glyphs, making text look nasty, hard to read, and nothing like printed output. The dedication and achievements of the Commodore commun…
Weren't you able to change fonts?
It was supported by the hardware, but they just didn't bother to change the font.
Re: Breaking the physical limits of fonts
#23Great article. As an aside: I found the bit buffer function a little hard to read. I suspect that's because I haven't done a lot of work where I've needed to manipulate bits in a procedural way. Can anyone recommend any resources / exercises for me to get better at this?
Re: Breaking the physical limits of fonts
#24Earlier quoted context omitted.
Weren't you able to change fonts?
Yes, but on a machine that primitive, loading a font takes a significant percentage of the entire computer's resources. Each character required 8 bytes to define its bitmap. If all you want to do is define only the 52 uppercase and lowercase letters (which was allowed), that's still over 400 bytes. The entire computer only had 16,384 bytes of RAM, and not all of that was available to the user. Also, there is the smal…
On the TI-99/4A, if you redefined characters using BASIC, you can only expect such redefinitions to last as long as your BASIC session. Booting into another program (especially on cartridge, as I believe TI Writer was) required a system reset.