Put characters in display ram isn't ATASCII?

[Thelen]

Hi All,

I'm putting bytes in the display ram in textmode- but these bytes don't correspondent with the ATASCII characterbytes... (so I'm always struggeling with this) - why is that, and is there a list of the characters with the corresponding bytes to put in displayram?

Thanks!

[tebe]

https://www.atariarchives.org/mapping/appendix10.php

[Thelen]

45 minutes ago, tebe said:

https://www.atariarchives.org/mapping/appendix10.php

Great! Thanks for the quick reply!

[+DjayBee]

Look at the codes in HEX then they make more sense.

[tebe]

Mad Assembler

 lda #'Z'    ;atascii

 lda #"Z"    ;internal

 

[TGB1718]

2 hours ago, Thelen said:

I'm putting bytes in the display ram in textmode- but these bytes don't correspondent with the ATASCII characterbytes... (so I'm always struggeling with this) - why is that, and is there a list of the characters with the corresponding bytes to put in displayram?

If you MADS, it will convert strings for you, in double quotes you get the screen bytes, in single quotes, you get ATASCII

 

This is an example output from MADS showing the difference

 

   206 A003 28 65 6C 6C 6F 00 +      .byte "Hello World"
   207 A00E 48 65 6C 6C 6F 20 +      .byte 'Hello World'

 

Just noticed @tebe has shown the single character version, but it also works for full strings

Edited January 23 by TGB1718

[Thelen]

Thanks both, great feature of Mad Assembler!!

[pcrow]

FYI: When I first ran into this, it felt like a stupid thing that shouldn't have been done, but then I realized why they did it: You want all zeros in display memory to be a blank screen, so $00 must be a space.  ASCII has $20 as space, and to avoid wasting a character in the character set to have two blank characters, they mangled the character order for the screen memory.

 

Now what I still think is stupid is that they didn't just do an exclusive-or of $20 so that it would be a trivial conversion.  That would also have made it nice in that it would have just flipped the case of letters, making it much easier for coders as well.  If someone sees the wisdom of what they instead did, please enlighten me.

[Teapot]

I think the screen code layout is set up so the 4-color text modes, which can only access 64 characters out of the font, are more usable. If ATASCII was used, even with the EOR $20, you'd have one font choice of all graphics symbols and numbers and punctuation and another of all upper and lower case letters with a few random other symbols. The rearrangement gives you letters in both reduced fonts. Most of the commonly used characters are in one of them.  It's still flawed though since there's no space (❤️) in the lowercase half.

[pcrow]

55 minutes ago, Teapot said:

I think the screen code layout is set up so the 4-color text modes, which can only access 64 characters out of the font, are more usable. If ATASCII was used, even with the EOR $20, you'd have one font choice of all graphics symbols and numbers and punctuation and another of all upper and lower case letters with a few random other symbols. The rearrangement gives you letters in both reduced fonts. Most of the commonly used characters are in one of them.  It's still flawed though since there's no space (❤️) in the lowercase half.

Thanks!  I'm sure that's the answer.  This puts $20-$5F in the GR.1 and GR.2 screens, giving you numbers, punctuation, and uppercase letters.  That totally makes sense now.  And there's no graphics mode that selects the other half of the character set, so there's no need for a space there.  And now that I know that's the answer, I can remember exactly what the formula is to convert and why it's more complicated than a simple bit operation.

[Rybags]

Yep, the answer for sure would be for Gr. 1 and 2 - the space being 00 a convenient side-effect.

You can use the other half of the character set to get lower case but the problem is you have no space character in the default chset.

[Teapot]

13 hours ago, Rybags said:

the space being 00 a convenient side-effect.

I think space being 00 was entirely the point. That way a zero byte was always only the background color in every graphics mode.

[pcrow]

11 minutes ago, Teapot said:

I think space being 00 was entirely the point. That way a zero byte was always only the background color in every graphics mode.

I agree.  It's lucky that a space in ASCII is a nice round number.  And if it were $00, then C would have needed a different method for storing strings.  Now I'm wondering how other computers in the day handled things.  Using bitmap memory and copying characters from the character set would be dead simple and not require any fancy graphics support, but that would take nearly 8K of RAM, so I assume they did the same thing Atari did.  Did they also have a similar internal screen code mapping?  They didn't have the GR.1 or GR.2 modes, though, so they could have just done an EOR #$20 mapping; did they?

[Rybags]

C64 also uses different mapping though still maps space as 32.  It has the extended colour mode (rarely used) which reduces the character set to 64 characters.

 

Practically all the old 8-bit computers had text modes similar to how ours worked.  Though BBC Model B used bitmap for most of it's modes allowing freely mixing graphics + text.

Most others would have had a direct ASCII -> screen code relationship, it was only really Atari and C= that had lots of extra modes.

Amstrad - I believe that's another machine that used bitmap, it was developed to be similar (and better) than the BBC.