notANON

TinyELF Emulator for Macintosh OS X

I’ve now hit chapter 4 in Tom Pittman’s “A Short Course in Programming” book that has been graciously posted online for the world to enjoy.  Chapter 4 deals with registers but almost immediately it sends you back to program 2.3 at the end of chapter 2.  I am going to re-comment the code to attempt to make more sense of it.

.. PROGRAM 2.3 — SLOW BLINK
..
0000    91      GHI   Set D(accumulator) to the to highest byte of register 1
0001    CE     LSZ    Skip the next two bytes if D=0
0002    7A     REQ   This turns the Q bit off if D doesn’t equal 0
0003    38     SKP    This skips the next command when D doesn’t equal 0
0004    7B     SEQ    This turns on Q bit if the long skip jumps past the short skip
0005    11      INC     Increment register 1
0006    30     BR      Jump back to the beginning
0007    00                 This is the target of the 30 command

The reason that the high byte is used because the low byte would equal 0 every 256th time the program loops.  This would cause you to never see the Q bit actually blink on the TinyELF emulator because when you cycle the Q bit that quickly, the emulator thinks you are trying to use the speaker that is also attached to the same line.  So when I set my memory address 0000 to 81 instead of 91, I get a super high pitched dog whistle sound coming from my speakers.

The long skip happens 1/256th of the time.  At the point the Q bit gets set to 1.  The program continues to loop and R1 continues to increment 255 more times but the high byte still equal to 0.  These 256 cycles happen so quickly that you barely get to see the Q bit flash before the high byte in R1 changes to to 01 and the short skip jumps past the 7B command.  The program has to loop 65,280 times before you get to see the Q bit blink briefly.

AHA!

I’ve been delving further into the subject of self-modifying programs on the TinyELF.  Take the program that I showed you in the last posting on the subject for instance:

0000    3F    BN4       Wait for you to press I

0001     00                   3F branches to THIS address if you don’t press “I”, if you do press “I”, it skips to the next address

0002    6c     INP 4    Take whatever is in the IN 4 buffer and put it into the next location in memory, then executes it

0003    00    IDL       It actually doesn’t matter WHAT you put in this spot since the 6C command will change it anyways

0004    00    IDL       after it 6C changes the previous bit, stop (or not depending on what input you send to the program)

Key in the program and then run it.  Type in 6C and then “I”.  So the program fills the memory ENTIRELY with 6C commands.  This is because 6C takes anything sitting in the “In 4” buffer and sticks it in the next byte but that’s not all.  It also RUNS IT!  So when you put in 6C, it still sees 6C in the buffer and then replaces the next byte and then runs that byte which is now 6C, rinse and repeat many, many times.

Now that the memory is filled entirely with 6C’s, re-key the first part of the program:

0000    3F    BN4      Wait for you to press I

0001     00                  3F branches to THIS address if you don’t press “I”, if you do press “I”, it skips to the next address

0002    6c     INP 4    Take whatever is in the IN 4 buffer and put it into the next location in memory

Now type in something like C4 and hit “I”.  If you remember from my last post, C4 is a “no op” command which just tells the computer to skip that byte.   I’ll let you run this yourself to see the output but it’s rather interesting.  See if you can guess what will happen by logical reasoning.

So far, the only command I find that overwrites the program itself is when you enter 6C.  There may be other ways but I’m not an assembly language ninja quite yet.

I’ve been tinkering some more in chapter 3 of Tom Pittman’s Short Course in Programming.  I still think the book is excellent but some of the concepts are starting to become a bit confusing.  For instance, when you take input from the hex keypad via the 6C INP 4 command, the next byte after that one gets modified if your memory protect is not enabled.  It seems this could make input sanitization a difficult task.  It also can make programs run unpredictably if you get a byte or two misplaced.  Of course that is the pitfall with assembly language in the first place.  To explain what I mean, enter in this program:

0000    3F    BN 4      Wait for you to press I

0001     00                  3F branches to THIS address if you don’t press “I”, if you do press “I”, it skips to the next address

0002    6c     INP 4    Take whatever is in the IN 4 buffer and put it into the next location in memory

0003    00    IDL       It actually doesn’t matter WHAT you put in this spot since the 6C command will change it anyways

0004    00    IDL       after it 6C changes the previous bit, stop (or not depending on what input you send to the program)

Now run the program and type in 6C and press the “I”.  I hope you are watching the memory contents window now because that’s crazy.   Re-enter the program and experiment with some other values.

I have absorbed a few other interesting things too.  First one that I like is the C4 NOP command.  No op simply skips to the next byte.  This is good for when you delete a command from memory but you don’t have enough room for a 30 BR LOOP followed by an address byte.

Next thing I like is the 64 OUT 4 command.  That command outputs to the hex display whatever is in the byte following the command.  For instance:

0000     64       OUT 4      This outputs the next byte to the display

0001      FF                         This will be output to the display

0002      00      IDL            Idle until further instructed

There are also other output lines but as far as I can tell, they are attached to anything in the emulator.