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