BOX-256: a tiny game about writing assembly code to pass the graphics tests

8 bit palette means trying to match the colour against 256 possibilities instead of 16.

I just had to make a quick mockup of hardware version of BOX256: http://i.imgur.com/Vw1i459.jpg

Could you build OS X version too, please?

Probably a driver issue. Firefox 45.0 supports WebGL, but it may be disabled on your machine if it can't find a suitable OpenGL driver. For reference, the site worked fine on my Ubuntu 15.10 machine, Firefox 45.0, Intel GPU.

There will be more levels in few days.

Real x86 is very different; you have limited registers (especially 32bit x86), very weird variable length instruction encoding, gazillion different instructions, memory access takes significant amount of time. Of course having near infinite amount of memory compared to the 256 bytes of BOX256 changes the way you program your code too.

The manual implies that's a limitation of the Unity WebGL player, but works in the standalone version.

Checkerboard: 0x24 cycles. http://imgur.com/C1UeEdn (EDIT: 0x16, see below)

My key insight was twofold:

1. If you start every thread at 0x00 and make the first N commands "THR @00", you get 2^(n+1)-1 threads running by the time your first thread exits the chain of THR commands.

2. You can use a single array MOV instruction to set a range of program counters, effectively causing every thread to jump to a set position.

So in the first 5 cycles I start 31 threads, then my main thread drops into a loop where all it does is set every thread's position (including its own) to a start point every 2 cycles. Every single thread is now a 2-cycle loop with no JMP cycle spent to return to the start each time. Then I simply make 16 loops of:

  PIX counter color
  ADD counter 1 counter

with color being one of two memory positions, which the main thread swaps out each loop. I initialize counter such that each thread is doing its own row of the output (0, 10, 20, etc). The leftover threads I don't actually want (but it's hard to fine tune the thread count, so I left them in), so they share the first thread's loop. The repeated actions are effectively a noop.

Note that, due to space constraints, I use the unused 4th byte of each PIX instruction as the counter for that loop.

Doing this got me to 0x24 cycles. I shaved a further 4 cycles by using the leftover space to add 4 more loops. These ones run vertically and operate on the last two columns (two threads doing one column together). By the time the row-moving threads have reached the 2nd last column, the column-moving threads have finished the last two columns, and so the program is finished 4 cycles earlier.

I think I could get another 2-cycle saving if I fine-tuned the number of threads started, compressed everything down again and got another two column-moving threads.

The bigger improvement is converting the whole thing to 1-cycle loops instead of 2-cycle, and having half the loops incrementing the counters and the other half doing PIX instructions. This might just be possible in the available space if I've run the numbers correctly, and would result in a total time of 0x14.

EDIT: Did the latter: http://imgur.com/zD1Gw5H

It came out to 0x16, as I failed to account for the extra time to spin up more threads.

Solution for square: spawn threads, distribute PIX instructions for each pixel evenly across threads.

Checkerboard and 4 Squares: http://imgur.com/a/dJRhM

Not sure how you would integrate that sort of thing to the ISA though. Maybe something like:

    00 THR 004 001 @A0
    04 JEQ 001 @A0 010
    08 --- parent thread
    ...
    10 --- child thread

where THR instruction would store a value that is visible only to child in some memory location, in this example value 001 would be stored at @A0, which is then used to distinguish the threads in a conditional jump.

It's really ungainly to work with -- but it does drop the cycle counts to solve the problems by running more threads.

Yes, in a few days hopefully