6

The Commodore 64, and possibly others, I don't know, have character codes (These map integers to characters, in the same way that ASCII does) and there are screen codes (The offset which the VIC-II will use to look up the bitmap in the character set).

The character codes are used in file names, I guess BASIC tokens etc also. The screen codes are only used when putting some letter on the screen! Then there are routines to convert between them. Presumably, the ROM also needs to do exactly this thing.

So is there a reason why not put the bitmaps in the character ROM in the same order that the characters are laid out by PETSCII? That would save people from having to do this daft, daft conversion.

  • 1
    This "daft" conversion continues to this day. To look up a glyph in some modern font file formats, one takes the character code point and runs it through a transformation (usually some sort of map embedded in the font file) to yield the symbol index for the actual glyph data. Glyph order in the font is not character code point order in the character set. At least one file format allows a many-to-one mapping, too, for saving space. – JdeBP Sep 13 '18 at 14:38
  • @JdeBP you mean so that a Cyrillic a and Latin a can occupy the same space? That makes a lot of sense actually. That kind of thing could have worked quite nicely actually if ever they did a Russian Commodore 64. – Wilson Sep 13 '18 at 14:40
  • If they have identical bit representations, yes. – JdeBP Sep 13 '18 at 14:56
  • 1
    @Wilson Here is an example. They've overdone it, unifying Y and У; luckily stopping short of unifying W and Ш. – Leo B. Jan 7 at 17:09
  • @LeoB. Did any Soviet or Russian homecomputers with bitmap fonts ever use ГОСТ 10859 encoding for this? Like a БК or ДВК or something? or do you mean that Commodore really did release a Russian C=64? – Wilson Jan 7 at 17:16
4

The Commodore 64, and possibly others, I don't know, have character codes (These map integers to characters, in the same way that ASCII does) and there are screen codes

To start with this includes the Apple II - but as well several others.

So is there a reason why not put the bitmaps in the character ROM in the same order that the characters are laid out by PETSCII? That would save people from having to do this daft, daft conversion.

For one, isn't there an OS to do that job?

The main reason is simple: Rearranging Them Saves Hardware.

The other is that rearranging them enables additional features.


For example the Apple II had only a ROM for 64 different glyphs. Arranging them in a way to suit ASCII encoding, would mean that ROM space for 128 glyphs would be needed - or additional hardware to do the transformation on the fly. That would have asked for a ROM chip double the size (*1) or a clever logic doing the transformation on the fly. Replacing a rather expensive chip with a few lines of machine code seems like a good trade off. Especially one in line with Woz' constant struggle to cut down the chip count. Isn't it?

Similarly, Sinclair's ZX80/ZX81 character set follow the same reasoning of cutting down the needed ROM space. Except here 11 punctuation characters where switched for graphic symbols to allow for 4 pixel per character cell graphics.

The SinclairSpectrum extends this to 128 codepoints to include full ASCII charset with lower case and all (*2) punctuation plus the drawing symbols.

On the PET the reasoning was a bit different. While it had a character ROM holding 256 glyphs, they where organized as two character sets of 128 each, so standard character handling could be kept as 7 bit. Further the PETSCII encoding corresponded to what the keyboard delivered, and the ROM was organized accordingly.

So while it made sense for the first PET, C64 and other 8 bit Commodore only inherited it for compatibility.


Bottom line, by separating the functionality of having ASCII on the software side, while having a different hardware representation on the CRT controller side enables ways of optimization - much like any other abstract interface does.


*1 - Or at least an additional half the size answering to the missing 31/32 glyphs twice.

*2 - Within reason.

  • "For one, isn't there an OS to do that job?" I'd have thought so. But as you can see, someone found it necessary to write his own code to do this conversion. I haven't looked, bu so I guess the ROM routine isn't usable/convenient for whatever reason. – Wilson Sep 10 '18 at 14:51
  • 1
    Or he just wants to do it ... like in assuming everyone else is less capable. A common varation of the Not-Invented-Here syndrom. – Raffzahn Sep 10 '18 at 15:47
  • The Apple ]['s output routine doesn't actually use ASCII codes, but instead expects to be passed values 128 higher than the desired ASCII code. This was probably done to save a few bytes of ROM, but makes it needlessly difficult for something like a printer card to support 8-bit graphics data. – supercat Sep 10 '18 at 20:38
  • 1
    I had to downvote this 'answer' as it doesn't answer the question. How does it save hardware? This answer doesn't say. What are the additional features it enables? This answer doesn't say. Also, this answer spends more time talking about unrelated systems which are irrelevant to answering the question. Next, the PET doesn't have two sets of 128 characters, it has two sets of 256 characters using 4K of ROM. Lastly, please look up the difference between 'were' and 'where'. It will only take two minutes of your life. – Tim Locke Sep 11 '18 at 2:58
  • 1
    @TimLocke The original PET had a 2 KiB Character ROM. 4 KiB is only the SuperPET and European varaiations of later PET. – Raffzahn Sep 11 '18 at 13:19
3

For the C64, there's a simple reason (probably among others): Control characters vs. reverse video.

There are two character sets of 256 characters and two fonts of 256 glyphs. Both have the following in common:

  • The font has 128 glyphs twice, in normal and reversed display
  • The character set on the other hand has quite a few "control characters", like clear screen, issue newline, change color, and also enable/disable reverse video

Therefore, a 1:1 mapping simply isn't possible.

The system is however designed in a way enabling you to use your own font, and you can encode it however you like -- a while back, I created a font using the IBM CP-437 encoding, this is quite nice for e.g. on-screen docs.

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.