Built this as a personal challenge. No OS, no drivers — just x86 assembly and BIOS. 512 bytes exactly. Boots in QEMU.

Run it: nasm -f bin pong.asm -o boot.bin qemu-system-x86_64 boot.bin

GitHub: https://github.com/akshat666/-bootponggame

Nice! So you wrote this three years ago according to the git timestamps?

You can add it to the list at https://gist.github.com/XlogicX/8204cf17c432cc2b968d138eb639... I think there are already at least two Pong game there.

Yes, 3 yrs but still fun. I have seen some games in boot sector. Its super cool.

Challenge: `cpu 8086` rather than `use16`.

well well well

Possibly relevant is hugi-compo round 3, the "Pong" compo: https://www.hugi.scene.org/compo/compoold.htm#compo3

I spent three days disassembling Guillermo Sais's 142-byte winner, which was challenging to understand. My notes may be of interest; they are in gsais-pong.md in http://canonical.org/~kragen/sw/pavnotes2.git/

I hope this is not interpreted as any kind of criticism. I would much rather be responsible for maintaining Joshi's code than Sais's. But I suspect that most people who are interested in either work will be interested in the other.

This is gold. so much to learn from this . Interesting to see how more limitations have curved the logic for each.

"No operating system. [...] Just [...] BIOS". Hmm.

Out of interest, is there a difference in environment between running a COM executable for MS-DOS versus running a bootblock? I know there's the whole of MS-DOS, but a typical size-coded demo (http://www.sizecoding.org/wiki/DOS) will only use int 10h to switch mode, and that's it. Everything else is IO mapped (e.g. the keyboard) or memory mapped (e.g. screen memory). Could these equally run as a bootblock, and vice-versa?

One difference I know of is that DOS maintains an ever-increasing timer that it writes to 0:046C... is that available at bootblock execution time?

As far as I know yes, but with some minor changes, like the the position to be loaded in memory (`org 0x7c00` for bootloaders and I think `org 0x100` for DOS) and the fact that it needs to be exactly 512bytes to boot.

This is cool!

BTW I checked out your Github and tried the link to your personal site - looks like the www prefix isn't working.

www.akshatjoshi.com fails but akshatjoshi.com works. Gotta fix those A records!

Thanks Joe! This should fixed now :)

It's probably one of the best introductory projects to x86 assembly on bare metal.

More advanced than my attempt: https://github.com/mat-sz/pongloader

BTW: You could provide a live online demo using v86 - https://github.com/copy/v86

That is a good demo right there. Any way to speed up the v86 on the browser ?

Now that I see this, I'd curious if something like Nethack 3.4.3 or Slashem could be rewritten in T3X0 and be playable under 286 machines:

https://t3x.org/t3x/0/

There's a working Rogue port for Minix2 under a 16 bit CPU (and for the Z Machine too, and GBA, and several others...), but I think even Hack 1.0.3 would be too big to fit under a 286 with 640k.

It would be a good start if Nethack 1.3d got working under CP/M for instance, rewritten with T3X0 and some ASM hacks for speeds...

You could easily write a RISC-V CPU emulator for your older/smaller machines, and run the original Nethack code compiled to RISC-V.

Under a 286? At time-freezing speeds. Minix 2 under a homebrew 16 bit CPU already was so-so in usability:

https://homebrewcpu.com/

I think it would be well enough for Nethack.

Would be interesting if even a Z80 could run Nethack in a CPU emulator.

Nethack 1.3c, maybe. The first release, I mean, the inmediate one after Hack 1.0.3 under BSD's. That with a lot of patience. Nethack 3.4.3... I doub't it even DOS could handle it with 640k and a 286.

always facinated by these.

some ideas: - could try to add another player. just need to map 4 more keys. IO should be fine doing it the same way (dont think itd need thread or whatever) the io is super fast in the qemu scenario.

- rather than have this in the MBR. make an MBR where you can select this sector to load as next sector and jump, maybe even with ability to return. *you can then expose other games too if ud ever be bothered for snake or minesweeper :D

just some tinkering ideas. cool project and hats off. its always more tricky than it looks these things!

Very good suggestions. Making it a bit modular and flexible. Initial idea was to avoid any jump like a kernel etc. But very good points.

Tomorrow it's my turn to pretend to have written this!

Good luck with that :)