Famicom Party: Making NES Games in Assembly

https://book.famicom.party/

by ingve • 6 years ago

129 29 6 years ago

book.famicom.party

swimfar• 6 years ago

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.

sighup1• 6 years ago

Tempting indeed, bookmarked for now, will take another look for sure.

saagarjha• 6 years ago

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

shultays• 6 years ago

Accessing ppu (graphics chip of NES) is a bit convoluted but yea, probably easier than more sophisticated hardwares.

alxlaz2• 6 years ago

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.

ethagnawl3• 6 years ago

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.

cable2600• 6 years ago

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.

hnlmorg• 6 years ago

The Famicom had a floppy disk drive too. I've got one and a few games on floppy like Zelda.

https://en.wikipedia.org/wiki/Famicom_Disk_System

karatestomp• 6 years ago

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.

Annatar• 6 years ago

"HN" dearly needs such books, about assembler coding for all kinds of hardware.

AnkiManki• 6 years ago

Definitely.

snvzz• 6 years ago

Absolutely. Imagine if they were to learn how to do something else than webdev.

dr_dshiv• 6 years ago

News article from 2009 on the project to turn cheap street NES clones into educational computers.

https://www.wired.com/2009/03/12-computers-ba/

artsyca2• 6 years ago

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

ftio• 6 years ago

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.

ethagnawl3• 6 years ago

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.

artsyca2• 6 years ago

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

jordigh3• 6 years ago

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:

https://hg.sr.ht/~jordigh/Tilerswift/

Development has stalled, but I intend to get back to it.

jeffalyanak2• 6 years ago

I forked TM so it could be built on a modern system. It will run well on any *nix system.

https://github.com/JeffAlyanak/tile-monster

jordigh3• 6 years ago

Was this previously called Tile Molester? (ugh, these names)

busterarm• 6 years ago

Even the ones that are Linux-centric really are mostly Ubuntu-centric.

Nobody seems to care about portability anymore.

famicomparty• 6 years ago

Good news, there's a project that ported NES Screen Tool to cross-platform Qt, called "NESTool":

https://github.com/jpwhiting/nestool

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.

jordigh3• 6 years ago

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

https://build-system.fman.io/

AnIdiotOnTheNet• 6 years ago

but I'm not sure yet how best to pre-compile a Linux version that works across distributions - any advice would be appreciated.

I like AppImage. Self-contained portable application bundles that should work on most Linux distros.

https://docs.appimage.org/packaging-guide/index.html

TeaDude• 6 years ago

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)

synestematic• 6 years ago

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.

Famicom Party: Making NES Games in Assembly

Related Stories