Strange choice of syntax to be seeing boot sector Asm in --- I didn't know GNU/AT&T assembler(?) could generate 16-bit binaries. Also looks to be a very beginner attempt since I immediately spotted lots of bytes that could be trimmed; if I was looking at disassembly and not the source, I might even mistake this for compiler output. A few more hints/suggestions:
- mov ax, 13h | int 10h will enter mode 13 in 5 bytes instead of 6
- this is x86, not a RISC. mov m16, imm16 exists.
- put the variables in memory after the code and initialise them literally
- use ALL the registers. I don't see a single bp or si
- the use of a few 32-bit instructions (but not 32-bit registers) is odd
One of the Hugi-compo rounds was a Pong game http://www.hugi.scene.org/compo/compoold.htm#compo3 to be run under MS-DOS; the winner was 142 bytes. However, there were several smaller entries that were disqualified for some cosmetic or lifecycle problems that didn't affect playability, the smallest of which was 67 bytes. The rules specified things including the paddle width, the text mode, the color of the ball, the win text, and the keys used to control the paddles. It seems likely that a smaller playable Pong could be achieved by relaxing the rules further — for example, by using different keys to control the paddles, or using a different starting ball position.
A boot sector doesn't have the MS-DOS interrupt services; it has to use only the BIOS interrupt services. On the other hand, it doesn't have to worry about exiting cleanly and resetting the video mode either :)
And to the OP: this is fantastic - how are you doing the in-browser demo? [EDIT: never mind! The body is `overflow:hidden` on that page so I initially didn't see the credits!]
I've starred the repo and am planning to lose a few hours to it this weekend!
I watched the YouTube video, and then read the source to try to figure out how he managed to get music in it too, but it turns out that was just the video...
The OverTheWire Advent Security CTF had one problem this year [0] which involved reverse engineering a (self-modifying) Master Boot Record binary similar to this which implemented AES-ECB-128, felt very rewarding to complete. I made heavy use of bochs [1] which seems to be the most common tool for emulating and debugging protected mode and bootloader code such as this. The creator of the CTF challenge talked about it on twitter as well [2].
This is great, I'm reading the heavily commented linux kernel source code and I was wondering how much can be done in the boot sector (other than call a more sophisticated boot loader) kudos!
pouet.net's many sub-1K demos are also worth inspecting.