benryves wrote:
No, as the TIOS mapping is pretty mental. Rather than having a fixed table, I'll use a hash table which maps a char to a char (char as in 16-bit character, not as in C's "byte" type). This table would be empty at the start, however...
I imagined so, except for the initial empty state.
benryves wrote:
...in this case, it might be sensible to substitute in the "original" value if the input character code is between 32 and 127, otherwise display an error.
At least that much, yes. And I think you should add as many characters as possible to the initial table (like Greek letters with TIOS support).
benryves wrote:
I'm not sure what problems could be caused, nor am I aware of the broken Ion headers, but I do see your point. I'll remove it.
Come on, you can’t say you’ve never heard of the infamous ‘.byte $bb, 6d’ incident!

benryves wrote:
I'm aware that some assemblers will have to hack about with the input - for example, with the Z80 index instructions the Z80 plugin would have to remove the IX or IY token before the expression is evaluated.
Why is that a problem? Expressions are nicely tokenised and passed in a structured form. You can’t really avoid that with a general parser.
benryves wrote:
I'm not sure what that means for the arrow notation (not that I've ever seen the arrow notation)...
I’ve come across these notations so far, and I was thinking of the last one:
rlc b,(ix) / set b,0,(ix)
ld b,rlc (ix) / ld b,set 0,(ix)
rlc (ix)->b / set 0,(ix)->b
All of them are perverse in some way, but so are these instructions.
