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.
Thanks for wasting 4 minutes of my life! For some reason, I picked up a Wyse Winterminal S50 from Weird Stuff last week... a thin linux client box from 2006 that has some sort of underpowered x86 and very little memory.
So I was playing with it and it has this weird linux on it that lets you set it up to very slowly browse the web and such, but it wasn't very interesting, all told.
When I saw this project come up, I grabbed the .img, wrote it to a spare usb stick and damn if the thing didn't just boot up to floppy bird. Nice work! Now I wonder what other dumb PCs I have sitting around that can boot it...
Turns out after you have written the floppy IMG to a blank
uFD or HDD, and it boots and plays the game, then you can
partition the drive (I used Linux Mint), format it as
FAT32 or NTFS, and use the full drive for mass storage
without a conflict.
Same drive still boots to Floppy Bird only, unless you
install some other OS or something which overwrites
the Floppy Bird bootloader on sector 0, and give up the bird.
Partitioning and formatting alone do not overwrite the MBR,
even if it is just a custom floppy boot sector at the time.
It's also not really running on "RAW METAL" because it's using BIOS interrupt routines for drawing and input.
It's still awesome, though, and the code is really cleanly written and easy to follow.
Because the code is so nice, this would be a fun project to try to port to Protected Mode with its own HAL and maybe drivers for one set of hardware (perhaps QEMU's). Could be a fun experiment in why OSes are hard and x86 is painful.
And in principle you can write in a higher level language and build for a target without an OS. In practice, you can certainly write the bulk of your code in C and only write (possibly) a little initialization and (possibly) some IO code in assembly - mostly inline assembly.
First 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?
No. ASM is just a slightly easier mnemonic version of the raw machine language. All software basically compiles down to this form.
The OS functions are provided here. The "game" is just an application in the OS (kinda). The BIOS provides whatever the OS needs to hook into to use the hardware. Here's a high-level overview of how this works http://duartes.org/gustavo/blog/post/how-computers-boot-up/
OS's don't need to be very complicated, just a few bytes in some cases depending on what you want to do. For example, you can just use the standard VGA modes (here, he's using 13h) to get something to display, and just write directly to the video memory. The BIOS helps handle some of the interface work to the various standard components.
This is the real old-school way of doing things and the code is really well done and commented. If you know x86 asm basics, you can read through most of the system-level stuff without too much trouble.
I think the Floppy Bird uses Real Mode[1], which provides an easy access to various devices directly through the BIOS. Practical opearting systems switch to protected mode, which provides more features, but doesn't allow you to use BIOS interrupts (and at that point you need to start writing device drivers).
Here, that layer doesn't exist. This program takes the place of the OS, and communicates with the hardware directly, without an OS in the way.
This can be done because ages ago, the PC hardware interface was almost completely standardised, and all PCs to this day implement that standard for backwards compatibility.
It's a Real Mode (16-bit) 'OS', very similar to DOS. When you run in Real Mode, the BIOS's provides a few hooks for doing some basic 'syscall' type stuff like changing the video mode, so you can get away with doing less in the actual OS code by doing it via the BIOS. That said, this code he has will run on any hardware that'll run DOS (for the most part).
If he did this via 32-bit assembly he'd have a fair amount more code to get things done (Though he still uses very little hardware anyway so he could get away with not setting up most stuff).
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. :)
If you write ASM that makes system calls, yes. If you write ASM that just talks directly to your devices, no.
For the latter, ASM isn't even strictly necessary outside possibly some narrow things that could (/should, if this was a "real" project) be inline assembly in a C program. Obviously, your C couldn't call any system calls and (depending on the runtime) might even need to forego malloc and similar.
I haven't looked at the code, but I assume this just uses the BIOS in your PC. The BIOS is a basic layer for talking to raw hardware, whereas Operating Systems normally are expected to provide many higher level functions (file systems, processes, virtual memory, etc).
I'm wondering: how hard would it be to add sound to this thing? I think it uses Piezo sound, which is probably easily addressed. But what about midi or PCM output? Would you have to target every manufacturer specifically?
I really liked how fast my computer "booted" into the game. I would totally start collecting games like these if there were a scene.
Assembly is about as nonportable as you can get. Hardware access (not exposed by other languages), speed, and possibly executable size are the practical reasons one would write in assembly. The second and third are almost entirely outdated - storage of executables is free relative to storage of data; hardware speeds have made "slow" programs plenty fast for most things; and compilers can do better than you can quickly do, very quickly. The first is still a valid reason to use assembly, but typically in the form of a small snippet of inline assembly in C/C++ code.
The person who wrote this wrote it to be booted directly from BIOS. That means it must handle everything an OS would otherwise do for it: bootloader, resource management, hardware access, random number generation, etc. So a project like this has great value as an introduction to low level systems and OS development.
I 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.
[+] [-] e12e|11 years ago|reply
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! :-)
[+] [-] agumonkey|11 years ago|reply
[+] [-] girvo|11 years ago|reply
[+] [-] salgernon|11 years ago|reply
So I was playing with it and it has this weird linux on it that lets you set it up to very slowly browse the web and such, but it wasn't very interesting, all told.
When I saw this project come up, I grabbed the .img, wrote it to a spare usb stick and damn if the thing didn't just boot up to floppy bird. Nice work! Now I wonder what other dumb PCs I have sitting around that can boot it...
[+] [-] danelectro|11 years ago|reply
Same drive still boots to Floppy Bird only, unless you install some other OS or something which overwrites the Floppy Bird bootloader on sector 0, and give up the bird.
Partitioning and formatting alone do not overwrite the MBR, even if it is just a custom floppy boot sector at the time.
[+] [-] nsxwolf|11 years ago|reply
In other words it works on RAW METAL and doesn't require an Operating System."
The second statement doesn't quite follow the first. You can certainly write a 16 bit x86 assembly DOS application.
[+] [-] bri3d|11 years ago|reply
It's still awesome, though, and the code is really cleanly written and easy to follow.
Because the code is so nice, this would be a fun project to try to port to Protected Mode with its own HAL and maybe drivers for one set of hardware (perhaps QEMU's). Could be a fun experiment in why OSes are hard and x86 is painful.
[+] [-] dllthomas|11 years ago|reply
[+] [-] spiritplumber|11 years ago|reply
Does it have a switch that lets the computer cheat?
http://www.catb.org/jargon/html/story-of-mel.html
[+] [-] ErikRogneby|11 years ago|reply
[+] [-] zimbu668|11 years ago|reply
[+] [-] habosa|11 years ago|reply
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?
[+] [-] bane|11 years ago|reply
The OS functions are provided here. The "game" is just an application in the OS (kinda). The BIOS provides whatever the OS needs to hook into to use the hardware. Here's a high-level overview of how this works http://duartes.org/gustavo/blog/post/how-computers-boot-up/
OS's don't need to be very complicated, just a few bytes in some cases depending on what you want to do. For example, you can just use the standard VGA modes (here, he's using 13h) to get something to display, and just write directly to the video memory. The BIOS helps handle some of the interface work to the various standard components.
This is the real old-school way of doing things and the code is really well done and commented. If you know x86 asm basics, you can read through most of the system-level stuff without too much trouble.
[+] [-] nawitus|11 years ago|reply
1. http://wiki.osdev.org/Real_Mode
[+] [-] vertex-four|11 years ago|reply
This can be done because ages ago, the PC hardware interface was almost completely standardised, and all PCs to this day implement that standard for backwards compatibility.
[+] [-] DSMan195276|11 years ago|reply
If he did this via 32-bit assembly he'd have a fair amount more code to get things done (Though he still uses very little hardware anyway so he could get away with not setting up most stuff).
[+] [-] phazmatis|11 years ago|reply
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. :)
[+] [-] dllthomas|11 years ago|reply
For the latter, ASM isn't even strictly necessary outside possibly some narrow things that could (/should, if this was a "real" project) be inline assembly in a C program. Obviously, your C couldn't call any system calls and (depending on the runtime) might even need to forego malloc and similar.
[+] [-] Jare|11 years ago|reply
[+] [-] Scuds|11 years ago|reply
The great 8-bit systems of the 80's - Apple II, C64 - booted their apps and games off of floppies all the time.
[+] [-] icebraining|11 years ago|reply
[+] [-] anoxic|11 years ago|reply
[+] [-] PhasmaFelis|11 years ago|reply
Although I admit this is more impressive than the usual "Floppy Bird only slightly different."
[+] [-] golergka|11 years ago|reply
[+] [-] michaelgrafl|11 years ago|reply
I really liked how fast my computer "booted" into the game. I would totally start collecting games like these if there were a scene.
[+] [-] zokier|11 years ago|reply
edit: for this project specifically there is the small problem that you probably need to enter protected mode for "modern" audio.
[+] [-] michaelq|11 years ago|reply
[+] [-] dllthomas|11 years ago|reply
[+] [-] cyorir|11 years ago|reply
[+] [-] ginko|11 years ago|reply
I don't see it being called anywhere in the Makefile.
[+] [-] sovok|11 years ago|reply
[+] [-] andrewstuart2|11 years ago|reply
[+] [-] Narishma|11 years ago|reply
1. http://en.wikipedia.org/wiki/PC_booter
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] sfeng|11 years ago|reply
[+] [-] carlsborg|11 years ago|reply
$apt-get install genisoimage $ln -s /usr/bin/genisoimage /usr/bin/mkisofs
builds fine after this.
[+] [-] NickWarner775|11 years ago|reply
[+] [-] edpichler|11 years ago|reply
[+] [-] nemasu|11 years ago|reply
[+] [-] gangster_dave|11 years ago|reply
[+] [-] 3327|11 years ago|reply
[+] [-] carlsborg|11 years ago|reply
[+] [-] wwhhyy|11 years ago|reply