Show HN: Pong in 512 bytes (boot sector)

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

I would also recommend studying the entries of this old competition to learn some more sizecoding tricks: http://www.hugi.scene.org/compo/compoold.htm

pouet.net's many sub-1K demos are also worth inspecting.

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 :)

The winning entry, by Guillermo Sais, was:

    0000000: b003 cd10 95fa bea2 00b3 a068 00b8 07bf  ...........h....
    0000010: 6401 8d70 028d 02f6 75a6 80fc 0477 03f6  d..p....u....w..
    0000020: 5db0 d419 7520 287d d795 cd10 b409 ba34  ]...u (}.......4
    0000030: 01cd 21c3 506c 6179 6572 2031 2068 6173  ..!.Player 1 has
    0000040: 2077 6f6e 2e24 e460 a881 7813 7501 afd4   won.$.`..x.u...
    0000050: 05b0 f674 02b0 0a02 053c 8c77 0288 05b8  ...t.....<.w....
    0000060: db0a 99b2 00bf 000f b114 ab87 d7e2 fb26  ...............&
    0000070: 8134 fc0e 487a 9826 3800 7602 f7db b14f  .4..Hz.&8.v....O
    0000080: bada 03ec 33c1 2408 7bf9 e2f7 ebd4       ....3.$.{.....

looks like Oscar Toledo has kicked off a trend. :)

https://github.com/nanochess/bootRogue

https://github.com/Kharacternyk/dice-tower-os

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].

[0]: https://advent2019.overthewire.org/challenge-zero [1]: https://wiki.osdev.org/Bochs [2]: https://twitter.com/David3141593/status/1210363683815272448

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!

It's really cool!

But the opponent does the same thing and you can win every time ;)

Return the first ball from the lowest possible position. Then move to the highest position, you win!

I wonder if the latency is any better then if it would be running in a framework/stack!?

How was the web version created? Is it the same code compiled to WASM?

reminds me of https://en.wikipedia.org/wiki/Ping-Pong_virus