Closed patricksurry closed 5 months ago
one question. The original code mentioned \n
was implementation dependent, but always just outputs LF.
My new code works the same, but wondered if the original intention that this should respect TALI_OPTION_CR_EOL
?
This would be easy change via some conditional assembly in the translation table.
_check_esc_n:
cmp #'n'
bne _check_esc_q
; newline, impl. dependant, using LF (ASCII values 10)
lda #10
bra _save_character
I'm always a fan of saving bytes, and I didn't even consider a table here because the elements to replace were non-contiguous. I should have time to look at this and merge this sometime this weekend.
I do agree that \n probably should follow the line endings from the TALI_OPTION_CR_EOL (it would make TYPE
ing this string follow the user's line ending), although it has the annoyance of resulting in different string lengths and will will only be tested with the LF line ending setting (which is what platform-py65mon.asm sets), so we'll want to test it manually to make sure it's working properly for the three expected settings (just LF, just CR, and both CR and LF (in CRLF order))
If you don't get to it before me, I can add that functionality - you'll still end up saving bytes in the long run as that will be mostly handled with conditional assembly. You can look at xt_cr:
in native_words.asm to see how I handled it there, but I don't think that fits your exact case here because it looks like you need to fall into the code that compiles the character with the char in A. You'll need one of:
Put CR in A
Put LF in A
Put CR in A, compile it, then put LF in A.
I think that can all be handled with some conditional assembly checks - and I agree that you'll need to add a special handler for \n.
The table can already handle each of the options so I just conditionally decide which byte to put in the table. I tested all three cases with s\" n\nm\ml\lr\r" dump
as well as re-running the tests for the default case. There was a comma missing in the commented out CRLF config.
Switching to a translation table for
\a-z
saves about fifty bytes and a bunch of cycles when processing strings. All tests pass, and broke spectacularly when I had an error so the code is definitely exercised.You see the effect in test cycle output for
number
and>number
even for very short strings.