Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly

github.com

Post reply on HN
Print view View original

31–40 of 73 posts

Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly

#31

Post by DSMan195276 »

habosa wrote: post #12

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?

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).

Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly

#32

Post by nsxwolf »

"Floppy Bird is a clone of the infamous Flappy Bird written in 16 bit (x86) assembly.

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.

Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly

#33

Post by cyorir »

ekr wrote: post #21
anoxic wrote: post #17

Earlier quoted context omitted.

I think it really means floppy bird IS an OS, albeit one that can get nothing done but a flopping bird

No, it's not an OS by any means, as it doesn't provide a way to abstract computations (processes), doesn't provide support for file systems, etc.

That is a rather narrow (formal?) definition of OS. If instead you consider an OS to be (more generally) a collection of system-level software providing the interface between hardware and the userspace application, then in this case the sys code is the OS and the game code is the userspace. This definition is based on the idea that an OS manages resources and provides services - as opposed to the more rigid definition that an OS manages resources including processing time and storage space.

Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly

#34

Post by dllthomas »

nsxwolf wrote: post #32

"Floppy Bird is a clone of the infamous Flappy Bird written in 16 bit (x86) assembly. 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.

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.

Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly

#35

Post by vertex-four »

habosa wrote: post #12

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?

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.

Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly

#36

Post by bri3d »

nsxwolf wrote: post #32

"Floppy Bird is a clone of the infamous Flappy Bird written in 16 bit (x86) assembly. 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.

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.

Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly

#40

Post by drivers99 »

bri3d wrote: post #36
nsxwolf wrote: post #32

"Floppy Bird is a clone of the infamous Flappy Bird written in 16 bit (x86) assembly. 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.

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 i…

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 ports (for the PC speaker presumably).

In other words, it's using BIOS for input, but not drawing.

Post reply on HN