Embedded and legacy rabbit holes
-
A neat thing about embedded is that everything old is new again. I'll explain: I grew up coding 8 and 16-bit machines. I often had 64KB of RAM, and 1-2MHz of CPU grunt. You had to get creative to do anything with it at all. Embedded is - while not quite as constrained typically (although in some cases, even more constrained), and in any case still pretty limited. Ergo, old technologies can get a new lease on life because they were designed for systems with relatively anemic hardware. Enter Windows 3.1 raster font files. These little monsters are useful to me because there really isn't a common file format for non-antialiased raster fonts. There are some one-offs, but they're not file formats but rather, in memory, or in flash formats, which is a bit different. While they can be written to a file, the only time you see them in files is C header and implementation files. .FON files are as good as it gets in that arena, as far as I can tell, so I support them in my embedded graphics library. Did you know .FONs are essentially renamed .DLLs? In either PE or NE format, and they're stored as an embedded resource. Parsing that is fun! X| It's a weird format besides. The pixels are laid out vertically rather than horizontally, for example. Anyway, this isn't the only time I've rehabilitated old tech for embedded, but it's one of the weirder ones. I found python code for parsing the font files, which I had to teach myself enough of to port it to C++. mkwinfont/python/dewinfont.py at master · juanitogan/mkwinfont · GitHub[^]
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
A neat thing about embedded is that everything old is new again. I'll explain: I grew up coding 8 and 16-bit machines. I often had 64KB of RAM, and 1-2MHz of CPU grunt. You had to get creative to do anything with it at all. Embedded is - while not quite as constrained typically (although in some cases, even more constrained), and in any case still pretty limited. Ergo, old technologies can get a new lease on life because they were designed for systems with relatively anemic hardware. Enter Windows 3.1 raster font files. These little monsters are useful to me because there really isn't a common file format for non-antialiased raster fonts. There are some one-offs, but they're not file formats but rather, in memory, or in flash formats, which is a bit different. While they can be written to a file, the only time you see them in files is C header and implementation files. .FON files are as good as it gets in that arena, as far as I can tell, so I support them in my embedded graphics library. Did you know .FONs are essentially renamed .DLLs? In either PE or NE format, and they're stored as an embedded resource. Parsing that is fun! X| It's a weird format besides. The pixels are laid out vertically rather than horizontally, for example. Anyway, this isn't the only time I've rehabilitated old tech for embedded, but it's one of the weirder ones. I found python code for parsing the font files, which I had to teach myself enough of to port it to C++. mkwinfont/python/dewinfont.py at master · juanitogan/mkwinfont · GitHub[^]
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
He's the same guy (Simon Tatham) that wrote putty
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
Oh wow. I didn't know that! :)
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
A neat thing about embedded is that everything old is new again. I'll explain: I grew up coding 8 and 16-bit machines. I often had 64KB of RAM, and 1-2MHz of CPU grunt. You had to get creative to do anything with it at all. Embedded is - while not quite as constrained typically (although in some cases, even more constrained), and in any case still pretty limited. Ergo, old technologies can get a new lease on life because they were designed for systems with relatively anemic hardware. Enter Windows 3.1 raster font files. These little monsters are useful to me because there really isn't a common file format for non-antialiased raster fonts. There are some one-offs, but they're not file formats but rather, in memory, or in flash formats, which is a bit different. While they can be written to a file, the only time you see them in files is C header and implementation files. .FON files are as good as it gets in that arena, as far as I can tell, so I support them in my embedded graphics library. Did you know .FONs are essentially renamed .DLLs? In either PE or NE format, and they're stored as an embedded resource. Parsing that is fun! X| It's a weird format besides. The pixels are laid out vertically rather than horizontally, for example. Anyway, this isn't the only time I've rehabilitated old tech for embedded, but it's one of the weirder ones. I found python code for parsing the font files, which I had to teach myself enough of to port it to C++. mkwinfont/python/dewinfont.py at master · juanitogan/mkwinfont · GitHub[^]
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
I could see the vertical format working if they are trying to race the raster from the CRT. Remember those? spit the top row of bits across one line, advance bit mask one position, repeat. win 1.0 was probably running on slow CPUs when that format was developed. I started with win 2.1 at 12Mhz and EGA was ground breaking. No pre-fetch cache, etc
-
I could see the vertical format working if they are trying to race the raster from the CRT. Remember those? spit the top row of bits across one line, advance bit mask one position, repeat. win 1.0 was probably running on slow CPUs when that format was developed. I started with win 2.1 at 12Mhz and EGA was ground breaking. No pre-fetch cache, etc
It wouldn't work that way because you still have to read the text left to right, top to bottom. There's probably some reason for it, but I don't know. Curiously, it's the same format as the SSD1306 monochrome OLED display's framebuffer.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
