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.
"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.
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...
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.
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!
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 :)
[flagged]
[flagged]