atarixle Posted November 6, 2018 Share Posted November 6, 2018 (edited) 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 November 6, 2018 by atarixle Quote Link to comment Share on other sites More sharing options...
antrykot Posted November 7, 2018 Share Posted November 7, 2018 Maybe try this as a workaround #include <stdio.h> int main() { *(char*)756 = 204; printf("Sch%ctzenhausweg 11", 10); } Quote Link to comment Share on other sites More sharing options...
atarixle Posted November 7, 2018 Author Share Posted November 7, 2018 (edited) 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 November 7, 2018 by atarixle Quote Link to comment Share on other sites More sharing options...
atarixle Posted November 17, 2018 Author Share Posted November 17, 2018 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? Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted November 17, 2018 Share Posted November 17, 2018 You may like to operate direct on memory and copy that to target locations using the "mem...()" functions. You can even switch the character representation to the internal one and copy to the screen memory: https://cc65.github.io/doc/atari.html#ss5.4 Quote Link to comment Share on other sites More sharing options...
antrykot Posted November 18, 2018 Share Posted November 18, 2018 (edited) 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 November 18, 2018 by antrykot 1 Quote Link to comment Share on other sites More sharing options...
atarixle Posted November 18, 2018 Author Share Posted November 18, 2018 (edited) 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 November 18, 2018 by atarixle 1 Quote Link to comment Share on other sites More sharing options...
ivop Posted November 18, 2018 Share Posted November 18, 2018 I think your only option is to use CIO directly. If you mix this with usage of the printf family, I assume you have to be sure to fflush(stdout) before using CIO yourself. Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted November 18, 2018 Share Posted November 18, 2018 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: Translation is performed at such a low level that there is no avoiding it. 1 Quote Link to comment Share on other sites More sharing options...
atarixle Posted November 19, 2018 Author Share Posted November 19, 2018 I guess the \x0A gets converted whenever it appears in quotes, no matter if it's in printf or anywhere else. Quote Link to comment Share on other sites More sharing options...
ivop Posted November 19, 2018 Share Posted November 19, 2018 (edited) 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 November 19, 2018 by ivop 2 Quote Link to comment Share on other sites More sharing options...
ivop Posted November 19, 2018 Share Posted November 19, 2018 (edited) 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; } Edit: BTW it seems fflush(stdout) is not needed on the cc65 implementation of stdio. main.zip Edited November 19, 2018 by ivop 1 Quote Link to comment Share on other sites More sharing options...
sanny Posted November 19, 2018 Share Posted November 19, 2018 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 Quote Link to comment Share on other sites More sharing options...
+Stephen Posted November 20, 2018 Share Posted November 20, 2018 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; } atari000.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. Quote Link to comment Share on other sites More sharing options...
sanny Posted November 20, 2018 Share Posted November 20, 2018 To the OP: you can copy cputs.s from the library sources to your project, modify it (remove 0x10 special handling) and compile and link it to your application. It will replace the library version of these functions. 2 Quote Link to comment Share on other sites More sharing options...
scottinNH Posted October 4, 2022 Share Posted October 4, 2022 QUESTION1: Could someone explain the differences, as in PROS v CONS, between: @antrykot's short (memory-targeting) workaround and @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! 🙂 Quote Link to comment Share on other sites More sharing options...
baktra Posted October 4, 2022 Share Posted October 4, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted October 4, 2022 Share Posted October 4, 2022 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... Quote Link to comment Share on other sites More sharing options...
scottinNH Posted October 4, 2022 Share Posted October 4, 2022 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) Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted October 4, 2022 Share Posted October 4, 2022 1 hour ago, scottinNH said: Yes. I am looking for an example of this also, if anyone sees it please share a link. Just use standard C IO functions: (nothing cc65 specific.) - open - read - close Quote Link to comment Share on other sites More sharing options...
scottinNH Posted October 4, 2022 Share Posted October 4, 2022 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.