Yesterday, 08:26 AM
I think if you check the other byte you'll find it's not actually `CHR$(0)`. Unlike with the arrow keys and such, where they produce `CHR$(0) + CHR(x)`, the modifiers are mapped in the 10030X range so they'll all have the top byte be the same 135 and the bottom byte be the one that changes. 100304 turns into `CHR$(208) + CHR$(135)`.
Part of the issue is that INKEY$ did not return the state of the modifier keys, so there's no corresponding INKEY$ value (hence why the values 10030X, larger than an INTEGER and past the range that INKEY$ returns). If you want to make an INKEY$ replacement you're probably best just ignoring the modifier keys, as you don't need them anyway (`_KEYHIT` already returns values with the modifiers applied. Ex. 'A' vs. 'a'). If you do want to keep them then you'll have to consider whether you want to return the actual 4-byte value or have some kind of weird aliasing with the 2-byte key values (though I don't think `CHR$(208) + CHR$(135)` is a value INKEY$ could ever return anyway, so maybe it's not a real issue).
Part of the issue is that INKEY$ did not return the state of the modifier keys, so there's no corresponding INKEY$ value (hence why the values 10030X, larger than an INTEGER and past the range that INKEY$ returns). If you want to make an INKEY$ replacement you're probably best just ignoring the modifier keys, as you don't need them anyway (`_KEYHIT` already returns values with the modifiers applied. Ex. 'A' vs. 'a'). If you do want to keep them then you'll have to consider whether you want to return the actual 4-byte value or have some kind of weird aliasing with the 2-byte key values (though I don't think `CHR$(208) + CHR$(135)` is a value INKEY$ could ever return anyway, so maybe it's not a real issue).