This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Leftover code in games

Leftover code in games
by on (#99006)
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:
; 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:
; 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.
Re: Leftover code in games
by on (#99008)
Sticking source code in the ROM is the weirdest thing. Very interesting.
Re: Leftover code in games
by on (#99009)
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.
Re: Leftover code in games
by on (#99010)
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.
Re: Leftover code in games
by on (#99012)
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

Quote:
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".
Re: Leftover code in games
by on (#99013)
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.
Re: Leftover code in games
by on (#99016)
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.
Re: Leftover code in games
by on (#99019)
Why, floating point math could be quite useful in a RPG game, for stuff like hit calculation - doesn't have to be fast there.
Re: Leftover code in games
by on (#99021)
@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.
Re: Leftover code in games
by on (#99023)
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.
Re: Leftover code in games
by on (#99024)
Ahh, the disk drive explanation makes some sense. Still seems like a massive oversight to me, though.
Re: Leftover code in games
by on (#99027)
Wait, what?
That is really interesting!
Quote:
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.
Re: Leftover code in games
by on (#99033)
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.
Re: Leftover code in games
by on (#99034)
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.
Re: Leftover code in games
by on (#99035)
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.
Re: Leftover code in games
by on (#99040)
This is indeed quite interesting, and will likely teach me something, which is good because I could really use an advanced course in NES assembly!
Re: Leftover code in games
by on (#99042)
Personally I wouldn't use any of the old sources (that I have seen) to try to learn anything. Short/obscure symbol names, next to no comments, tons of magic numeric constants -- all of the sources seem to show the same pattern. :)

BTW, for those not in the know, Gil Galad's site has full source code for a prototype of James Bond Jr., among others.
Re: Leftover code in games
by on (#99048)
thefox wrote:
Personally I wouldn't use any of the old sources (that I have seen) to try to learn anything. Short/obscure symbol names, next to no comments, tons of magic numeric constants -- all of the sources seem to show the same pattern. :)

BTW, for those not in the know, Gil Galad's site has full source code for a prototype of James Bond Jr., among others.


It's a lot better than anything I can churn out at the moment - but that link will help me a lot, Thanks!
Re: Leftover code in games
by on (#99094)
tepples wrote:
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.

That's a very good argument. But I' was thinking about cases where you can't make smaller ROM, game is finished and there is some garbage.Yea, I did not percise it, sorry about that.
Example:
UNROM 64kb game which is finished, can't be cut down anymore and have empty spaces occupied with some source garbage.
While developers could add something extra by removing that garbage, it would be an additional costs, right?
And who want an additional costs with finished product?
Re: Leftover code in games
by on (#99097)
I mentioned it briefly on this forum that there are tons of free room in some European games, mostly in the CHR ROM. Like, 9 of 16 CHR banks in Alien 3 are empty.
Re: Leftover code in games
by on (#99101)
I see, thanks, Shiru.
I wonder why USA version of Dragons Lair is missing source code?
According to wikipedia article, USA version was first to be released.
But even with this, I don't see a reason for such a big change. Also, why did'nt they just wipe the uncompiled the code? USA version is 128kb ROM...This is really anti "costs saving" thing to do.(I mean, 128 EPROM is cheaper than 256, thus saving costs.)
Re: Leftover code in games
by on (#99104)
Well Europe's DL has 2x 128's instead of 128K PRG and CHR-RAM. I can't tell since I'm on Ubuntu, but maybe the US version just went at 30FPS speed with one full VBlank and render being to transfer more tiles and the CHR-ROM was used to gain the speed? I'm just guessing watching the youtube video of the EU/US games.
Re: Leftover code in games
by on (#99105)
Wow!
You're correct.And yes, EU and Jap are faster.
USA version is UNROM 128kb, while EU and Jap ersions are MMC3 with CHR ROM...
Why I did not thought about it?
Thanks.
Re: Leftover code in games
by on (#99111)
US Dragon's Lair runs at 12FPS. European Dragon's Lair runs at 16.66FPS. Japanese Dragon's Lair runs at 20FPS.
Same exact game logic, just run faster. Since the Japanese version also has faster music (6/5 as fast as the original), I'm guessing the Japanese version was a port of the European version.
Re: Leftover code in games
by on (#99130)
Bregalad wrote:
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

Quote:
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".


No, there are "two scripts" in ROM apparently. But only one is the complete script for the game. But an alternate possibly complete script exists but I think it contained some no-no words for Nintendo of America's policies at the time.