Welp. CHR 13 becomes CHR 10 in files.

This is self-explanatory, and just plain dumb. When saving a TXT or PRG, all occurrences of CHR 13 become CHR 10. Why make this a feature? Just, why? Now if I have a 13-character entry in a save file, I have to pad it. I shouldn't have to bow to such dumb design choices. Ugh. Take this as a warning, everyone who wants to do thorough processing of TXT files.

What is CHR 13 or 10? Do they equate to some kind of character code? If so, what characters? Do you have any suspicion as to why they made this design decision?

U+000A = character 10 = Line Feed. U+000D = character 13 = Carriage Return. These both mean "line break", and they exist because historically - in typewriters - these were two separate actions that needed to be performed in order to start a new line. In computers, this no longer applies, but we still have those two characters. Because of this, different operating systems (and indeed, different software inside each OS) may use different combinations of these characters. There are 4 possibilities:

• LF
• CR
• LF+CR
• CR+LF

You can read about it here: https://en.wikipedia.org/wiki/Newline It seems that SmileBASIC uses just a single LF (character 10), and decides quite rudely that any occurrences of CR should be replaced with LF. As Snail points out, this is a huge problem when you want to use text files to store data, by encoding the data into the character codes.

As Snail points out, this is a huge problem when you want to use text files to store data, by encoding the data into the character codes.

Only if you load the text data into a program slot (intended for holding programs). Text data stored in a string variable (intended for holding text data) is fine.

Well, at least we have DAT files.

As Snail points out, this is a huge problem when you want to use text files to store data, by encoding the data into the character codes.

Only if you load the text data into a program slot (intended for holding programs). Text data stored in a string variable (intended for holding text data) is fine.

Nope.

SAVE "TXT:TESTSTRING",CHR$(13)
S$=LOAD("TXT:TESTSTRING",#FALSE)
PRINT ASC(S$[0])

Prints out 10. On save, no text is safe. EDIT: I should point out that inserting CHR 13 into a PRG slot will in fact insert a CHR 13: one of those blue arrows. It doesn't break the line either. However, on save this character is converted to a CHR 10. The editor simply displays CHR 10s as the blue arrow character (which is another, even more confusing design choice.)

As Snail points out, this is a huge problem when you want to use text files to store data, by encoding the data into the character codes.

Only if you load the text data into a program slot (intended for holding programs). Text data stored in a string variable (intended for holding text data) is fine.

Nope.

SAVE "TXT:TESTSTRING",CHR$(13)
S$=LOAD("TXT:TESTSTRING",#FALSE)
PRINT ASC(S$[0])

Prints out 10. On save, no text is safe. EDIT: I should point out that inserting CHR 13 into a PRG slot will in fact insert a CHR 13: one of those blue arrows. It doesn't break the line either. However, on save this character is converted to a CHR 10. The editor simply displays CHR 10s as the blue arrow character (which is another, even more confusing design choice.)

Yeah, this is definitely a strange way of handling all this. Maybe you could submit it as a bug up to SmileBOOM and explain what you're using it for?

Yes, please, submit a bug report: https://miiverse.nintendo.net/posts/AYMHAAACAAADVHklSy9oJg If you don't have a Miiverse account, with your permission, I will post the bug report, crediting you for discovery - one way or another, this should get reported.

Yes, please, submit a bug report: https://miiverse.nintendo.net/posts/AYMHAAACAAADVHklSy9oJg If you don't have a Miiverse account, with your permission, I will post the bug report, crediting you for discovery - one way or another, this should get reported.

Really didn't feel comfortable with calling this one a bug, but I went for it. Just another bug for the tally.

If it was just when you were using program slots, I understand your hesitation. But if it happens with string variables too, that is unquestionably a bug.

It doesn't happen with strings.

Did you try the code posted by slackerSnail? For me, it prints 10. Do you have repeatable code that shows CHR$(13) is not always converted to CHR$(10)?

It doesn't happen with strings.

It happens when you save a TXT or PRG. Within the contents of the file, CHR 13 is always replaced with CHR 10. The contents of the string or PRG slot you're saving aren't immediately altered, only if you loaded said file over them.

So you really can print a CR arrow as a plain character? wow xD ok ;3

PRINT CHR$(13) yeah

Well crud. I was making a file type that saves as TXT and holds integers as characters.

Make custom CHR$ and ASC functions DEF _CHR$(ASCII) IF ASCII==13 THEN RETURN "(enter symbol in the symbols menu)" ELSE RETURN CHR$(ASCII) END DEF ASC(CHARACTER$) IF ASC(CHARACTER$[0])==13 then RETURN (ascii of previously mentioned symbol) ELSE RETURN ASC(CHARACTER$[0]) END

Make custom CHR$ and ASC functions DEF _CHR$(ASCII) IF ASCII==13 THEN RETURN "(enter symbol in the symbols menu)" ELSE RETURN CHR$(ASCII) END DEF ASC(CHARACTER$) IF ASC(CHARACTER$[0])==13 then RETURN (ascii of previously mentioned symbol) ELSE RETURN ASC(CHARACTER$[0]) END

This only changes the problem of CHR$(13) being transformed into CHR$(10) into the problem of CHR$(13) being transformed into some other character.

This is the solution I am using:

DEF TO_SAVESTRING A$ OUT RESULT$
 RESULT$=""
 VAR I%,B$
 FOR I%=0 TO LEN(A$)-1
  B$=A$[I%]
  IF (B$=="\") THEN
   B$=B$*2
  ELSEIF (B$==CHR$(13)) THEN
   B$="\D"
  ENDIF
  PUSH RESULT$,B$
 NEXT I%
END

DEF FROM_SAVESTRING A$ OUT RESULT$
 RESULT$=""
 VAR I%,B$
 WHILE (I%<LEN(A$))
  B$=A$[I%]
  IF (B$=="\") THEN
   INC I%
   IF (I%<LEN(A$)) THEN
    B$=A$[I%]
    IF (B$=="D") THEN
     B$=CHR$(13)
    ENDIF
   ENDIF
  ENDIF
  PUSH RESULT$,B$
  INC I%
 WEND
END

SAVE "TXT:TXTFILE",TO_SAVESTRING(A$)
A$=FROM_SAVESTRING(LOAD("TXT:TXTFILE"))

Hm. Backslash "\" appears as \. Doesn't really matter as long as it's the same character in both places.

>This only changes the problem of CHR$(13) being transformed into CHR$(10) into the problem of CHR$(13) being transformed into some other character. Well, now there won't be 2 characters that are turned into the same character. What else do you need? You can now do encryption and other stuff without worrying about your data being corrupted.