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.
>> 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.
Oh yeah, I forgot to mention: “jz $+0x4” is I believe still a capital offence in many jurisdictions.
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.
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.
Would have also used a label, but for golfing in machine i think this notation is ok.
Arbitrary code execution was necessary to navigate entrance of government buildings starting in the 80’s.
I’m gonna write malware in QR format and print out fake restaurant and food truck menus
I don’t think there’re many x86 smartphones in the wild… 😅
What’s interesting, is that in the QR code itself, you can just about make out the face of a snake.
If it doesn’t scan on a phone why use a QR code?
I had the same question on my mind.
My conclusion was just because he/she/it can.
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…
Because your phone is only looking for a URL.
And it’s running an Arm CPU.
What would it do with x86 machine code?
You ever try typing code out of the back of a magazine? I would have dreamed of tech like this. It would probably scan on a laptop too, with the right software.
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.