akshat666 5 days 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

amiga386 17 hours 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) 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 14 hours 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.

joenot443 19 hours 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!

kragen 17 hours ago

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.

110111011110 17 hours 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!

mg794613 15 hours ago

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

Barry-Perkins 14 hours ago

Pong in 512 bytes — boot, play, amaze

anthk 19 hours 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/

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 18 hours 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 15 hours 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/

      • fl7305 10 hours 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 9 hours 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.