Yes! Enjoying the assembly love recently. Awesome work!
Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
51–60 of 73 posts
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#52This is just beautiful: https://github.com/icebreaker/floppybird/blob/master/src/mai... Nicely structured code! I'm almost tempted to port it to amd64, just for fun. After all we really don't need any more x86/16bit example code, we need more amd64 code! :-)
I've been saying this to my co-workers over the past week as I've gotten into modern day assembly (ARM, but still): It's basically a high level language at this point! It's amazing how much structure you can actually give yourself with modern tools.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#53I would love to see a chart of when each of these ports came out. It would be a pretty interesting representation of the difficulty of building the exact same thing in various languages.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#54Floppy bird? Written in assembly, I half expected it to be called "Snappy Bird."
It's called like that because it's a booter[1], so it's loaded from a floppy disk at boot time.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#55First of all, this is really cool and I think the closest thing I have seen to 'readable' assembly. Tiny nitpick: doesn't running asm still require an operating system? I haven't read all of the code but I assume that there are instructions for I/O or other traps that require the OS. Isn't the OS just the layer between the hardware resources and programs that want to access those resources?
The BIOS has a lot of built in traps that, while minimalistic, make all PCs appear the same to you, the trap-user. This is the bare minimum to load an OS + drivers from disk, or run an OS installer, or turn your PC into a flappy bird arcade machine.
Come to think of it, "bare metal" would really be modifying your BIOS to contain flappy bird. Then you could draw to the screen directly. Too bad it would only work on one model of motherboard. :)
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#56This is just beautiful: https://github.com/icebreaker/floppybird/blob/master/src/mai... Nicely structured code! I'm almost tempted to port it to amd64, just for fun. After all we really don't need any more x86/16bit example code, we need more amd64 code! :-)
I've been saying this to my co-workers over the past week as I've gotten into modern day assembly (ARM, but still): It's basically a high level language at this point! It's amazing how much structure you can actually give yourself with modern tools.
any recommended resources?
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#57Earlier quoted context omitted.
> I meant "hardware access ([when the particular thing is] not exposed by other languages ... Ok, I agree. > Like I said, you cannot quickly do better than a modern compiler, and a compiler does it very, very quick. I'm not sure what you mean by "quickly" but this submission proves that it can be done in reasonable time. And if you look at the code (for example here: https://github.com/icebreaker/floppybird/blob/mast…
"it's obvious that you cannot produce anything nearly as compact and efficient with a compiler." It's not obvious. We can argue over what's "nearly", but without even trying, manually converting the assembly to C I get 71 (1.5x) instructions out of gcc and that includes an inlining of animatebird. The resulting code is otherwise not so far from the original. It certainly reads more poorly, but that's to human eyes no…
Well, on Android the original Flappy Bird was 894kb in size,
and this Floppy Bird is only 8.7kb.
Plus the 8.7kb includes enough utility code to obviate the need to load an OS for the game to run on top of, so the size ratio actually is better than the apparent 100:1.
The TAB key changes the bird's color scheme.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#58This is just beautiful: https://github.com/icebreaker/floppybird/blob/master/src/mai... Nicely structured code! I'm almost tempted to port it to amd64, just for fun. After all we really don't need any more x86/16bit example code, we need more amd64 code! :-)
I've been saying this to my co-workers over the past week as I've gotten into modern day assembly (ARM, but still): It's basically a high level language at this point! It's amazing how much structure you can actually give yourself with modern tools.
I'm not sure you really need much in the form of modern tools to achieve this -- the code base above is basically include macros and jump labels?
As mentioned by agumonkey, it feels a little bit like Forth.
In fact, I seem to recall a rather excellent tutorial on 68000 assembly featured very similar structure (even if I never finished it -- at the time I was defeated by my own bugs and the fact that those bugs, without an MMU or memory protection, could easily crash the entire machine. It was rather demotivating...).
For another example, see the original source of Apple II DOS, posted here a while back:
http://www.computerhistory.org/atchm/apple-ii-dos-source-cod...
Fundamentally I don't think the structure of the code is all that different? (Please correct me if I'm oversimplifying, or missing something).
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#59Earlier quoted context omitted.
vga.asm copies bytes directly to video memory in a raw manner, once it's in VGA mode. It only uses BIOS to switch into VGA mode ("mov ax, 0x13" and then "int 10h"), and back to text mode before rebooting when you quit. It does use BIOS to read the keyboard. It also reads bytes from sectors of the disk using BIOS rather than the OS when it starts up. The sound is a beep created with raw "OUT" commands on the data port…
ticks() and sleep() also use BIOS. The author could have implemented this by handling IRQ 0. :-) Come to think of it handling the keyboard interrupts isn't that hard either... Also looks like boot.asm uses the BIOS to read the rest of the program...
Seems like if the "boot.asm" (actually sector 0 of the floppy) could be made relocatable away from sector0,
then it could still be functional when stored in a filesystem (including on a HDD) not unlike BOOTSECT.DOS.
The remainder of the floppy (sectors 1 through 16 proper) when copied to the same sectors (which are normally blank
and unused) on a MBR/BIOS style HDD work just the same as from floppy without having to be in a filesystem
themself.
Then you could easily chainload to Floppy Bird on a HDD from other bootloaders (like WinNT5 & NT6), with no changes to the main ASM program.
EDIT: the comments in boot.asm refer to sectors 1 & 2 since they are the first 2 sectors of the floppy, these two are officially numbered 0 & 1 in a disk editor or DD command.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#60Earlier quoted context omitted.
"it's obvious that you cannot produce anything nearly as compact and efficient with a compiler." It's not obvious. We can argue over what's "nearly", but without even trying, manually converting the assembly to C I get 71 (1.5x) instructions out of gcc and that includes an inlining of animatebird. The resulting code is otherwise not so far from the original. It certainly reads more poorly, but that's to human eyes no…
Well, on Android the original Flappy Bird was 894kb in size, and this Floppy Bird is only 8.7kb. Plus the 8.7kb includes enough utility code to obviate the need to load an OS for the game to run on top of, so the size ratio actually is better than the apparent 100:1. The TAB key changes the bird's color scheme.
"Well, on Android the original Flappy Bird was 894kb in size, and this Floppy Bird is only 8.7kb."
You're actually making my point. Virtually the entirety of both those numbers is going to be image (and, on the Android version, audio data). Using lower-resolution assets is not something reserved to assembly language, and the size of the code is just not an issue next to that, most of the time. The biggest exceptions on desktops/servers being when executable makes the difference between spilling instruction cache and not. Things can get tighter on embedded, but there too tables and stuff are more often the cause of contention.
"Plus the 8.7kb includes enough utility code to obviate the need to load an OS for the game to run on top of, so the size ratio actually is better than the apparent 100:1."
Enough code to obviate the need for an OS (for this narrow use case, in Real Mode with BIOS calls available) is probably fewer bytes than enough metadata to convince Android to run you. But as mentioned, you're not actually comparing code size at all really.
"The TAB key changes the bird's color scheme."
I'm not sure what your point is here. Cycling palettes is a neat trick, but nothing new, nothing complicated, and certainly nothing that couldn't have been done as easily in another language.
Edited to add: Perusing your other comments, you seem to have plenty more savvy than your comment would show... were you trolling or trying to make some oblique point that I missed or what?