It’s Snake, In A QR Code, But Smaller

We’re not sure that many of you have recognised the need in your life for an x86 machine code program encoded into a QR code, but following on from someone else work [donno2048] has created a super-tiny Snake clone in assembly which comes in at only 85 bytes long. It fits far better in a QR code than the previous effort, but perhaps more useful is a web page demo which runs an in-browser DOS compatibility library. We followed the compilation instructions and got it running on our Manjaro installation, with the result of a somewhat unplayable but recognisable Snake, we’re guessing because it was written for a slower platform. The web version is more usable, and allows us to investigate its operation more thoroughly.

To achieve a working game in so little code is an impressive feat, and since we found different keys responded on machines with different keyboards we’re curious how it does its keyboard input. Also we think it has the Snake bug where turning back on yourself means instant game over. We would be interested to hear the views in the comments of readers who know something about x86 assembly, to help explain these points.

15 thoughts on “It’s Snake, In A QR Code, But Smaller

  1. >> we found different keys responded on machines with different keyboards we’re curious how it does its keyboard input

    The “iin al, 0x60” reads a keystroke. These are scan codes, and the codes for the arrow keys are as follows:

    UP = 0x48
    DOWN = 0x50
    LEFT = 0x4B
    RIGHT = 0x4D

    “and al, 0x1E” sets the parity flag if LEFT or RIGHT is pressed, and resets it if UP or DOWN is pressed. the JP instruction causes the next instruction to be skipped if parity is set, meaning either left or right is pressed.

    “and al, 0x14” clears the zero flag if DOWN or RIGHT is pressed, and sets it UP or LEFT is pressed. the jz causes the next instruction to be skipped if either UP or LEFT is pressed.

    The net result is that BX will have one of four different values depending on which key was pressed: 4, 160, -4, or -160. Since the display is operating in 80×25 text mode (2 bytes per character), this would be equivalent to moving left or right 2 characters (-4 or +4), or up or down 1 line (-160 or +160).

    It’s a clever way to distinguish between 4 different keys using only 2 tests. However, it’s going to return the same results for other potential sets of four keys on the keyboard, which could explain the behaviour you’re seeing.

      1. Why? that seems to be a simple conditional jump to a label (which is nothing more than a place in the byte code). If I remember correctly, thats 4 bytes _after_ the current instruction byte code.

        1. Because the fact that instructions can have varying sizes means it’s hard to tell where the jump is landing. It’s also easier to see the control flow when there’s labels.

    1. I hate the TV commercials that have QR codes at the bottom of the screen. Quick!!!! Jump up from your couch, grab your phone and scan our QR code…. Yeah like that’s gonna happen…

      1. I do not know how old are you, but I think we already had OCR on those days. That is a good technology plaged by akward to use software.
        I personally dislike QR because they are not readable by humans.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.