TaskWindow Wrch bug

Another discovery I forgot to write up.

All versions of TaskWindow have a bug in their Wrch handling that results in an address exception that does not occur outside the TaskWindow.

A comparison that is intended to spot control codes is signed instead of unsigned, which results in negative values of R0 on entry to Wrch being treated as a control code and used as an index into a table.

Naturally, very large negative values cause an exception. This doesn’t happen normally.

        CMP    R0,#10
        CMPNE  R0,#32
        BGE    ...      ; this should be BHS

I spotted this because I wrote a lovely little function that converts a Unicode into a UTF-8 sequence packed in a single register which can then be output very neatly:

loop    SWI    XOS_WriteC
        MOVS   R0, R0, LSR#8
        BNE    loop

Surely the problem there is that TaskWindow is treating the argument to OS_WriteC as a 32bit value, when in reality only the lower 8 bits are significant?

I have been too tentative, an early AND#&ff would certainly solve it.

I was trying to keep TaskWindow from making too many assumptions, but we can’t have TaskWindow thinking &100 is a visible chr and everything else thinking it’s a control code.