ANTIC Mode 2 text rendering

[robus]

New to the forum and hoping someone might have an answer to this question.

 

As a hobby project I'm working on an Atari 400/800 emulator (the 400 was my first computer and I loved that thing!). Things are moving along well (I have a 6502 processor executing the OS ROM code which is nice to see) I'm now investigating ANTIC and GTIA to get something to show up on screen. I'm working on Mode 2 to start and I've got it processing a basic Display List (3 x 8 line blanks + 24 x mode 2 lines), decoding the characters and sending bits to GTIA for coloring as shown in the attachment (apologies for the color scheme!).

 

What I'm confused about is how Mode 2 handles the screen memory beyond my classic "Hello World!" text? The screen memory is zero'd out, but ANTIC can find a glyph for byte 0 which is, of course, the Heart image and proceeds to fill the rest of the screen with that. I don't think I should fill the text screen ram with "Space" characters to avoid drawing to screen, so how does ANTIC know not to render characters when there is no character data?

 

Edited August 30, 2022 by robus

[phaeron]

ANTIC shouldn't be finding a heart for $00, it should be showing empty (space) characters:

• CHBASE = $E0, so the font is stored at $E000-E3FF.
• A character name byte of $00 references the character data at $E000-E007.
• $E000-E007 is all $00, so no character is displayed.

That you have the heart showing up indicates a mixup between ATASCII and INTERNAL character sets, since $00 is the heart character in ATASCII. But that shouldn't be a factor at the hardware level, since ANTIC has no idea of character sets and the default font that it is given at $E000 is ordered in INTERNAL order. ATASCII is purely an OS-level concept from translation in the Display Handler when it reads/writes screen memory.

 

[robus]

26 minutes ago, phaeron said:

ANTIC shouldn't be finding a heart for $00, it should be showing empty (space) characters:

• CHBASE = $E0, so the font is stored at $E000-E3FF.
• A character name byte of $00 references the character data at $E000-E007.
• $E000-E007 is all $00, so no character is displayed.

That you have the heart showing up indicates a mixup between ATASCII and INTERNAL character sets, since $00 is the heart character in ATASCII. But that shouldn't be a factor at the hardware level, since ANTIC has no idea of character sets and the default font that it is given at $E000 is ordered in INTERNAL order. ATASCII is purely an OS-level concept from translation in the Display Handler when it reads/writes screen memory.

 

Thanks for the reply.

 

I'm converting from ATASCII to the internal format (which is why my Hello World! is drawing  ) using this logic:

 

- (uint8)convertATASCIIToGlyph:(uint8)ch
{
    if (ch >= 32 && ch <= 95) {
        ch -= 32;
    } else if (ch < 32) {
        ch += 64;
    } else {
        // It's OK
    }
    return ch;
}

 

[ivop]

That code looks correct. Note how your space between Hello and World is printed correctly, so I assume you are doing something wrong with the remaining characters you print. How is the screen memory initialized?

 

[robus]

It’s zero’d out just as the OS does on startup. I get a space in Hello World because of the space char. I wondering if I should init mode 2 screen ram with spaces but I don’t see any documentation for that?

[phaeron]

Clearing the screen should set all bytes to $00. It's not clear where that Objective C code is being run -- if that's being used to stuff "hello world" onto the screen then that's fine, but if you have that in the ANTIC rendering path that's definitely wrong.

 

[robus]

45 minutes ago, phaeron said:

Clearing the screen should set all bytes to $00. It's not clear where that Objective C code is being run -- if that's being used to stuff "hello world" onto the screen then that's fine, but if you have that in the ANTIC rendering path that's definitely wrong.

 

My emulator is written in ObjC. AFAIK the screen ram receives ATASCII chars which ANTIC translates into ROM glyphs?

 

There’s discussion of EOL codes when BASIC writes to the screen device, but I don’t think ANTIC deals with that?

[phaeron]

7 minutes ago, robus said:

AFAIK the screen ram receives ATASCII chars which ANTIC translates into ROM glyphs?

No, ANTIC translates INTERNAL chars, because that's the ordering of the characters in the font at $E000.

 

Here's what the OS-B memo pad screen looks like in memory:

 

 

...and here's the order of the characters in the font data:

 

Note the order of the blocks -- ATASCII $20-3F, $40-5F, $00-3F, $60-7F. This is why the screen buffer bytes are INTERNAL codes. If the font data had been ordered in ATASCII $00-7F order, then the screen buffer would take ATASCII codes instead.

7 minutes ago, robus said:

There’s discussion of EOL codes when BASIC writes to the screen device, but I don’t think ANTIC deals with that?

Correct, all control codes are handled by the E:/S: handler in the OS ROM.

[robus]

Ah, thanks. The penny drops!

[robus]

Much improved! Thanks for the assist. I couldn't find anything that mentioned which character bytes were actually written into Screen RAM.