Unprintable character in dynamic strings because of CopyDialogIndirect() issue.

[SmolBig]

CopyDialogIndirect() contains the following loop that controls how much it copies:

?loop:
	LDA [$00], Y ; load the next character from the pointer
	STA !DIALOG_BUFFER, X ; write to the buffer
	INX : INY
CMP.b #$7F : BNE ?loop

My issue is that I'm trying to use the character that encodes to 0x007F, but it's causing the copy to end prematurely, and without the terminating 0x7F, which means that the printed text spazzes out and just keeps printing gibberish until it finds something to end on. (Because 0x007F doesn't terminate the actual print.)

[sporchia]

7F is a terminating byte, even the original code doesn't map anything to it

[SmolBig]

Hmm. Okay, I'll try to figure out how the original code handles printing the corresponding character. It must decompress it differently or something.

[KevinCathcart]

Technically the original code would accept 0x00 0x7f under the dual byte character set ("Uncompressed"). But It would require a very unusual sequence in the variable byte encoding ("compressed") to generate it (I think that the following might work: 0xFE 0x00 0xFE 0x7F). I strongly suspect that Nintendo's own encoder did not have support for generating that sequence, hence why Nintendo did not use that slot. But they did use the dual byte 0x01 0x7F character (variable byte 0xFD 0x7F).

Even my code for going from the dual byte character set to the single byte character set does not support that.

[SmolBig]

Stepped trough the JP1.0 decompress, and it doesn't have an issues with 0x7F, so re-opening.

0eeea9 lda [$04],y
0eeeab and #$00ff
0eeeae cmp #$00f6
0eeeb1 bcs $eec6
0eeeb3 xba
0eeeb4 and #$ff00
0eeeb7 sta $7f1200,x
0eeebb iny
0eeebc sty $1cdd
0eeebf inx
0eeec0 inx
0eeec1 stx $1cd9
0eeec4 bra $eea9