Jump to content
IGNORED

cc65 Atari international characters


Recommended Posts

Hello,

 

I am trying to make use of the german Umlauts in the international ATASCII-char-set.

 

BUT whenever I want to type an ü (lowercase U-Umlaut), which is $0A in hex, I get a total different character.

 

Example: printf("Sch\x0Atzenhausweg 11"); results in total mess.

 

Same is for the characters $07 and $09. $09 results in Ataris TAB Character. All other chars (between 1 and 31) are working well.

 

Can it be, that CC65 converts those characters into C- or DOS-control-chars? That is my only left explaination.

 

And how can I prevent CC65 from doing this?

Edited by atarixle
Link to comment
Share on other sites

Thank you, I will try this using sprintf().

 

EDIT:

 

it really works well ... to make practical use of this (so I don't need to create a string for every sentence that contains one Umlaut), I will turn my own plain text-function into a printf-style-text-function.

Edited by atarixle
Link to comment
Share on other sites

  • 2 weeks later...

Writing a function using sprintf is a lot more difficult than I thought (just because I did never really code much in C at all).

 

Is there another way to prevent cc65 from converting special chars to the C standard?

 

Or is there some1 out there who writes something like that for me?

Link to comment
Share on other sites

Is there another way to prevent cc65 from converting special chars to the C standard?

 

This is not a standard behavior, according to the ISO C standard the value of '\x0A' should be 10, not 155. Report it to the cc65 developers, because it's a bug in their compiler.

Edited by antrykot
  • Like 1
Link to comment
Share on other sites

I more think that cc65 follows the ISO standard this way, so 0x0A will be a LF control character (which becomes 155 on the Atari to be source compatible to most of the software out there).

 

I highly bet, 0x0A becomes another value if I compile for the C64, NES, and so on.

Edited by atarixle
  • Like 1
Link to comment
Share on other sites

I more think that cc65 follows the ISO standard this way, so 0x0A will be a LF control character (which becomes 155 on the Atari to be source compatible to most of the software out there).

 

I highly bet, 0x0A becomes another value if I compile for the C64, NES, and so on.

Correct. This from the cputc function in 'cputs.s' in the Atari 8-bit library sources:

 

post-21964-0-50326100-1542567835.png

 

Translation is performed at such a low level that there is no avoiding it. :)

  • Like 1
Link to comment
Share on other sites

I guess the \x0A gets converted whenever it appears in quotes, no matter if it's in printf or anywhere else.

 

Yes. All the characters outputted through stdio functions to print one or more characters, eventually all end up in the cputc function flashjazzcat mentioned. Only way to avoid it is what I said, to bypass stdio and go to CIO directly. This is not portable, but the Atari international character set isn't anyway :)

 

Edit: Hold my beer. I'll come up with an example.

Edited by ivop
  • Like 2
Link to comment
Share on other sites

Here it is:

#include <stdio.h>
#include <stdint.h>

#define ICCOM 0x0342
#define ICBAL 0x0344
#define ICBAH 0x0345
#define ICBLL 0x0348
#define ICBLH 0x0349

#define CIOV 0xe456

static char buf;

static void cio_putc(char c) {
    buf = c;
    *(uint8_t  *)ICCOM = 11;
    *(uint16_t *)ICBAL = (uint16_t) &buf;
    *(uint16_t *)ICBLL = (uint16_t) 1;
    asm("ldx #0");
    asm("jsr %w", CIOV);
}

void main(void) {
    *(uint8_t *) 756 = 0xcc;
    printf("Sch");
    cio_putc(10);
    printf("tzenhausweg 11\n");

endl:
    goto endl;
}

post-20947-0-07192400-1542659590.png

 

Edit: BTW it seems fflush(stdout) is not needed on the cc65 implementation of stdio.

main.zip

Edited by ivop
  • Like 1
Link to comment
Share on other sites

Correct. This from the cputc function in 'cputs.s' in the Atari 8-bit library sources:

 

I guess that was written by Mark Keates and/or me. This was in the year 2000 and I don't remember the details and who is responsible for that part.

Could be that he or I wanted to be more compatible with "regular" (ASCII) text files. One could think of a "type textfile.txt" or "cat textfile.txt" like program to display

the contents of a text file. If the text file wouldn't be in ATASCII, but in ASCII, the program would still do the right thing.

 

Maybe that part is not really needed in the cputc function. But I will be a major test effort to verify that, after 18yrs the current code in place.

 

regards,

chris

Link to comment
Share on other sites

Here it is:

#include <stdio.h>
#include <stdint.h>

#define ICCOM 0x0342
#define ICBAL 0x0344
#define ICBAH 0x0345
#define ICBLL 0x0348
#define ICBLH 0x0349

#define CIOV 0xe456

static char buf;

static void cio_putc(char c) {
    buf = c;
    *(uint8_t  *)ICCOM = 11;
    *(uint16_t *)ICBAL = (uint16_t) &buf;
    *(uint16_t *)ICBLL = (uint16_t) 1;
    asm("ldx #0");
    asm("jsr %w", CIOV);
}

void main(void) {
    *(uint8_t *) 756 = 0xcc;
    printf("Sch");
    cio_putc(10);
    printf("tzenhausweg 11\n");

endl:
    goto endl;
}

attachicon.gifatari000.png

 

Edit: BTW it seems fflush(stdout) is not needed on the cc65 implementation of stdio.

I would like to hear that work properly pronounced. I am sure my best guess is laughably terrible.

Link to comment
Share on other sites

  • 3 years later...

QUESTION1: Could someone explain the differences, as in PROS v CONS, between:

  1.  @antrykot's short (memory-targeting) workaround and 
  2.  @ivop's CIO direct solution?

Asking because I ran antrykot's code and got identical output as shown by ivop.

I'm guessing ivop's is faster (lots faster?). Not knowing answer to my question, I'd lean toward's antrykot's solution as it's much smaller. 

 

QUESTION2: is `*(char*)756 = 204;` portable across all Atari systems? I expect for 400/800 that character write will work, but one must first soft load a copy of the International character set into their code. Is that all?

 

QUESTION3: Does anyone have an example of CC65 loading and soft loading an alternate character set?

 

 

 

PS - ((This is not intended to overlook "3. ": @sanny source-cloning solution. Since I do understand sanny's proposal, it is not a focus of my question)).

PPS - I've SO been looking for this documentation; happy to find it exists; TY! 

🙂

Link to comment
Share on other sites

I've once solved the problem with many texts in my C program by placing them to an external file and then processing them with a tool that generated character arrays for me in encoding (ATASCII or internal) to my liking.

The tool would need to have a translation table to translate the external file encoding to the ATASCII equivalents. For text-intensive application, it was worth developing the tool. One would say it is an overkill, but CC65/CA65 are generally weak when processing characters in different encodings.

The abyss between the ATASCII international character set and ASCII is simply too deep.

 

The output of the tool is as follows:

https://github.com/baktragh/train3ose/blob/master/train_text.h

 

Then I paint the texts using memcpy() in the application. But that is one of many possible solutions.

 

 

  • Like 1
Link to comment
Share on other sites

6 hours ago, scottinNH said:

QUESTION3: Does anyone have an example of CC65 loading and soft loading an alternate character set?

Don't know what you mean with "soft loading" but for changing the character set, maybe this post helps:

 

 

Of course you could also just load an external file into the memory space of the character set...

 

 

Link to comment
Share on other sites

1 hour ago, Irgendwer said:

Don't know what you mean with "soft loading" but for changing the character set, maybe this post helps:

 

 

 

Yes this helps, thanks.

I can strip this down to an example that redefines a character set nothing else.

 

Quote

Of course you could also just load an external file into the memory space of the character set...

Yes. I am looking for an example of this also, if anyone sees it please share a link.

If no one has a link I will figure it out eventually

(I did it in BASIC long ago using the excellent Dr. C Wacko book, but with C I am still learning the language... and when I try anything "fancy" on the Atari, I often get stuck for hours)

Link to comment
Share on other sites

53 minutes ago, Irgendwer said:

Just use standard C IO functions: (nothing cc65 specific.)

- open

- read

- close

OK thanks, that helps boost my confidence. I can pair that with the rest of your font redefinition example above.

 

I have some other examples to work on first, but when I get this one complete I'll post it here for others, and post to GitHub.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...