I had to really really slim the game code down, as well as change a few features in the interpreter code to accommodate some things for the game.

Here is a somewhat long video demonstrating the game code and serial transfer program. I will try and make a video of playing through the game tomorrow.

Here are the new changes, mainly the previously mentioned way of handling button input in the interpreter. There are always small changes I do but forget about to mention on here, but any changes to do with using keywords will be updated on the Keyword Table file.

Using the keyword

BG

 waits until a button press. When a button is pressed, it is stored in the "BV", and can be accessed like any other register:

* Wait for button press *
BG

* Set value of R1 to button value (1-4) *
R1 BV

* Check if we pressed button 2 *
CE BV 2

Another thing I changed was accessing single byte EEPROM addresses. Before only 3 bytes at end of EEPROM were accessible using 6 different keywords, 3 for writing, and 3 for reading. I did this to reduce byte size in programs. But it felt too limited, so now there are only 2 keywords for accessing an EEPROM byte, and byes 382-502 are accessible to user to save data in, like this:

* Write to EEPROM *
EW (address) (value)
EW 0 R1
EW 1 12

* Read from EEPROM *
Rx ER (address)
BB ER (address)
R1 ER 0
BB ER 117

 It now takes 3 bytes in program code to save to EEPROM, and 3 bytes to read.

The address can be 0-117. 8 bytes at end of EEPROM are saved for a feature to be later implemented.
This future feature will have one keyword for saving all 8 registers to last 8 bytes in EEPROM, and one keyword for loading those bytes back into the 8 registers. This could be good for saving a game, etc.

The EEPROM keyword and address can not be used in a conditional like this:

CG ER 32 12
CE R3 ER 0

This will result in an error. This is not a bug but a feature... For now.

Now on to the new game code. I was able to pack a "fully" functional "RPG" game in 127 bytes. Think Pokémon on a one dimensional linear map with only 2 LED's to know what is going on in the game. This was quite the challenge, but I am glad I was able to program it in TGRK instead of adding it into the Arduino sketch.

It ended up having a lot less features then originally planned, but I think with the right tweaks the difficulty can make it enjoyable to play. That is if you don't mind reading the binary codes blinked out to monitor your health level, and subtracting or adding to those blinks to know how many hit points you lost in the last battle, or how much gold you just spent on healing at the inn.

Game Code

R2 64

F1
  FUNC
    
    CE R8 0
      BG
      L0L
      L1L
      CE BV 2
          L1H
          R1 ADD 1
        CG R1 R7
          CG RND 64
            R5 R1 DIV 2 ADD 1
            R8 1
    SEP
    
    CE BV 1
      L0H
      R1 SUB 1
      R8 0
      CE R1 0
        R2 ADD R3
        R3 0
        BB R2
    SEP

    CE R8 1
      L1H
      L0H
      R6 RND ADD R1 ADD R5 DIV 12
      R2 SUB R6
      R8 2
    SEP
      
    CE R8 2
      R6 R2 ADD R3 ADD RND DIV 12 ADD 1 
      R5 SUB R6
      R8 1
      S1
      CLE R5 0
        R7 R1
        R3 ADD RND ADD R1 DIV 2 ADD 1 
        R8 0
        BB R2
        L1L
        L0L
    SEP
    
    CG R2 0
      CLE R1 126
        LPF
    SEP
    CE R1 127
      BB -1
      LP
  FUNC

F1

EOP

I am not going to explain this code in any detail in this post, I go over it line by line in the video. But the key to getting it all in so it was functional was taking out all the AND keywords where you see nested conditional statements. This saved me 5 bytes which was all I needed to add the led control keywords in the right spot to know what the hell is going on while trying to play this abomination.