Does anyone know why GIMP is listed as a build dependency?
I don't see it being called anywhere in the Makefile.
Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
11–20 of 73 posts
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#12First 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?
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#13Earlier quoted context omitted.
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 quickl…
Well, in the embedded system field Assembly is still pretty much used everywhere, I think you are talking about doing asm for the regular PC. http://spectrum.ieee.org/static/interactive-the-top-programm...
Does anyone still use assembly for embedded? Of course. Is it a good idea? For some of them, and for the reasons I listed (I suppose I should add "you are working on a legacy assembly codebase").
"Still used pretty much everywhere" is just not the case anymore, even in embedded. At least, that's what the chart seems to say and it matches my experience working alongside embedded developers, knowing some embedded developers I've never had the pleasure of working alongside, and doing a small amount of embedded work myself.
(Edited to remove: Right in that link, both C and C++ are used more than assembly in the embedded space, and Arduino (more C/C++) follows closely behind assembly. The chart is unclear, but the rankings seem to be based on numbers that don't change when different filters are applied, which would mean that it does not show this. It is still certainly consistent with "assembly no longer dominates embedded", though - some of the C and C++ will be embedded, and all of the Arduino will be embedded.)
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#14great work always looking forward to seeing amazing examples like this on HN. Thanks you
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#15First 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?
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.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#16First 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.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#17First 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?
I think it really means floppy bird IS an OS, albeit one that can get nothing done but a flopping bird
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#18This is really cool. Is there a practical reason why you would write a game in assembly (speed? portability?)
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.
As someone who has written no-os code, you do not need to do everything the OS does. If you do not mind giving up most of your RAM, you can stick to realmode and take advantage of the BIOS functions (you can work around the RAM limitation by jumping between modes). If your computer has UEFI, you have access to a much more advanced set of functions, and (for many purposes) can target that. I haven't done anything beyond hello world type stuff on UEFI, but it feels like you can get alot done without noticing the lack of an OS.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#19First 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 might or might not require an OS; you can implement the hardware access code directly into the program.
Re: Floppy Bird: A Flappy Bird clone in 16-bit x86 assembly
#20First 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?
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).