Leftover code in games

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems.

Moderator: Moderators

User avatar
Bregalad
Posts: 8036
Joined: Fri Nov 12, 2004 2:49 pm
Location: Caen, France

Leftover code in games

Post by Bregalad »

I found it fascinating several games actually have uncompiled code in their unused secitons of ROM !!
http://tcrf.net/Category:Games_with_leftover_code
How can programmers make such a leak ?

Anyways, on the interesting things (for us) :

1) Air Forteress (J)

It's interesting apparently they call $2006 "vrad" and $2007 "vrdt", I guess for VRAM address and VRAM data.
You also see some pre-processor directives, like .ifn and .ife
A bit later you see that, very likely, $2000 is called CTLR0, and the variable where they store what they write to $2000 (which I usually call M2000 in my code) is called CR0.
Finally I must say the labels and comments are very weird. It almost looks like disassembled code sometimes. I sure doesn't wish to program like this, it would make the code extremely non-maintainable.

2) Dragon's Lair (J) and (E)

Has probably the biggest piece of leftover code ever ! It's well known for being a pretty horrible NES game too, so we can have a good counter example about how NOT to code a game. :D

We can see how the split their pointer tables into low and high componant, as we all (should) know it's more efficient this way. Apparently the assembler they used uses DL for what would be .db <xxx and DH for .db >xxxx

Apparently they use '!' for local labels.

They use hardwired addresses like $200 to setup their sprites, apparently they use a sprite zero hit. Shame on them :wink:

They use the word "attribute" so apparently attribute tables were actually called like this.

Their temporary variables are called ZPAGE_BYTE[n] Doesn't sounds very friendly to code this way.

Apparently they use macros for several kind of stuff, like ADD16

Their banks were apparently programmed in reverse order as we can see here :

Code: Select all

; End of bank $39
; --- -- ---- ---
;======================================
; Start of bank $38
; ----- -- ---- ---

	ORG	$138,$8000
Apparently they were using MS-DOS, and the same PDS environment that was used for Ian Bell's tank demo as I can conclude from this :

Code: Select all

; End of bank $30/$31
; --- -- ---- -------
;======================================
	IF	EPROM=99
	SEND COMPUTER1
	ENDIF
	IF	EPROM=98
	SEND MSDOS,"C:\PDSMAST\DLAIRFCS\EPROM\DL.PDS"
             	ENDIF
3) Robin Hood

Apprently they used .chr files :)
They used structure-like syntax with dots in their labels. This is really elegant in fact !

4) Secret of Evermore

Okay it's not NES it's Super NES and there is nothing much interesting other than the game was written in C instead of assembly !

5) Zig Zag Cat

Also Super NES, this time it's in assembly. Also it looks more like 6502 assembly than 65816 to me. They also use the ! for local labels, which means it's probably PDS too.
User avatar
rainwarrior
Posts: 8062
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Leftover code in games

Post by rainwarrior »

Sticking source code in the ROM is the weirdest thing. Very interesting.
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Re: Leftover code in games

Post by Shiru »

Sticking the source code is accidental, seemingly it was common for cross dev systems with disc drives. Guess they were allocating disc space for binary files without erasing it, without writing full content. I seen that even in an russian arcade game from 1980s, for an arcade machine.

Funny that these days it happens with AVI files in torrent clients. They allocate disk space for the whole file, and if there used to be an erased video file on the same disk, when you trying to open the file that is not finished downloading yet, chances are that you'll see pieces of the erased video.
User avatar
MottZilla
Posts: 2835
Joined: Wed Dec 06, 2006 8:18 pm

Re: Leftover code in games

Post by MottZilla »

The famicom Final Fight 3 pirate original had a bunch of source code in it too as I recall. It is interesting. But then again Ninja Gaiden apparently has an unused copy of the script in it.
User avatar
Bregalad
Posts: 8036
Joined: Fri Nov 12, 2004 2:49 pm
Location: Caen, France

Re: Leftover code in games

Post by Bregalad »

I noticed the script in plain ASCII in Ninja Gaiden but I was sure it was used ! Then where is the actually used text ? Is it compressed somewhere
The famicom Final Fight 3 pirate original had a bunch of source code in it too as I recall.
Could be interesting too, even if the game is "pirate original".
tepples
Posts: 22345
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Leftover code in games

Post by tepples »

One of the purported "NES test cartridge" ROMs, the one with the "b d p q" sprites on one of the test screens, has source code in it.

When I used to play falling block games, I discovered that Tetris Worlds for GBA has comments all over (but the game came nowhere close to filling 4 MB, which was the smallest GBA cartridge), and the game rules of Tetris Elements for PC are configured by plain-text script files.
User avatar
thefox
Posts: 3139
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Leftover code in games

Post by thefox »

Bregalad wrote:4) Secret of Evermore

Okay it's not NES it's Super NES and there is nothing much interesting other than the game was written in C instead of assembly !
It's such a short piece that it could be from a tool too. I think it's unlikely that they would have been using floating point numbers in the game.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Re: Leftover code in games

Post by Shiru »

Why, floating point math could be quite useful in a RPG game, for stuff like hit calculation - doesn't have to be fast there.
User avatar
Bregalad
Posts: 8036
Joined: Fri Nov 12, 2004 2:49 pm
Location: Caen, France

Re: Leftover code in games

Post by Bregalad »

@thefox : You are totally right, it could have been the source of something else than the game itself !

The only reason they would have to use floating point it :
1) The programmer is dumb and don't know about fixed point / they think floating point is the only way to represent non-integers, and trust me there are many people in this category
2) You have to handle both very small numbers such as 0.0001 and very large numbers like 10e+15 and both with a decent relative precision.

In the case of hit calculations, it could probably be done in fixed point, especially considering the result is always from 0 to 999, which fits in 10-bits, therefore 6 bits are left for extra precision if required during the calculation of the damage.
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Re: Leftover code in games

Post by Shiru »

Fixed point is fast but not convinient at all, it is pain in the back in a large complex project like a RPG game. There is nothing special or wrong in floating point usage, you know, many BASIC interpreters of old home computers had it as the only number type. Like, ZX Spectrum in 1982.

I wonder how smart it is to tell that people who completed a huge successful project in 1990s were potentially dumb.
User avatar
rainwarrior
Posts: 8062
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Leftover code in games

Post by rainwarrior »

Ahh, the disk drive explanation makes some sense. Still seems like a massive oversight to me, though.
Denine
Posts: 397
Joined: Wed Feb 17, 2010 5:42 pm

Re: Leftover code in games

Post by Denine »

Wait, what?
That is really interesting!
Ahh, the disk drive explanation makes some sense. Still seems like a massive oversight to me, though.
Yes, that's true.
At the other hand. Why bother with stuff that do not make any trouble in developement? I mean there's no real reason to waste time by removing something if there's enough empty space to get game finished.
User avatar
thefox
Posts: 3139
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Leftover code in games

Post by thefox »

Shiru wrote:Why, floating point math could be quite useful in a RPG game, for stuff like hit calculation - doesn't have to be fast there.
It was just my gut feeling, I could be wrong.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
rainwarrior
Posts: 8062
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Leftover code in games

Post by rainwarrior »

Denine wrote:
rainwarrior wrote:Ahh, the disk drive explanation makes some sense. Still seems like a massive oversight to me, though.
Yes, that's true.
At the other hand. Why bother with stuff that do not make any trouble in developement? I mean there's no real reason to waste time by removing something if there's enough empty space to get game finished.
Yeah, that's why it makes sense. In an era where disk access may have been relatively slow, I could see how a ROM building tool wouldn't overwrite any data it didn't have to.

These days... is it even possible to do anymore? It seems like that would be a big security risk for any OS to allow a file to be created that takes over a block of disk without clearing it first. You'd probably have to do it through low-level access. For PCs in the 80s and 90s I can understand why someone would favour speed over security in their I/O design.
tepples
Posts: 22345
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Leftover code in games

Post by tepples »

Denine wrote:Why bother with stuff that do not make any trouble in developement? I mean there's no real reason to waste time by removing something if there's enough empty space to get game finished.
Around what year or what ROM size did professional game developers stop feeling like putting huge amounts of effort into trimming down a game to fit the next lower power of two ROM size? We had a discussion about this recently on Slashdot, where the Mac OS team filled unused space in the Macintosh SE's ROM with three full-screen photos of the developers (G 41D89A from the debugger). A user joked that it would have been a better use of engineer's time to make a herculean effort to cut the program's footprint down to the next lower power of two.

rainwarrior: It probably changed when PC operating systems started supporting sparse files, or files containing implicit zero-filled clusters.
Post Reply