I didn't know that GB consoles didn't have a flat memory model. That was horrible to program with x86/DOS and must have sucked even more on a tiny hand-held.
"2. CPU
2.1 OVERVIEW OF CPU FEATURES
The CPUs of DMG and CGB are ICs customized for DMG/CGB use, and have the following features.
CPU Features
Central to the 8-bit CPU are the following features, including an I/O port and timer.
127 x 8 bits of built-in RAM (working and stack)"
How much memory is needed today to make games that are only half entertaining?
Great attitude. That's like saying people that program in ASM on graphical displays aren't real programmers due to not using the old punchcard system. Get over yourself.
Truly spoken like someone who has never written iOS programs. Some iOS programs are actually truly inspiring and I know of many people who haven't gotten into that market because it's too competitive (programming wise).
FWIW, I know my x86 assembly and am not an iOS programmer. But I have huge respect for good iOS programmers. Some of those apps are phenomenal.
The framework is glorious, the underlying user-base code can still be utter horse shit. Any programmer that doesn't know assembly is worth his weight in basic.
He's not claiming that someone who programs for iOS is a bad programmer. At all.
He's claiming that people who identify themselves as an "iOS programmer", rather than just a "programmer", aren't really programmers. A "programmer" might be able to write inspiring stuff for iOS, but they haven't pigeon-holed themselfs into being an "iOS programmer"
> I know of many people who haven't gotten into that market because it's too competitive (programming wise).
Or because it's a market where really awesome programmers can't distinguish themselves from good-enough average ones because few customers can discriminate between those.
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.
This 100%. It pangs me to see people call themselves .NET programmers or iOS programmers. You're either a general programmer or you're a class act. I know about 20 languages at this point and they all serve me well. You can bet you're going to need to know the hardware as well as assembly translation when you're not designing a stupid social app. Or well, don't learn assembly and continue to be mystified by the lldb debugger assembly dump in XCode, "that's just low level tundra tuft, lemme just close that and add some print statements..".sigh
i'm sure there are many talented .NET programmers who could quickly pick up assembly and become much more productive than you in that language... if they had a good reason to learn it.
That's not how it works. There's a reason unintelligent folk stick to one thing, it's because their aptitude does not stretch well across multiple venues. Programming is like chess, most good chess players play bughouse, losers chess, etc.. .NET is like sticking to 20min chess your whole life. You might get good with t but you have no dynamic range...
OP is referring to programmer in the same vein as someone refers to an 'artisan.' You wouldn't call someone an artisan if all they do is manage the inventory order from Baked-Cakes-For-Fakes. There are far too many 'programmers' who can't code their way out of a paper bag. If you don't know assembly you probably blow at debugging, and that's amateur.
ah, i can see how my comment could create confusion.
I was actually intending agree with you, to mean that the low-level programmers are precisely those individuals who achieve the time-to-market. They can wade through the specs and configure devices before the polished API becomes available.
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.
24 comments
[ 2.7 ms ] story [ 65.5 ms ] thread>>To download this document you must become a Premium Reader<<
EDIT:
http://www.romhacking.net/documents/544/
https://www.google.com/search?hl=en&safe=off&q=GameBoy+Progr...
The first link you posted allows you to download the file. Thanks so much for posting it!
"2. CPU 2.1 OVERVIEW OF CPU FEATURES The CPUs of DMG and CGB are ICs customized for DMG/CGB use, and have the following features. CPU Features Central to the 8-bit CPU are the following features, including an I/O port and timer. 127 x 8 bits of built-in RAM (working and stack)"
How much memory is needed today to make games that are only half entertaining?
You would be amazed what crazy and complex things were written to create some of the older games you know and enjoy.
http://www.otakunozoku.com/nintendo-gameboy-cribsheet/
FWIW, I know my x86 assembly and am not an iOS programmer. But I have huge respect for good iOS programmers. Some of those apps are phenomenal.
He's claiming that people who identify themselves as an "iOS programmer", rather than just a "programmer", aren't really programmers. A "programmer" might be able to write inspiring stuff for iOS, but they haven't pigeon-holed themselfs into being an "iOS programmer"
Or because it's a market where really awesome programmers can't distinguish themselves from good-enough average ones because few customers can discriminate between those.
I was actually intending agree with you, to mean that the low-level programmers are precisely those individuals who achieve the time-to-market. They can wade through the specs and configure devices before the polished API becomes available.
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