Due to time constraints, the most complex thing I've manage to do as far as console programming is an SNES demo that renders animation frames for a Mega Man object composed of multiple sprites and properly positions and flips them, using controller input to change frames and flip status.

Each frame consisted of a combination of 8x8 and 16x16 sprites, all extracted from NES Mega Man games and then hand recolored to increase color depth. It was rather slow going, however, as the sprite data for each frame had to be generated manually and embedded in a resource file; I just wanted to get something on screen, so I didn't bother with proper tool development. A planned, but unfinished, update would have used DMA to transfer just the tiles needed for a given frame to the PPU; the current implementation just DMAs the entire tileset in VRAM at startup, which unfortunately takes up about 1/2 the space available for sprite tiles...

I could have, of course, used a single 32x32 sprite for each frame instead; but that would have defeated the purpose of the exercise, which was to develop and test a sprite engine that could support composite sprite objects. It would have also complicated the "as-needed" DMA scheme, since the 4 rows of tiles wouldn't be contiguous in VRAM, requiring 4 transfers instead of just 1.

Before that, I made a minor adjustment to the sound driver for the original Final Fantasy that added support for "waveform envelopes" for the two pulse wave channels.

At some point I started on complete, accurate documentation for the NES and SNES, but wasn't been able to complete them due to time constraints. I also did some introductory work on an SNES emulator for PS2 Linux, but that was also dropped for time.

Quote:Original post by GilliganCoder
I have always wanted to find the original source code to the mario games to see how they implemented such functions as jumping and collision detection. SMB, SMB3, and SMW are the target games, and I'm assuming the algorithms improved from SMB3 to SMW, etc. Does anyone know where I could find the original source code, the disassembled source code, or the original assembly language code for any of these games? Any input is appreciated. Thanks.

Hey, I know this thread has been inactive for 6 days, but I just happened to be googling something nes related and this showed up. I am an old rom hacker and Basically I have the same interest in how Nintendo games work, only I've pursued it by disassembling and studying some of them. Quite a few of them I run through a custom debugger/emulator I helped create (the emu is called FCEUXD, just google it). Anyway, it absolutely fascinates me how they pulled tricks off on old hardware, and I have a strong academic interest in reverse engineering some of the games' 6502 code.

anyway, here is a link to a thread where someone is working on a much more complete commented disassembly of smb1
http://nesdev.parodius.com/bbs/viewtopic.php?t=2987

This fellow named snowbro disassembled and commented a few other NES games back a few years ago. here's a link to his stuff.
http://snowbro.moccamagic.com/

I have a lot more reassemblable disassemblies I have collected from friends, and some I created myself of lots of other NES games. You'll have to PM me to get those as they aren't hosted anywhere afaik. Also, if you PM me I might help you get started in using FCEUXD to disassemble and debug some of them.

Wow.

Did programmers feel ridiculously limited back then? Or was working around these limitations "all in a day's work"?

Quote:Original post by Daniel Miller
Wow.

Did programmers feel ridiculously limited back then? Or was working around these limitations "all in a day's work"?

considering the source takes up 8 KB,they've spent most of the time hacking.My guess is that an optimised-but-not-hacked version of the code can be made fairly quickly(the high level programming with C of similar games today takes several days at most).
I wonder what they were doing with the Atari 2600,there a game often takes <1KB ,and the console has just 128 bytes of ram.

Quote:Original post by Winterhell
considering the source takes up 8 KB,they've spent most of the time hacking.

Only the very earliest generations of NES games has so little code; later NES games had substantially more.

The original Mega Man, for example, has about 35 KB of code, including 2.5 KB just for the sound driver; Final Fantasy has about 50 KB of code.

Quote:
anyway, here is a link to a thread where someone is working on a much more complete commented disassembly of smb1
http://nesdev.parodius.com/bbs/viewtopic.php?t=2987

Not working on. Finished for several months now.

I just happened to have also written a thorough explanation of one of SMB's most infamous bugs, the Minus World. Here's the link:

http://www.geocities.com/deethefigurine/smbminusworld.txt

Hello, I've been studying the SMB source using both versions, one by doppelganger and the other by DarkCode (which was unfortunately incomplete).

Apologies to doppelganger if any disrespect is taken from what I'm about to say. - I only mean to be constructive. Having the entire SMB source commented is great, but the comments are just a bit on the excessive side. The commenting style was guilty of repetition of things that can be directly understood from the code. Example: "sta ScreenTimer ;set screen timer"

Also, another unfortunate stylistic choice: most of the variable and label names were overly technical-sounding, and as a result, unwittingly deceptive.

To clarify around an example, I found it difficult to deduce the meaning behind the OperMode_Task variable, when in another commented source it was called jmp_control2, which uses a much simpler nomenclature. It is simply harder to hold a variable in my mind when it reads as "Operating Mode Task" rather than "Jump Control 2". The lesson here is don't make things seem more complicated than they really are.

You should be recognized for your hard work, of course. Perhaps some day we can have an improved version. My project right now has become hacking away some of the unnecessary commenting, and simplifying the labels. I would like to learn a lot from this source code. I'm primarily interested in thinking about what the creative process of the development team might have been like. It is very helpful having every label named. It's like having a textbook about SMB. All it needs is to be analyzed and distilled, which I am attempting to do.

In my defense, I would just like to say that this was my first RE work ever.

Yeah, some of the names do sound a bit technical. I won't lie, this disassembly, as thorough and complete as it is, could only simplify things to a point. Super Mario Bros is pretty messy in the code, and I was more concerned about not pointing out enough rather than pointing out too much.

Having said all of this, I appreciate your criticism, it helps.

At the moment I am currently involved in another project, but if I have time, I will probably go over smbdis and see if I can't clarify some things that are still vague and unclarify the blatantly obvious.

I actually have given some thought to writing a "theory of operation" document that explains the whole program in detail in paragraphs, that would compliment the disassembly quite nicely.