Conventionly we have the 10 'ascii' digits possibly mapped into a [I think] 5 * 7 'image matrix' - the '0 to 9' character renderings.
For machine code programming of a 16 bit CPU, it is much more intuitive to have the number, hex in this case, mapped to a 4 * 4 'image'.
So. eg. 13=hex0D would be rendered in it's 4 * 4 'image' as: [13=8+5=8+4+1=##0# : pixel on/off = #/0] 0000 0000 0000 ##0# And the following char, which looks a bit like a "Z" #### > 256 * 16 00#0 > 256 0#00 > 16 #### > 1 represents the number: (8+4+2+1)*256*16+2*256+4*16+15 = ? Wow ! I don't find my calculator ! = hexF24F
I've chosen to give the MSbit first [top-posters are screwed here!].
So if the "Z" looking image represents the number %F24F, then perhaps 'ADD %F24F ...' could be displayed as "+Z..." ? And you could see the individual bits change the "Z", another image.
IMO the concepts which werty is selling are similar to the abacus, which more DIRECTLY represents eg. "7 - 5 = 2", than 'our way of going via the 'symbols': "7", "5", "2", "-","=".
werty correctly realises that skipping the extra stage of translating concepts to text has great advantages, when communicating with a CPU-systems.
Of course we still need the text, in our case ascii, to communicate with humans - because of convention.
== Chris Glur.