GameBoy Programming Manual

I couldn't download it from Scribd either without paying. A 9 dollar one-day pass... don't think so.

The first link you posted allows you to download the file. Thanks so much for posting it!

I'm really surprised Scribd seems to have had little public trouble with copyright.

I used to find myself there all the time for various hard to find and not for public consumption automotive docs. The site was full of obviously infringing content.

This post seems to have been inspired by a comment I made yesterday with the original PDF （　´_ゝ`）

https://news.ycombinator.com/item?id=6119347

http://chrisantonellis.com/files/gameboy/gb-programming-manu...

I like that you said you are an "iOS programmer" that's the problem with programming today. you are not a programmer. if you were a programmer, you would be able to make sense of that document. so to answer your question, 20 years from now, programmers of that era will be able to make look at iOS programming docs and understand it, meanwhile "20 year future language programmers" won't. I say this because I learned gameboy programming in my first year of college (1997) by learning z80 and reading gameboy programming text files that were probably around 5 pages. that low level programming, till today serves me well.

From what I gathered (8bit era cpu, console hardware videos) the concept of programming has virtually evolved. Nowadays you use general languages to interact with a system or set of virtual devices (iOS, its subsystems etc) meanwhile in the GB era the system was a set of concrete hardware chips connected by buses and you used mnemonics to orchestrate them (by low level byte messages). My conclusion is that you don't understand because it's a very alien looking framework. I'd also bet 5$ that in 20 years the changes won't be as dramatic as the 80s-00s shift.

I think this document nowadays is more catered to embedded or micro-controller programmers. When the document was released it was common to get close to the hardware and probably most people had some experience/exposure nowadays not so much

Unless you know low-level programming, you're not really a programmer -- at least not one that won't commit a whole host of errors and mistakes. Know your hardware, know your assembly, know your C, and know your higher level languages and frameworks. Being ignorant to the base layers is sloppy, mate.

What has changed over time are the constraints. Nowadays if you want to store a number you can just do so. NSDictionary deals with mappings. You can just serialise data out and back again. You don't need to worry about memory until a crash says you are using too much, at which point Instruments points the finger. You are unlikely to encounter most boundary conditions in your code (I don't remember the last time malloc-equivalents returned no memory).

Back in the "olden" days, storing a number required thought. 8 bit processors could often deal with 16 bit values, but beyond that you were on your own. You had to be very careful designing your data structures so they used the least memory possible. Saving data was unreliable. There were often no debugging tools at all. Some lucky folks had ICE[1] but most of us had to guess why the system hung. All this meant you had to get low level because of the constraints.

But you know back in those olden days we didn't have to have a comprehensive help system. We could assume users were proficient. We didn't have to deal with security and attacks. No networking. Undo was rare, and if it existed was a single step. Your code only ran in one human language. So while we did have to care about the low level implementation details of the code, we didn't have to worry too much about the rest.

The low level constraints are pretty much gone now. The tools are great. And you do have to worry about a lot beyond the actual implementation like usability, smooth animations (games had to worry about that in the olden days but in a different way), multiple languages, coordinating with other systems over a hostile network, attacks and a whole bunch more. I'm glad for all this, because worrying about fitting data structures and a framebuffer in 16kb of memory didn't make for a better app.

Being familiar with the low level is still sometimes helpful, but not that often. It is also a heck of a lot more complicated - eg compiler produced code is not straightforward and logical. Multiple levels of cache, cache policies, speculative execution etc make reasoning about data more difficult. The majority of the time it doesn't matter.

Right now the majority of mobile apps behave rather poorly if you have more than one device. In the future that will be a given. UI is more likely to be goal driven with the system figuring best practises for meeting the goals, versus nudging things by pixels as is done today. (Heck a user will probably do some combination of pointing, speaking, thinking and just plain old looking.) I'd expect a more functional approach where immutable states are the unit of an app, and new states are produced via interaction and external updates with the states syncing across everywhere relevant instantly.

[1] http://en.wikipedia.org/wiki/In-circuit_emulator

As I understand CS, it deals a lot with Data structure construction and management.

In my school, we began with high-level functional languages and it's only after 3 years of programming than we discovered low level programming and could write a Kernel.

Can you explain how a RISC assembly language can help you learn CS ?

I've really been wanting to get into GBA programming. I really would like to buy a cart to be able to develop directly on my DS ( I thought I would be able to find one in Akiba, but they seem a bit impossible to find in person, and all the online stores I've seen seem mega shady)

x86/DOS actually was much nicer than most consoles, as it had a 20 bit address space. All memory in the machine could be addressed, even if you had to juggle NEAR and FAR pointers.

The 8/16-bit consoles could only address 64k, which was to be used for program, data, VRAM and memory-mapped I/O. So you were forced to partition your code and data in 8k or 16k banks and manually swap them in and out. If bank 1 was swapped in, there was no way to access bank 2...

Right - everything has to be a sprite. That way you can represent the screen with something like 360 (20x18) sprites, instead of 23040 (160x144)) pixels. The sprites are also done by blitting hardware, the Z80 CPU presumably couldn't update a 160x144 screen at a playable framerate if it had to update pixel by pixel.

Of course modern games use more memory as they are running on completely different platforms. Memory usage has nothing to do with entertainment level. A 8-bit Chess Game might be as entertaining to someone as is Call of Duty 26 to someone else.

(Game boy has 8192 bytes of working ram. 127x8 bits is only for stack)

Not particularly... The game boy's processor is more like a i8080 than a z80. It lacks the second register set used for interrupt handling and the iX and iY registers and the super-sweet addressing mode they enable.

Game boy assemblers do use the z80 syntax rather than the crazy i8080 syntax, thankfully.