> Use your distribution's package manager to install WINE (e.g. apt-get install wine), then launch NES Screen Tool from the command line as above under "Mac"
This is something that I find rather off-putting about NESdev. It's very Windows-centric. I'm not used to GNU/Linux being treated as a second-class dev citizen, so I've started a small contribution towards fixing this. I've got a NES tile viewer that I hope will soon be a tile editor, written in PyQt for cross-platform aspirations:
I made Mac and Windows builds, but I'm not sure yet how best to pre-compile a Linux version that works across distributions - any advice would be appreciated. I assume users can install Qt on their own, so I don't need to do static linking, but I'm not sure what needs to happen beyond that.
I'm in the process of updating the parts of the book that are already there to use it instead of NES Screen Tool. Looking at a few replacements for FamiTracker as well, so no one will need to use WINE to do NES development.
Personally, I'm happy building from source, especially for niche software. Just give me a working CMake or Qt .pro file and I can figure out the rest. I in fact rather dislike pre-built binaries. I don't trust them to work well and I don't trust them to work for a long time if they happen to rely on libraries that one day change (even the most statically compiled of static binaries still usually rely on libc).
And if your software ever gets popular enough, I expect one day my distribution will just package it for me. I'm happy with this arrangement. Source for niche software, apt/rpm for well-established software.
For my own Qt project, I decided to use PyQt so I could leverage fbs for distribution for Windows where they're not used to source code (Mac can rely on homebrew, as far as I'm concerned):
This looks like a really nice introduction. And it looks like there's not too much to learn before writing basic programs for the NES (I could be wrong). A simple environment with static hardware makes it less intimidating to jump into.
Back in high school I started getting into Z80 programming on the TI-86 calculator. It was a great platform for learning. It wasn't too complicated to start making simple programs (you could even code directly on the calculator if you didn't mind inputting everything in Hex.) And it was an easy step to start doing graphics. This reminds me of that kind platform.
Sometimes I dream about getting back into ASM for fun. But I have so many other, more practical, things I'd like to learn (I'm not in software development). This is temping, though.
> And it looks like there's not too much to learn before writing basic programs for the NES (I could be wrong).
You're not! The whole thing is very easy to pick up, and there's a lot more documentation nowadays than it used to be.
It's also possible to write useful programs in C, rather than ASM, if you're into that. neslib ( https://github.com/clbr/neslib ) does pretty much everything you need. cc65 ( https://cc65.github.io/ ) is a little quirky but definitely usable.
> It's also possible to write useful programs in C, rather than ASM, if you're into that.
Have you done much of this? I looked into it a while back and it seemed like the style of C required was very much its own flavor. I'd been wanting to get some experience with Assembly, so I've been (slowly) coming up to speed with that instead.
I'm about 30% through such a project right now, and I have written C code for 6502-family CPUs in the past, although not specifically for the NES. I wouldn't say it's a lot of it, the way I wrote "a lot" of C code for x86, PPC or ARM, but I did definitely did use it to write more than trivial/one-off programs.
> I looked into it a while back and it seemed like the style of C required was very much its own flavor.
As far as cc65 goes, I think it's (mostly?) ANSI-compliant. There are a couple of quirks that you need to be aware of due to the underlying processor, but that's true of any machine. For example, the 6502 lacks native arithmetic instructions for 16- and 32-bit operands, so the compiler won't generate the same kind of code for adding uint8_t operands and adding uint16_t operands.
Then, of course, each compiler has its own quirks :). cc65 doesn't do micro-optimizations, for example, so a lot of the things that we're taking for granted in gcc or clang don't happen automatically in cc65. But that's also true of pretty much any compiler, or, well, at least it used to be true back in the day.
But if you look at the code... it's pretty typical C, I've definitely seen worse. It's possible to write cleaner compilers targeting a much wider subset of C for 6502 than, say, for the 8051. I have absolutely no fond memories about programming that damn thing, in neither ASM, Pascal or C :). Some programmers are a little too inventive for their own good and hide a lot of stuff behind all sorts of macros and whatnot but you can definitely write the kind of C code that would be merged into the Linux kernel if it had a 6502 port.
I don't have any numbers but a lot, if not most of the current crop of indie/retro games aren't written in ASM anymore, at least not on platforms with decent C compilers (NES, SNES, Amiga...). Some games (platformers, side-scrollers) have a sufficiently regular structure that you can write them in Assembly without cursing the day you were born. But games that are less linear than that, or that require even the dumbest autonomous AI that's just a branching instruction smarter than "fire at every 3 seconds, use special ability if player_health < 10", are pretty painful to build without higher-level abstractions. It's definitely possible, it's just that debugging high-level problems ("why is this enemy not switching from offensive to defensive spells when its health drops below 50") in a low-level language is generally above the motivation threshold for things you do on your own time.
Either way, though, knowing your way around Assembly is a good idea. First, touching some assembly code every once in a while is unavoidable. If you're writing games for old enough consoles, NES included, you do occasionally have to touch bootstrap code, and that's all LDA, CRN, HCF and ACDC. Second, most (cross) compilers that you can run today, whether modern or vintage and ran in an emulator, are orders of magnitude worse than gcc, clang or MS C/C++. The fact that compilers orders of magnitude worse than those can still be used to write entire programs is testament to just how good modern compilers are. But useful though they may be, they will still occasionally spit out really bad code, and while knowing enough Assembly to outdo the compiler isn't necessarily required, knowing enough to figure out when the compiler does something dumb and speculate on how to change your code to set it straight is really useful.
FWIW, I learned 6502 assembly first and I am, or I used to be, pretty good at it. Back when I first became interested in this topic, around 2002 or so, there weren't any good compilers available for free (cc65 was around but, as far as I remember, its support for the C64, which is what I cared for back then, wasn't exactly stellar. But I may be wrong, it's been a long time). But the tooling we have today is good enough that I rarely need to write any.
I'm a novice C programmer at best, so (warranted or not) that bit of flavor was enough to give me pause. I thought if I was going to make an investment in learning something new, that it might as well be something that I'd already been wanting to learn and would be useful elsewhere.
I totally agree with you that just because you _can_ write complex games in Assembly, that doesn't mean you should. I wasn't knocking using C to write NES games at all and won't claim to even begin to know how to address that scenario you laid out.
Anyways, your answer was interesting, informative and full of what sounds like hard won wisdom. Thanks for taking the time to put it together. If you're up to sharing the details, I'd be interested in checking out your games.
> It was a great platform for learning. It wasn't too complicated to start making simple programs (you could even code directly on the calculator if you didn't mind inputting everything in Hex.)
This was fairly annoying to do correctly, to be fair, so I mostly took it as a fun but not all-that-practical feature. It did make for a CTF challenge at iCTF one year, though :)
Famicom had educational games in East Asia I know Thailand has several Famicom clones with keyboards and joysticks to play educational games on it. Each one costs like $35USD and hooks up to a PAL TV.
The Commodore 64 had an advantage over the Famicom in that it could use cassettes and floppy disks to store the games on and could have them in BASIC or assembly.
Anyone who ever wondered why Excite Bike had that awesome track designer but no way to save tracks across restarts, it was intended to work with the FDS and on the Japanese version you could save them to a disk, if you had the peripheral. Learning that some years ago solved a minor mystery from my childhood.
I've often wondered why the software industry as a whole is so biased towards automotive and factory metaphors eg Toyota JIT manufacturing and nobody ever talks about the quality and joie de vivre of early video game software teams
There’s something to be learned from Toyota’s practices — the metaphor isn’t completely useless — but I think I agree that the auto manufacturing analogy has been stretched too far.
Making software is not at all like making a hundred thousand of the same car. It’s more like custom-designing a hundred thousand distinct cars, all with slightly-to-drastically different body shapes, colors, interior features, purposes, and customers.
I think this is what you're alluding to, but it is shocking how small some of the NES teams mentioned in this book are! The teams that made Donkey Kong and Mario Brothers were comprised of ~five people and only one or two of them were programmers.
Yes the teams were tiny and well dressed and working at the cutting edge of technology of the day building everything from the level of assembly
I'm telling you these are the people to emulate not the factory practices at the other Japanese company
Perhaps if building hardware it can be considered but the whole Toyota model is more about building a management structure around something that really doesn't need one
The biggest pain in the bum with early consoles like the NES is all the cartridge hardware you have to muck about with. I'm sure most of you reading this already know but the gist of it is that NES cartridges had their own special chips inside them that were there to improve the abilities of the NES over time.
Stuff like better scanline interrupts and Japan only sound chips (Due to changes to the cartridge port in the west) which you'll probably know about if you decided to listen to Castlevania 2/3's soundtrack on Youtube and found it different to what you remembered. The most common feature was to turn the character rom into a pseudo or even proper RAM so you could use way more graphics and tons of nifty techniques that made stuff better.
Anyway, from a quick sift through this looks like a good site and far nicer than a lot of console development sites.
(Sorry coranac, your site is a goldmine but the tiny font against that background gives me a headache)
this looks nice but after going thru the first part, I just noticed that the book is not only unfinished but also seems like the author may not be paying attention to it anymore... last blog post is over a year ago. Too bad.
This is something that I find rather off-putting about NESdev. It's very Windows-centric. I'm not used to GNU/Linux being treated as a second-class dev citizen, so I've started a small contribution towards fixing this. I've got a NES tile viewer that I hope will soon be a tile editor, written in PyQt for cross-platform aspirations:
https://hg.sr.ht/~jordigh/Tilerswift/
Development has stalled, but I intend to get back to it.