I think I found a bug:

In the reference material under ARITHMETIC, it shows `AND r1 0xFF` as valid. However, actually using that code always produces zero regardless of what is in r1. My experiment concluded that only decimal inputs are supported, and hexadecimal are not, but the reference doesn't say that, and the editor doesn't flag the hexadecimal inputs as an error. Perhaps the reference material should be updated to simply show "255" instead of "0xFF".

Here is code to reproduce:

  ; ==================================================
  ; Bug Report:
  ;   AND operation returns 0 when give a hex argument
  ;
  ; Expected behavior:
  ;   (1 AND 0xF) should either equal 1 or the
  ;   line should be flagged as an error.
  ;
  ; Actual behavior:
  ;   (1 AND 0xF) equals 0 and does not flag error.
  ; ==================================================

  .alias input r0
  .alias output_using_hex r1
  .alias output_using_dec r2

  main:
      ; Pick any number only using bits 0xF
      SET input 1

      ; Test using hex
      SET output_using_hex input
      AND output_using_hex 0xF  ; no error raised

      ; Test using decimal
      SET output_using_dec input
      AND output_using_dec 15  ; (15 == 0xF)

      PICKUP  ; end the tick, so registers are stable
      ; Registers at this tick boundary:
      ; input:            1
      ; output_using_hex: 0 (incorrect)
      ; output_using_dec: 1 (correct)

      JMP main

thanks for the bug report! oversight on my part, pushing hex support rn :)