nesdev.org

olddb wrote:Wait! Tepples programmed HH86?

Yes, and its prequel + other titles. I believe he was contracted (read: paid) to do it, but that doesn't really matter (if anything, just goes to show there's still a market for such programming work, even now.)

If I'm doing programming work, even at my day job, I basically run VS Studio and maybe the email client, and the debugger. That is about all I need to actually do my job. Back in the 80s I wouldn't have had an email client, we would have just talked to each other, but seeing as the game team was 8 people for a really large team, not such an issue. Back then asm code editors where not that complex so they didn't take ages to load. That being said the Amiga 1000 brought us Multi-Tasking in 1985, although most people think it is something Windows 95 bought the to the table. But you could also get OS/2 that would let you multitask Windows 3.1. I think SunOS was multitasking and SGI IRIX was as well by the late 80s. Assembling 6502 with Macros on a PC is not that slow. I mean when you assemble on a C64 it took 4mins, on a 286 (1982) it took 40 seconds. When a SNES game took more than 30 seconds to assemble I know a programmer who went to IT and said "This game is taking 30seconds to assemble, that is too long, I need the new 486 SX 33" and they agreed and all the programmers got it.

Debugging was not that great. You can step 6502, its kind of slow on actual hardware see the PDS, but then emulating the chip on the host machine became faster. This lets you trap logic bugs, but if a sprite is showing the wrong data, if the bug is caused by timing, or interrupts you just have to stare at your code, make a guess and test it. This is known as Black Box Debugging. Now with emulators you can step clock by clock and see exactly what happens, look at VRAM etc It makes development a lot faster. Back then you would also print out your source code ( it was called a backup ) and sit there with a pen and manually trace it with values to find your logic flaws.

I feel the biggest boost however is the internet. Now I have some random bug, then I can post here, and get feed back, there are in depth docs. If I want to look up some Random number generators or fancy maths I just google it and get a working and tested example to copy paste Back then it was you and what ever books you could afford.

Hey, this is me! I was going to post something here eventually, but not until I had much more content.

The "1985-style" was intended to mean "using assembly", vs. compiling from C or some other language. I can see how it's confusing, but when I talk to people who have no idea how NES games are/were made, they assume I'm talking about making modern games that look like NES games.

I started learning NES development a few years ago using Nerdy Nights and kinda hated it. I spent a lot of time lurking these forums and reading articles on the wiki, and eventually it started to make sense. Since then, I've given some tech conference talks and workshops. I started writing this book because I wanted to make it easier for someone new to everything to get started - there is a huge amount that you need to learn before you can dive in, and you can pick it all up from the wiki but the wiki doesn't have any kind of "path" to teach you.

I'm planning to eventually work this out into building a whole basic platformer, with MMC3 scanline IRQ and bank-switching, but I think that's a long, long way off.

Please let me know if I've made any huge errors in the book, I want this to be as accurate as possible. None of this would have been possible without nesdev.com. I'm hugely grateful for everything this community has put out into the world.