Character Set Question

[kamakazi]

I am working with a character set in RAM (copied from ROM) using an example program from ANTIC Magazine. In the article it replaces the ampersand symbol (&) and says that it is located at decimal number 6 [CHR$(6)]. But I am on an XE system and I have noticed that the entire ATASCII character set has been rearranged on XL and XE systems compared to the original 400/800 models. Is this the reason for the need of a translator cartridge? I am sure that there are other reasons as well but this might change the way I need to develop any programs for the Atari 8-bits.

 

To make sure that programs written on one machine will work correctly on another, is there a way to POKE somewhere to tell what type of Atari computer a person is using?If not then I will have to let the program ask the user what Atari they are using so the character set can be correctly loaded. Are there any other differences I should be aware of (besides CTIA/GTIA and controller port differences)?

[Kr0tki]

But I am on an XE system and I have noticed that the entire ATASCII character set has been rearranged on XL and XE systems compared to the original 400/800 models.

No it hasn't, it's at the same location in all ROMs.

[Synthpopalooza]

I see the issue here

 

You have two sets of data to worry with: ATASCII codes and screen codes.

 

When poking characters to the screen, you have to convert ATASCII into screen codes, using this table:

 

ATASCII 0-31 Screen code 64-95

ATASCII 32-95 Screen code 0-63

ATASCII 96-127 Screen code 96-127

 

Reason for the ordering, is so that the OS can ensure that when dealing with screen characters, code 0 will correspond with the space character, not the heart char. So when you POKE and PEEK chars from the screen, you must use the screen code chart, not ATASCII.

[Rybags]

Main reason actually for reordering is that in Gr. 1 and 2 you only have 64 characters. With ASCII the numbers are in the first half, letters in the second of the old 128 character standard.

By reordering how they did, it pairs the numerics with the upper case letters as well as most of the common punctuation symbols.

Edited May 31, 2014 by Rybags

[kamakazi]

That all makes sense. Thanks for pointing that out. It's strange but it works. I'm surprised I haven't noticed it before. So I may have been "poking" character data in the wrong place then. And that might explain why I'm all of a sudden getting a screen full of jargon when I run a sample program. Thanks again.

[pfeuh]

Hello,

ATASCII 0-31 Screen code 64-95

ATASCII 32-95 Screen code 0-63

ATASCII 96-127 Screen code 96-127

 

Is there such an easily undestandable description of the ascii/atascii conversion?

 

Regards,

 

Pfeuh

[Synthpopalooza]

Basically, almost everything between 32 and 127 conforms to standard ASCII, excepting for some codes corresponding to clearscreen, arrows, and backspace/insert. 0-31 are graphics control characters unique to the Atari. 128-255 are inverse versions of 0-127. In addition, 155 is ATASCII for a carriage return code. You can print the graphics version of this (inverse-Escape), but it requires POKEing the screen code 219 into screen memory.

[pfeuh]

Thanks Synthpopalooza,

 

It helps!

 

Pfeuh

[apemaster]

Here's the table.

[Synthpopalooza]

One other caveat:

 

ATASCII/Screen Code 125, when in any OS mode other then 0, has to be POKEd to the screen to avoid the screen clearing. PRINT #6;CHR$(125) will clear the screen, even if you put an ESC char before it.

[kenjennings]

If you PRINT #6 escape and clear screen in Graphics mode 0, the screen also clears.

 

If you just do a regular PRINT of escape and clear screen in Graphics mode 0 it outputs the clear screen symbol and does not clear the screen.

 

My semi-educated guess is that a regular PRINT without device id is using the E: on #0 by default which interprets the escape sequences while the device #6 goes to S: which does not interpret the escape sequences.

[Timbit]

Thanks for this. I found it very enlightening. I knew there are differences but I didn't know what.

 

Does anyone know whether this is somehow linked to the difference between PETSCII and screen codes on the Commodore 8-bit systems? Obviously PETSCII was around before ATASCII but it seems like they both swapped the ASCII table around for their video chips.

Also, if one were to replace the OS and character ROMs in an Atari, could it be made into a pure ASCII system? Could this be done on the Commodore 8-bit systems?

[Rybags]

I doubt that Atari's reordering has anything to do with Petscii. C64 character codes are swapped around to the point where lower case overrides upper case in the alternate set and really it becomes a bit ridiculous. Then you have screen codes different again, and in some cases different between each character set.

 

Atari reasoning for having screen codes different to Ascii in some cases is logical - to allow upper case letters, numbers and most punctuation marks in the coloured text modes you need to have them occupy the same half of the character set. With standard Ascii that's not possible.

Secondary reasoning, having zero as space makes the S: handler code a bit more efficient vs having to test for special cases where dec. 32 needs to be used instead.

 

Could a custom OS be done which uses pure Ascii - sure, but why? You'd end up with a system that most software wouldn't work on.

[Timbit]

Yes, I definitely have never figured out why PETSCII is how it is.

It still seems strange to not have ATASCII and screen codes match up.

I suppose a custom OS would be useless to most people who merely play games and use pre-written apps, but for those of us who know how and enjoy programming, writing one's on OS is more fun than being able to run software other people wrote.

Now that I've seen your answer to my last question, I realize I should have known it would be possible because Liber809 can run OS-9, which is ASCII-based.

Thank you for your reply.