Hacker News Reader

Comment by habosa | Hacker News Reader

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?

View on HN

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

1. http://wiki.osdev.org/Real_Mode

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

> Tiny nitpick: doesn't running asm still require an operating system?

The great 8-bit systems of the 80's - Apple II, C64 - booted their apps and games off of floppies all the time.

It might or might not require an OS; you can implement the hardware access code directly into the program.

True, you could leave out the bootloader and some of the sys code and this would then nearly be a DOS program, at least the port to DOS would be easy. Leaving it as is allows it to boot without an OS.

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.

Reply on news.ycombinator.com