edoM esreveR

I've had a good think about the ASCII conversion problem over the last couple of days, and toyed with a few possibilities. The options are:

1. Chuck the whole idea in the bin and just go back to using the already-working 6502 code which runs during application startup, working through all the in-memory strings and converting them where they lie.
2. Write a DASM macro to encapsulate strings in some sort of byte markers, and then write a post-processor to scan the assembled binary looking for those markers and convert the strings.
3. Dive into the DASM sourcecode and add either a custom directive that would convert strings during the assembly process, or a more generic directive that would allow a branch out to a named process during assembly which could do whatever was needed.
4. Alter the existing pre-processor to somehow encode converted strings in such a way that control codes like ASCII 13 wouldn't break the line structure.
5. Change the mechanics of the way the pre-processor works so that it generates binary data instead of modified sourcecode, and have DASM pull that data in with INCBIN.

As I said last time, I'm loathe to choose Option 1 because it's always going to be more elegant to have the strings already in screen-code inside the binary, and thus not require space for conversion logic or time during startup to execute it. Option 2 was where I'd tentatively got to, but it wasn't ideal - not least because my suspicion about labels being offset from the actual string was proven true, and I didn't really like having to add 'junk' around each string to identify it. Option 3 has a certain appeal, but it could easily take me several months to figure-out what changes to make without breaking anything. And Option 5 was a brief favourite, but upon investigation turned-out to be a bit unwieldy - in order for labels to work properly, every string would have to be a separate INCBIN. Yuck.

Which leaves Option 4, finding a way to alter the encoding of converted strings so they don't upset DASM. By chance, I was idly looking at the original CHARPLOT code which handles string plotting, and noticed something interesting - I use a bit in the Control Byte to indicate whether characters should be plotted in normal or reverse mode, and simply AND that bit into Bit 7 of the character before it gets spat to the screen. Bit 7 controls whether a (non-graphical) character is displayed as ink-on-paper colours, or paper-on-ink (inverse) colours, and all the screen-codes are stored with this bit clear - CHARPLOT sets the bit for each character it plots if the Reverse Mode flag bit in the Control Byte is set.

So the solution to the encoding problem presented itself - if I encode the strings in their converted form, but additionally have the pre-processor set Bit 7 before writing them out to the source file, they'll all be in the range 128-255 and thus won't trigger any ASCII control code issues. Then I can modify CHARPLOT so that it works the other way around - instead of setting Bit 7 if the Reverse Mode flag is set, it can just clear Bit 7 unless the Reverse Mode flag is set. This is absolutely no extra work for the routine, and means that I can make everything work by with just two minor tweaks to code I already have.

I'll post an updated link to the pre-processor when I get a moment.