4 ms·

I wrote a Pong game in a 512-byte boot sector

104 points by akshat666 11mo ago

akshat666 11mo ago
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 https://github.com/akshat666/-bootponggame
- Tepix 11mo ago
  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/8204cf17c432cc2b968d138eb639494e https://gist.github.com/XlogicX/8204cf17c432cc2b968d138eb639... I think there are already at least two Pong game there.
  - akshat666 10mo ago
    Yes, 3 yrs but still fun. I have seen some games in boot sector. Its super cool.
- snvzz 10mo ago
  Challenge: `cpu 8086` rather than `use16`.
  - akshat666 10mo ago
    well well well
matsz 11mo ago
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 https://github.com/mat-sz/pongloader BTW: You could provide a live online demo using v86 - https://github.com/copy/v86 https://github.com/copy/v86
- akshat666 10mo ago
  That is a good demo right there. Any way to speed up the v86 on the browser ?
anthk 11mo ago
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/ 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...
- fl7305 11mo ago
  You could easily write a RISC-V CPU emulator for your older/smaller machines, and run the original Nethack code compiled to RISC-V.
  - anthk 10mo ago
    Under a 286? At time-freezing speeds. Minix 2 under a homebrew 16 bit CPU already was so-so in usability: https://homebrewcpu.com/ https://homebrewcpu.com/
    - fl7305 10mo ago
      I think it would be well enough for Nethack. Would be interesting if even a Z80 could run Nethack in a CPU emulator.
      - anthk 10mo ago
        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.
joenot443 11mo ago
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!
- akshat666 10mo ago
  Thanks Joe! This should fixed now :)
kragen 11mo ago
Possibly relevant is hugi-compo round 3, the "Pong" compo: https://www.hugi.scene.org/compo/compoold.htm#compo3 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/ 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.
- akshat666 10mo ago
  This is gold. so much to learn from this . Interesting to see how more limitations have curved the logic for each.
110111011110 11mo ago
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!
- akshat666 10mo ago
  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.
amiga386 11mo ago
"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 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?
- CrociDB 10mo ago
  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.
mg794613 10mo ago
Tomorrow it's my turn to pretend to have written this!
- akshat666 10mo ago
  Good luck with that :)
Barry-Perkins 10mo ago
[flagged]
Andrew-Tate 10mo ago
[flagged]
deleted 10mo ago
[deleted]

104 points by akshat666 11mo ago

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 https://github.com/akshat666/-bootponggame

Tepix 11mo ago
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/8204cf17c432cc2b968d138eb639494e https://gist.github.com/XlogicX/8204cf17c432cc2b968d138eb639... I think there are already at least two Pong game there.
- akshat666 10mo ago
  Yes, 3 yrs but still fun. I have seen some games in boot sector. Its super cool.
snvzz 10mo ago
Challenge: `cpu 8086` rather than `use16`.
- akshat666 10mo ago
  well well well

matsz 11mo ago

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 https://github.com/mat-sz/pongloader BTW: You could provide a live online demo using v86 - https://github.com/copy/v86 https://github.com/copy/v86

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

anthk 11mo ago

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

fl7305 11mo ago
You could easily write a RISC-V CPU emulator for your older/smaller machines, and run the original Nethack code compiled to RISC-V.
- anthk 10mo ago
  Under a 286? At time-freezing speeds. Minix 2 under a homebrew 16 bit CPU already was so-so in usability: https://homebrewcpu.com/ https://homebrewcpu.com/
  - fl7305 10mo ago
    I think it would be well enough for Nethack. Would be interesting if even a Z80 could run Nethack in a CPU emulator.
    - anthk 10mo ago
      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.

joenot443 11mo ago

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!

akshat666 10mo ago
Thanks Joe! This should fixed now :)

kragen 11mo ago

Possibly relevant is hugi-compo round 3, the "Pong" compo: https://www.hugi.scene.org/compo/compoold.htm#compo3 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/ 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.

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

110111011110 11mo ago

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!

akshat666 10mo ago
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.

amiga386 11mo ago

"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 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?

CrociDB 10mo ago
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.

mg794613 10mo ago

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

akshat666 10mo ago
Good luck with that :)

Barry-Perkins 10mo ago

[flagged]

Andrew-Tate 10mo ago

[flagged]

deleted 10mo ago

[deleted]