Login
You're viewing the assemblag.es public feed.
  • Nov 5, 2024, 6:42 PM

    Imagine you are in the 70's, and you want to build a character cell terminal with japanese kanji support. how even would you do that?

    The main goal is of course to use as little RAM as possible, so no full bitmap framebuffer. Traditionally, you'd use 2 bytes per character cell (one byte for the character code, one byte for "attributes" - bright, blink, inverse, etc) for about 4KB of ram to hold a screen of text.

    The character set that it would make sense to use… is probably Shift JIS? I'm betting that existing Japanese terminals probably used JIS X 0201, an 8-bit code containing ASCII + "half-width" katakana. Shift JIS extended that to a variable length code with 2 byte codes for kanji from JIS X 0208, and all the two-byte characters would take 2 character cells on the display.

    For simplicity, you could require that kanji are aligned to even columns.

    After that… you need a rather large ROM to encode the images of some subset of the ~7000 characters in JIS X 0208. As a reference, the MSX series of computers used a 128KB rom for the JIS 1 subset, ~3000 characters at 16x16px. Plus some extra logic or rom for a lookup table, since you can't directly address the rom based on the character code.

    Dunno how easy it would be to get that fast enough to handle looking up 40 characters per scanline on the fly. If needed, an extra 80 bytes of ram would be enough to store the rom addresses for a row, calculated during hblank.

    💬 0🔄 1⭐ 0