Jump to content

Photo

Character Set Question

OS Character Atari 400 Atari 800 Atari XL Atari XE Programming BASIC

13 replies to this topic

#1 kamakazi OFFLINE  

kamakazi

    Dragonstomper

  • 530 posts
  • Location:Moberly, Missouri

Posted Fri May 30, 2014 1:24 PM

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)?



#2 Kr0tki OFFLINE  

Kr0tki

    Stargunner

  • 1,133 posts
  • Location:Warszawa, Poland

Posted Fri May 30, 2014 1:56 PM

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.

#3 Synthpopalooza OFFLINE  

Synthpopalooza

    Stargunner

  • 1,472 posts
  • Location:knoxville, TN

Posted Fri May 30, 2014 10:06 PM

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.



#4 Rybags OFFLINE  

Rybags

    Gridrunner

  • 16,144 posts
  • Location:Australia

Posted Fri May 30, 2014 10:11 PM

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 by Rybags, Fri May 30, 2014 10:12 PM.


#5 kamakazi OFFLINE  

kamakazi

    Dragonstomper

  • Topic Starter
  • 530 posts
  • Location:Moberly, Missouri

Posted Sat May 31, 2014 8:09 PM

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.



#6 pfeuh OFFLINE  

pfeuh

    Chopper Commander

  • 100 posts
  • Location:67600 Ebersheim - France

Posted Tue Jun 3, 2014 11:52 AM

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



#7 Synthpopalooza OFFLINE  

Synthpopalooza

    Stargunner

  • 1,472 posts
  • Location:knoxville, TN

Posted Tue Jun 3, 2014 3:49 PM

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.



#8 pfeuh OFFLINE  

pfeuh

    Chopper Commander

  • 100 posts
  • Location:67600 Ebersheim - France

Posted Tue Jun 3, 2014 11:17 PM

Thanks Synthpopalooza,

 

It helps! ;)

 

Pfeuh



#9 apemaster OFFLINE  

apemaster

    Star Raider

  • 98 posts

Posted Tue Mar 10, 2015 4:13 PM

Here's the table.

Attached Thumbnails

  • internal-codes.png

  • jum likes this

#10 Synthpopalooza OFFLINE  

Synthpopalooza

    Stargunner

  • 1,472 posts
  • Location:knoxville, TN

Posted Tue Mar 10, 2015 5:07 PM

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.



#11 kenjennings OFFLINE  

kenjennings

    Dragonstomper

  • 789 posts
  • Me + sio2pc-usb + 70 old floppies
  • Location:Florida, USA

Posted Tue Mar 10, 2015 6:47 PM

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.



#12 Timbit OFFLINE  

Timbit

    Space Invader

  • 15 posts
  • Location:New Brunswick, Canada

Posted Sat Mar 14, 2015 9:18 AM

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?



#13 Rybags OFFLINE  

Rybags

    Gridrunner

  • 16,144 posts
  • Location:Australia

Posted Sat Mar 14, 2015 9:48 AM

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.



#14 Timbit OFFLINE  

Timbit

    Space Invader

  • 15 posts
  • Location:New Brunswick, Canada

Posted Sat Mar 14, 2015 11:56 AM

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.







Also tagged with one or more of these keywords: OS Character, Atari 400, Atari 800, Atari XL, Atari XE, Programming, BASIC

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users