You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Hoard-of-fonts Project on Github is preserving fonts for classic computers. Their fonts are stored in an ASCII format which they call YAFF (yet another font format?) that is human- and machine-readable. Since srecord is the tool of choice for preserving and converting ROM images, supporting this format would be a great step for preserving and editing character generator files. It would be reasonable to assume that the rows are stored in consecutive addresses. A parameter could be provided that would indicate the number of columns and rows for writing, and these values could be inferred from the format on reading (and consistency check required for conversion). I am not aware of any character generator ROMs using more than 8 columns. But some of the fonts are for banners and use more than 8 columns. For these, there could be a switch to use consecutive bytes for more than 8 columns, or to split between multiple ROM images. Here is an abbreviated example of the format (DEC VT100 "A"):
# Comments are ignored on read, could be added on write
# to include information about size, organization, etc.
# LATIN CAPITAL LETTER A
0x41:
........
...@....
..@.@...
.@...@..
@.....@.
@@@@@@@.
@.....@.
@.....@.
........
........
The text was updated successfully, but these errors were encountered:
The Hoard-of-fonts Project on Github is preserving fonts for classic computers. Their fonts are stored in an ASCII format which they call YAFF (yet another font format?) that is human- and machine-readable. Since srecord is the tool of choice for preserving and converting ROM images, supporting this format would be a great step for preserving and editing character generator files. It would be reasonable to assume that the rows are stored in consecutive addresses. A parameter could be provided that would indicate the number of columns and rows for writing, and these values could be inferred from the format on reading (and consistency check required for conversion). I am not aware of any character generator ROMs using more than 8 columns. But some of the fonts are for banners and use more than 8 columns. For these, there could be a switch to use consecutive bytes for more than 8 columns, or to split between multiple ROM images. Here is an abbreviated example of the format (DEC VT100 "A"):
The text was updated successfully, but these errors were encountered: