The Hidden Source Code in Dragon's Lair (NES)
ฝัง
- เผยแพร่เมื่อ 28 ก.ย. 2024
- What secrets are hidden inside the Japanese and European ROMs for Dragon's Lair (NES)? Let's take a look inside!
If you would like to support this channel, here is a link to the Displaced Gamers Patreon page - / displacedgamers
Twitter: / displacedgamers
Facebook: / displacedgamers
Instagram: / displacedgamers
Music by:
/ hariboosx
/ @wolfandraven
#SourceCode #ROM #Assembly
UnderWare BRIEF is some quality dork humor.
I used to comment in ebonics in assembly code I wrote.
Also I left smart ass comments like:
SWAPF register, f ; Swap nybbles (not wives)
I love nerd jokes in programming environment and source code. I even guilty myself writing dirty jokes and rambles in my source codes.
BRIEF is a really good editor/environment that supported scripting (through LISP script) and window views into multiple files on a single screen that I've used the heck out of developing some older console games.
I met a couple of the BRIEF developers once, on a junket to Borland, shortly after Borland had acquired them. I thought it would wind up with more advanced editing in the IDE, but alas, they just killed it. I supposed they just used the talented coders for other projects.
@@JohnDlugosz Was that in the office by the Santa Ana / John Wayne airport? They have been gone for years (or decades?) but I work right by there today.
I was really hoping you'd show why the US release was slower than the Japanese one after looking at the ROM output.
This
Likely due to the fact that US version used RAM for graphics data; during some periods they probably had routines that did a copy operation between PRG ROM to CHR RAM, which would take time. In the JP version, they were both ROMs with MMC that probably allowed for fast bank switching and displaying of graphics without having to wait for a copy-across.
I was expecting that as well. I don't think it had to do anything with poorly written software, but as others have said, because the cartridge hardware was superior. After all, if it was merely a software issue they could have fixed that and made it run better without having to change cartridge type.
Most likely due to too much dust in the game. But just blow the cartridge and she will most likely give you an answer.
It's because they used syrup instead of water inside the ROM chip, which flows slower.
oh, and avout the screen at 18:44
According to the cutting room floor, the European version had a boss at the end of the Entrance Hall not present in either the US or Japanese version. This boss is shown on the splash screen at 18:44, so maybe that's why it is used only in the EU version.
Your content has been incredible lately! Absolutely loving it.
It looks like MotiveTime Assembler just dumped whatever happened to be in RAM at the time on the compiling system into unused areas of the ROM. Not only is there source code but strings and error messages from programs that were open at the time of compile. If the previous (U) iteration had a CHR-RAM chip, those now "empty" areas in PRG-ROM would have been filled with graphics to load the CHR-RAM chip. Since those graphics are on the CHR-ROM chip now with the MMC3 configuration, MotiveTime Assembler just threw "whatever junk data" in there to pad it. Fascinating.
This is a fantastic video! I have seen the Leftover Source Code Entry for Dragon's Lair on TCRF but I am so glad to have you go through this and explain it some in depth. I liked how you discussed the different Machine Op Codes for the LDA (and other) instructions. I guess it is also worth mentioning that the Microcode of the 6502 tells the Program Counter how many bytes to increment based on the instruction Op Code as well (if its a 0, 1, or 2 byte parameter opcode), but then we would be going really deep.
Thanks, Brian! Yeah. I mean... I always figure that should anyone want to get in a discussion about details, they are free to open it up in the comments.
Yup I agree. As a developer and whatever personality I am, I love hearing the things I think/know to be true repeated by someone else because it makes my thought process feel validated. I really liked the Assembly Code work I did on a Motorola Microcontroller, maybe I should get back to it on the 6502 and/or NES.
@@BrianBates128 Was the Motorola a 68HC08 or 68HC11? Those have an architecture and instruction set that is very similar to the 6502.
@@jimmyhirr5773 I believe we were using the HC11. It's been about... 11 years lol.
I knew about EA's reverse engineered Genesis/MegaDrive dev kit, but had no idea about Rare's homebrewed dev kit.
I wonder if there's any more instances of this kind of thing happening out there.
I don't know about any more examples of reverse engineered dev kits, but some Nintendo 64 developers used Doctor V64 devices (normally used by software pirates) to load and test code since they were significantly cheaper than official dev kits. It wouldn't surprise me if some (possibly many) DS development studios used DS flash carts for developing their games.
Awesome video, as always!!
This is a really interesting topic; deducing the programmers’ situation from their old code. Amazing work as always!
Back in the mid-late 90's I was really into making MOD music, and I really wanted samples from SNES games but there were no tools for that back then and emulation was still in it's infancy. I was just screwing around and loaded some SNES roms in Soundforge and scrubbed through it and was surprised to find that you can actually find the samples that way. They're all really short and you have to cut them out and loop them yourself but that was how I got samples from SNES roms back then. Seeing you open the rom in a text editor reminded me of that. :]
Amazing detective work! This was super simple to follow. I love when thought to be deleted data is accidentally archived in games unknowingly.
"Based on the spelling in these comments we can verify they were written by a real programmer."
Wow that is souper offensive. I'm a programer and find that ofinsive.
Really? The only reason I said it was because I am a programmer, have made a few spelling mistakes over the years, and laughed with a few other programmers in the room when we find things.
We call each other out just because it doesn't really matter on the whole.
Stuff like:
"Hey John?"
"Yeah?"
"How do you spell..."
John: "Uh oh...."
A very light environment! I didn't mean to offend anyone at all! It was 100% a joke!
@@DisplacedGamers he's definitely joking, hence his own spelling in the comment, all in good fun.
@@jamescurrie01 Ahh. I am a programmer, so I didn't notice anything wrong with his spelling. HAHA...Ha.... ha. aah.
lol, pretty sure that's sarcasm. You'd be surprised what we find in the comments
@@DisplacedGamers Yeah that was 100% sarcastic. Come on, man. You're a programmer. You should know we all have dry senses of humor. ;)
There's quite a few games on the NES, and Gameboy with sourcecode in it. I believe one of the common assemblers would basically just take a whole page of memory and dump that to a file, or at least a block of memory in the size that you specified, of course without clearing it first. So whatever was previously in there, was then burned into some silicone for all of time. The Cutting Room Floor site has a lot of information 'bout all this and the games which included their source, or other neat stuff.
I wonder what's the legality of this situation. Does the code still belong to the company, or due to it being included in the game's ROM, is it perfectly legal to take, modify, and resell the compiled source code?
This is the first time I've heard of the entire source code for games being included accidentally(?) with the game.
@@thepuzzlemaster64 Unless there's a license stating otherwise, the source code is still under copyright, same as the actual game data on the cartridge is.
As I elaborated in another post, that's the behavior of the OS primitives and no need to write a whole page of RAM out yourself.
Also, chips are made of silicon, the semi-metallic element. You're confusing that with silicone which is a jiggly polymer used to make breast implants.
@@thepuzzlemaster64 The source code does not have to be secret to be copyrighted. Also, this is nothing close to the entire source code!! it's just a couple K, including some snippets of source. Why did you think it was the entire source code?
@@thepuzzlemaster64 as far as I know, secrets published by accident are still considered private, legally, so purposely republishing them would be the same as leaking them. Just distributing the ROM probably wouldn't count, but would be copyright infringement. I'm not a lawyer though so I'm pretty much just guessing based on what I've heard.
That does mean places like TCRF could get in trouble, but it appears the owners of this code don't care that a few pieces of it accidentally got included in the game and then documented online 30 years later. It's not as if their competitors are gonna rip off their #1 hit using a few incomplete code fragments decades too late. I'm not sure the company even still exists.
I like how every DG video is a potentially mildly clickbait title that turns out to be not only completely justifiable, but actually a little bit conservative. Never been disappointed with the payout. :-)
I had a clickbait-y thumbnail (Daphne from the LD capture) made for the video, but I chickened out.
Hey Displaced Gamers,
When was it discovered that the source code was at the end of the rom dump? Never heard of this!
I don't have a date on the discovery, but it was definitely a surprise to me back when I first saw it. The ROM community discovered it years ago, but I guess nobody talks about it much because "it's Dragon's Lair for the NES..."
Thinking like... this got past Nintendo verification, nobody questioned why the padding wasn't just all zeroes, etc.
So weird
@@unexpecteditem7919 It is actually fairly common. PCs in those days didn't have any memory protection. So if you said "dump this 128k of memory to EPROM", but the game was only 100k, it'd also dump 28k of whatever else happened to be in the PC's RAM after the ROM image. Check out the "Games with uncompiled source code" category on TCRF for lots of examples... and check out the DynaMike page there for an extra spicy example.
@@unexpecteditem7919 "All zeroes" padding is actually pretty useful for NES development if you have limited tools available because it is what the "BRK" instruction assembles to. This provided a way to create a crash dump so to say if your program ever really got out of hand and started executing in the padded area. It calls a software forced "interrupt" that things like the MMC3 would trigger at a certain scanline to let you do effects like parallax scrolling or separating the HUD from the gameplay area.
@@DisplacedGamers It IS Dragon's Lair for the NES but I really appreciate this error of their now because it is a way to see how they were doing this stuff back in the day. I've also heard on many occasions how devs were struggling with badly (if at all) translated documentation. Many developers didn't use DPCM samples simply because they had no idea that sound channel even existed or couldn't figure out how to use it.
Nice piece of retro engineering. Investigative first, then technical. All that very well put in a didactic video. Great stuff.
Didactic video huh?
Just discovered your channel and content. This stuff is fascinating. I developed back in the 80s on a PC for ColecoVision (tax software for H&R Block). Amazing detective work and a great presentation!
Ahhh Laserdisc...Great times. I got a laserdisc player for my birthday back in the day. I only had 3 movies. Star Trek the undiscovered country, Batman returns, and Indiana Jones, its probably why i know these movies scenes by heart.
just discovered your channel
great content
instant subscribed
a faaaaaaaaaar cry from those jerks who keep on asking for the viewer to subscribe like 3 times per video and you don't see why you should
Whomever made those obnoxious bell animations needs to find something better to do.
Brief was an editor that was EVERYWHERE back then.. it rocked.
I am slowly learning Assembly through these videos, or at least how it works. Keep up the good work.
Displaced Gamers, to show input lag, you could use a tool that shows when you press keys on the keyboard. I'm not sure what it is, but a streamer named coincident uses this to show what keys he is pressing while streaming.
Great video. I can easily follow the 6502 parts now that i've been heavy coding in nesmaker for over a year.
This is why i like to create a debug switch with extra code that could be turn off instead of forgetting to remove. temporary code.
The way you reference sources and show broll really adds to the story telling and entertainment
What a great video! Reverse engineering a ROM to find the development tools used by the team that made the game. You don't see stuff like that on TH-cam often. Your channel keeps giving us some really pleasant surprises. Watching the segment on the video when you show the chips on the cart, it occurred to me that the whole "chips used on carts" theme can be made into a very interesting video. From Mapper Chips to DSP there is a lot of interesting ground to cover. You can even address how pirated carts work. Where I live, buying original NES/SNES/Genesis carts was almost impossible. Most of the games you saw around were pirated. Hell, even today you can still buy pirated Genesis and Famicom games without effort (yes, they still sell quite well here). The curious part is that when you opened one of those carts, the ROM chips you expected to find were not there. There was usually a small epoxy blob somewhere in the PCB. Also, you rarely got battery backup on the games that were supposed to include that feature. An interesting idea for a future video. Excellent work, as usual.
Those chips you see coated with epoxy blobs are called, uncreatively, "glob tops."
There is a Bootleg Games Wiki that has a surprising amount of information about bootleg games. It's not as technically informative as these videos though. bootleggames.fandom.com/wiki/BootlegGames_Wiki
Also, Retro Game Mechanics Explained made a video about the SNES's memory mapping: th-cam.com/video/-U76YvWdnZM/w-d-xo.html
@@jimmyhirr5773 Thanks for the answer. I'll be checking the video on SNES mappers. I was aware of the Bootleg Games Wiki, is a great source of information if you are interested in pirated/bootlegged software. My interest lies on the hardware side of those pirated games. I was always curious about the lack of chips on those cartridges. I was able to compare an original game with a bootlegged one, and there were two or three chips on the original that were completely missing from the bootleg. Since that moment, I wondered how the pirated games worked. And if you could produce an almost perfectly working copy of the game with less chips (obviously cheaper), why did the original carts had to include the other chips that made the game more expensive.
@@GimblyGFR That's an interesting question, and I'd also like to know the answer. If the pirated copy was made many years after the original game was released, then the pirates could put more transistors in a single chip than the original publishers could because of miniaturization. So that's one possible explanation. But I'd really like to hear an answer from someone who works in the semiconductor industry because they would have more insight.
@@jimmyhirr5773 It depends on the system.
NES gets a lot of chips! At the very least, it needs a lockout/security chip, a PRG ROM chip, a mapper chip or several chips, and a CHR chip which can be either SRAM or ROM. The simplest and cheapest cartridge is the Unrom, it has SRAM CHR, and it has two mapper chips, which are classic 7400-series ICs, which were first released in 1960s, are manufactured by dozens of companies (so lots of competition, reducing the price), very simple and dirt cheap.
For the clone console, they use Famicom format cartridges, which don't use lockout chip; and even when they use NES format cartridges, there is no corresponding lockout chip in the console either way, so no point in including one in the cartridge! The cost structure has also changed, semiconductors got cheaper, assembly got relatively more expensive at the kind of price point they are trying to hit. The economy of scale and passage of time allowed the cartridge manufacturers to combine more stuff on a single die. Furthermore encasing the chips costs extra, so they tend to prefer bare dies under a gloptop. They don't care if this causes quality issues. They went through several evolutions. Early ones looked pretty much same as genuine Famicom carts, same number and function of chips individually, even all encased, though some of them gradually became gloptops. Then they consolidated SRAM and mapper in one die under a gloptop. Then they had a version with ROM, SRAM and mapper under a single gloptop, with an OTP test point on the cartridge PCB - so the ROM is apparently not mask ROM any longer, but OTP EPROM.
As to SNES, i think they would mostly just remove features. In the simplest case, the genuine cartridge without save game support consists of a PRG ROM chip and a lockout chip. I'd assume in regions where there is no legitimate Nintendo distribution, grey market sellers would simply modify the console to knock out the lockout chip in the console; then clone cartridges will work without the corresponding lockout chip, just with the ROM chip. But they also got clones of the lockout chip eventually.
I also saw mentions of PVCS in there. "Programmer Version Control System". An early source code control system.
I think finding source code and other stuff at the end of the file is not due to a configuration error, but is actually common place. The OS did not zero out newly allocated disk clusters, and there was no notion of "TRIM" as added decades later for making SSDs more efficient.
If you look at any file, the defined length is stored and listing/reading will only go up to that point. But if you look at the disk itself using a sector editor, you'll see that the file is a multiple of the cluster size (512 bytes for a floppy disk) and what's at the end of the last sector will be left over from that sector when the file was originally written. This, as exposed by various magazine articles in the day, can sometimes reveal snippets of source code.
Normally, people are completely unaware of this as reading the file in the normal way will not show that tail data.
But, the same issue is present if you issue the DOS command to change the length of a file. If the result is longer than the previous size, you get whole sectors assigned to the file now, that were not cleared of their previous contents. The ROM image file sent to the PROM writer (and eventually the mask maker) needs to be the size of the ROM chip being targeted, so they set that length after writing the linked output, and simply did not consider what data appeared in this tail.
It's a configuration error in the sense that they didn't ensure the generated file size matched the size that would be burned to the chip (or didn't properly fill that area of the file).
My favorite college course was an X68000 assembly course. This kind of diving into ROM opcodes is fascinating.
Wow, this is super cool! Has this sort of thing ever happened anywhere else, where the source code is found inside the machine code?
Related, kinda, I can't remember any other games where the actual source is inside the build (I know there are some), but there are shit loads of games where they accidentally ship the retail game with the debug symbols left in.
This is almost as bad, because the debug symbols contain all the function/variable names and such, which makes decompiling pretty easy.
Like all PS2 Grand Theft Autos did this.
Prince of Persia had a few pseudo ops in it. I paged through it out of curiosity since I mentioned it in this video.
Secret of Evermore (SNES) has a decent chunk of text as well as some C code inside.
@@DisplacedGamers Oh that's so awesome!! I love Secret of Evermore. I should open the rom in a text editor....
The Cutting Room Floor has an entire section for games that contain uncompiled source code. Check it out: tcrf.net/Category:Games_with_uncompiled_source_code
@@unexpecteditem7919 a lot of GameCube and DS games included debug map files. Not quite as nice as symbols in the executable (let alone source code) but still very nice. One of the Pikmin games even includes a Windows port, that was used for quick testing.
Demo discs were sometimes even worse in this regard; the demo of Star Fox Adventures includes a much older version of the executable with a ton of debug information. (Unfortunately it isn't compatible with any assets we have...)
theres a possibility that whatever way the ram was set up on the 'hacked' development kit meant that the game played absolutely normal for the developer, but was only discovered to be slower when already physically manufactured using the 'normal' US release where it was obviously bottlenecked by the speed of transferring ram. Once that was discovered the easiest way to fix it for further releases was to change it for the faster (probably more expensive) method.
"Based on the spelling in these comments, we can verify that they were written by a real programmer"
That one felt personal
My biggest surprise in this video was that 8 Eyes used MMC3. lol
Love your videos as I've said in other comment sections. Does the debugger have a dark mode? Looking at that bright white background genuinely hurts my eyes.
I guess they didn't show the cameo screen with the big snake in the US\JP versions since that boss is not in those versions. In the EU version you fight a huge snake boss from that screen, but in the US\JP version you just fight two small regular snake enemies instead.
You can throw daggers? No wonder I never got passed that first screen. I thought this game was some kind of cruel joke.
I swear that in Nintendo Power, it said Kirby's Adventure used the MMC5 chip. It allowed for the extra colors and parallax scrolling. That's what I remember reading anyhow.
very nice work. Is there enough source to point the way toward why the performance is so much smoother in the jp release, and to what extent it's using the mmc3 to make that possible?
Jeez, just thinking about how many circumstances would have had to happen for Motivetime to be able to create Dragon's Lair (NES) is mind boggling, especially considering how early the internet was back the and the amount of IRL networking that would have been necessary. A true testament to humanity's luck imo.
Interesting stuff. This really brings back memories for me. I hated, of all things, the case insensitive nature of DOS. Thus, the convention was to use all uppercase code, which is harder to read than cased code in my opinion. Unix systems were very expensive at the time, so everyone was using some type of DOS. To this day, Microsoft has stuck with that uppercase convention, at least with their command line. Still drives me nuts.
There are a surprising number of industrial programs with silly names. Once it becomes a standard solution nobody cares but I've wondered if immature names make it harder to sell expensive software in the early days when it's still at risk of being swept aside by something else.
Well done on your rom archeology.
Great content. Always loved these old school programming tales.
It's been three years, but I'm pretty sure I know why all of this happened. At the time, Nintendo had a strict policy regarding helper chips in the US. They did not allow 3rd parties to use non-Nintendo chips. This is why games like Contra and Castlevania 3 were reworked for the US using Nintendo only helper chips. This is why Dragon's Lair was so messed up in the US.
I don't fully understand the *why* of your videos; I am no coder or programmer. I have trouble with basic mathematics. But your videos are incredibly interesting and I under the basics.
Awesome video =D
This is what i call good content
That was really enjoyable! Thanks for making this video!
Thanks for another awesome video, detective DG!
Ah yes. The NES. I played games on that. Source coded through my whole childhood.
Really though, you developers and coders are literal digital wizards.
Thank you for the informative video. I understood some words.
Great video! Honest question: why not just interview the creators?
I'm surprised some electronics genius on the internet hasn't created some kind of open source 8 or 16 bit system devkit.
Very nice video, thanks for your effort. I love this channel
Dragon's Lair fucking rocked. I'm not apologizing.
Just amazing work!
Did you ever deep dive into the mortal kombat source?
This is amazing, thanks for the vid!
Damn this was surprisingly fun!
It was definitely a mistake. The thing with ROMs is that they contain more than just assembled source code (like graphics, sounds, and other binary data). Generally you will append that data to the end of the used address space and reference it using some defined offsets (which could be updated by the process). You can see in the APPEND variable they just included a bunch of random directories. My guess is that they probably just told it to dump everything from the same directory because it was easier than specifying the files individually.
APPEND sits in a block of nul separated environment variables, it's not an assembler directive. It's probably a leftover from setting the PATH variable in their AUTOEXEC or dev environment somewhere, nothing more. It is also evident how the placement process works in their assembler, you use ORG assembler directive to set the address in the ROM file, and then use INCLUDE and INCBIN directives to plop down some sort of stuff at that address. Also "appending" makes remarkably little sense in the context of 6502 and derivatives, as you don't want a lot of things to cross a page boundary, so you want explicit placement.
It stands to reason that there is simply a bug in the assembler. It might be a bug in the routine that grows the output buffer in RAM when ORG or some other directive is encountered, that maybe something like one page is cleared but the rest isn't. Keep in mind, the assembler is pretty powerful, scriptable, which just makes bugs more likely, but it's not a commercial product, it's something they threw together in-house, so these sorts of bugs probably would have escaped triage even if noticed.
For all games that had more space in thier games and programming skills, USE ALL OF IT. And not waste it and or add a easter egg or leave something good.
Also neat video
12:24 actually yes it is
just display inputs on the screen and slow down the footage
Thanks for this comment - saved me time in not finishing the video.
my guess on why the hidden code is because of an out of bounds read.
since the size was set to 126 the 2k difference may have allowed the developer unit to jump 2k outside of the bounds of the buffer into the part of the buffer where the source code lived or where the compiling happens.
the mmc3 chip could have been used as a way to handle copyright or drm.
not satisfied with nintendo's drm handler chip they made their own rather than relying on nintendo's copyright chip or suicide batteries.
they wanted the game to be still around years later but did not want it easy to dump.
a suicide battery once the battery goes dead the contents are lost as games like that dont use roms but they use ram instead and the battery holds the contents of the ram.
and for that same reason of preservation maybe the code was intentionally put in there so game preservation would be possible.
I love your videos I love learning about this stuff. I've always wanted to learn how to program and find it fascinating. I just don't ever have the time to learn it. Any suggestions on where to start?
"UnderWare Inc"...Call me juvenile, but my mind went somewhere else for a moment...
This is scaringly good.
Has it ever been debunked that this is simply a hertz rate issue when they brought it to the states? Considering the music is faster and the gameplay is faster in Japan it seems likely it's a 50 to 60 hz thing
Yeah its definitely a software difference. Different mappers don't increase clock speeds or access times. They probably just got feedback on it and turned the speed up.
Would you also happen to know why the colors are so dark compared to other NES games?
Lots of layers to these dragons, huh?
Wow, I’m here after 2 seconds of upload (allegedly). Neat. I look forward to the content on an otherwise indifferent or “poor” game.
Ok, now that I watched it in its entirety; I would also through in the hypothesis that due to some of the litigation Nintendo had faced around that time, they may have loosened their access to reference materials that would otherwise been kept to more preferred devs- this is likely around when the Tengen suit was resolved in US court. Also Sega mega drive may have been a push for a similar relaxation of previous policies as well. I’m now very curious if anyone from this dev period would be able to shed any light on this.
5:25 secrets revealed!
Obligatory algorithm engagement comment.
What happens if you expand the memory of the ram?
it has come back to haunt me...
Is there an MMC chip that allows for larger games
Soooo badly want to ask you a BILLION assembly language questions (naimly HOW TF they got a NES game to be written on MS-DOS {I KNEW IT back in the day, but no one believed me, everyone thought it was some sorta super computer for the time}) AND the diff between BIG endian [Indian? TF? and what does endian EVEN MEAN?] and little Endian....
Gonna look for an earlier video of yours HOPEFULLY explaining these things to START out... I'll feel very stupid if I leave this comment and you made a video EXPLAINING all of these at first before code assembly tear down. (Hell, I believed an asshole PC teacher back in the day that claimed to have written a flarkin WINDOWS app (3.1/95-ish) PURELY in assembly by hand... NO FLARKIN way! Lies and deciet.
Had a bad day today, and been bienging on your vids, you deserve FAR more likes and appreciation for these WONDEFUL vids. Thanks once more, and I WANNA KNOW how you speed boosted Link from Zelda 2 & STILL interacted like a baws! Please? XD
Which NES emulator are you using? The one I use does not have a monitor or debugger.
Try fceux
Man that was great !
Charged
Shot
I have a question...was Underware one of those unsung heroes of the industry? What I mean by that is often times games get shopped out to hidden middle companies that work on projects in secret. These companies can be seen almost like mercenaries as they often work with many competing companies at the same time completely off the books and at the highest bidder. This apparently happens quite often with triple A titles. If true, I have a theory myself...
With the Sega Genesis and TG-16 out in North America threatening Nintendo's dominance...the game was rushed to the US market. It is in "playable" form but not quite finished. It's possible they rushed it out to meet the deadline while having a middle ware company go back in and finish the game for everyone else. That could explain why everything seems backwards. Maybe the junk code found in the ROM was pieces of the original US version of Dragon's Lair. Has anyone attempted to compare the two ROMs' machine code side-by-side? I'm particularly interested in knowing if all versions of the game include junk code within the ROM Does the name Middleware appear in all versions of Dragon's Lair or is it just in the European and Japanese versions? This really interesting and thank you for making said video. You sir, have made my day.
Love it
Can you do a video on battletoads???
I don't understand why Nintendo was so stingy with development tools and support. I think they did this with other systems too, not releasing first party code to other studios. Maybe there would not have been so many terrible third party games if Nintendo offered better SDK support.
I think they didn't have the tools themselves? They were still pretty small at the time. They might have had some kit they put together but not anything good enough to share, or might have actually not had the money to invest in making such kits. I know by the later half of the SNES era, they did have official kits you could buy (if you had a development contract).
Some of their internal dev stuff actually became consumer products as well! The N64 Expansion Pak and Disk Drive were both used for development before being made public, and some games, even after the disk drive flopped, still used it for debugging. The SNES had a mouse and the Famicom had a keyboard, and some games used those for debug; leaked code has shown Nintendo used them too. (IIRC debug builds of Super Mario Kart use the mouse for a track editor.)
This video is 1000x better than the game.
It amazes me that there can be a stereotype of programmers being bad at spelling, since misspelled code will in 99% of cases fail to compile, and in the remaining 1% of cases make you waste a lot of time trying to de-bugger it.
Well what does a programmer do at least 80%, usually closer to 99% of the time as time goes on? Fix bugs.
Also if you have a limited attention span and effort, you'll definitely not put it into the spelling of the comments, but of actual code. I don't think comment spelling is outright horrible usually, i mean i occasionally see other people, non-programmers, write, and once in a while, i'm outright appalled; but they're not linguists or humanities graduates either.
I think, recently, there has also been a resistance to actually fixing spelling mistakes, since it might step on someone's feet and also generates spurious diff lines that someone later has to sift through and roll their eyes at, especially when there's a merge conflict or a bisect or some kind of audit etc.
Where art thou Princess Daphne
I work with several 1980s era computers, not based on UNIX. One of the 'features' is that file sizes have to be a fixed size, but obviously the data stored within may or may not hit that file size. If it doesn't, it's not padded with zeros, but instead an End-of-file marker is written and the rest of the file is filled up with whatever was on the disk at those memory locations before.
That could well be what's happened here. It certainly looks like it to me.
It makes actual file-content-verification horrible (as different file checksums may well be an 'identical' file) but I've delivered plenty of executables with source code shoved into the back end of the file, simply cause that's how the computer works at a binary level. It's invisible to the computer user, unless you know where to look.
It's a lot more likely that it's a buffer underrun in the program that's copying the ROM image to the ROM burner (or to a file). This looks a lot more like the memory of the computer than the raw disk data. This was a DOS machine, not POSIX-based, and I would put all my money on the fact that the developer should have padded the ROM image, didn't, and the transfer process just kept on going past the end the file and into whatever data was in memory before that operation (some of which was the batch files that initiated the process, the rest of which is the contents of the BRIEF application -- which most likely used up all of the available RAM to page in parts of the (large) .ASM files they were using).
@@NillKitty Correct about definitely being RAM data, not hard disk data. It wouldn't have to be an underrun though. In C (which the tool that creates the ROM image is probably written in), if you use malloc(), it doesn't initialize the RAM. There's generally no reason to do so, so that's not a huge problem, at least back then it wasn't. The memory just has random stuff from earlier operations (hence the environment variables, commands from the compilation process, maybe manually run command history from something like DOSKEY, etc.). The tool should have padded the image with 0xFF or something after it populated the program data into the image, but it didn't (maybe a command-line option that was omitted), so whatever didn't get written when populating the ROM just had whatever was in the PC's memory earlier.
@@shawnmulligan3471 calloc()
@@TurboXray Yeah but people make mistakes, it's probably a bug; normally you'd default to malloc if you intended to use the buffer immediately, because it's faster than calloc; maybe they intended to manually pad and just forgot, or maybe they didn't know about calloc, etc.
@@shawnmulligan3471 Oh I know. And no one uses calloc. But it's there haha.To the OP though, the filesystem issue is a thing for PC-Engine CD games, because they used harddrives to emulate data tracks. And so you see leftover stuff from files, and older uses of the HD (graphics, music, CDDA tracks) in between the real data in the data tracks. Art of Fighting for PC-Engine CD left their source code in an LHA file in one of those games. Was pretty amazing to see all of it intact.
I sincerely doubt Elite would have bought a PDS from RARE, Steve Wilcox, the head of Elite was pretty despised in the UK gaming industry as he would outright steal and re-release other companies games at a budget price, which landed him up in court several times over the years.
At a guess, I'd say they got the PDS from Data East or one of their subsidaries in Japan as they had a working relationship with them.
i've heard larry bundy jr was behind naming the MMC
What is this? Some kinda... Fact Hunt?
Would this information go into another fact hunt later? xD but.. hello you!
I can't believe he would profit off of other people's content. That's pathetic and he should feel bad.
Was he almost as hated as a.. CERTAIN OTHER person who's initials might be S.M., perhaps?
Turns out MotiveTime and Sierra had something in common: their choice in source code editing software, Brief.
If you're talking about the text editor, David Wise of Rare also used it for his SNES music.
Hi, as of now I understand around 10 to 15% about the stuff you're takling about but with each of your videos my understanding and "knowledge" increases - thank you for that!
One possible way to try and show laggy controls might be to show button inputs on the screen as they happen, allowing us to see the delay.
You didn't do the one thing I was kinda expecting: using this to compare the source with that from the slower North American release.
Yeah I'd like to see that in a part 2. It's not clear to me why the MMC3 version was faster other than it obv had more hardware to be faster
Was expecting that too.
@@dimreturns1190 I'm guessing it's because the MMC3 allows you to swap between animation frames faster.
A bit tricky because the US release doesn't have any junk source code in the rom
I think part of it was the trick of running it on hardware that was inherently 20% faster and how it affects the gameplay. One could agree that at 60, it's too fast, so another lazy option would be to cut it to 30 and make it too slow, rather than do extra work to make it feel like the intended speed.
"And, based by the spelling used in these comments, we can verify that they were written by a real programmer."
HAHAHA, so true! I love what you've been doing with these deep-dives lately, keep it up
Isn't that just the British spelling though? Or was that the point?
@@renakunisaki I think it's spelled "modified" on both ends of the pond. But it is a common way that folks who write a lot of C and assembly, but maybe not so much English, tend to misspell things.
There is another example of a -y word constructed with the y intact (in this case, a plural- "velocitys".) I can only conclude this is done intentionally for find functionality. The programmer wants to be able to recall that line when searching for "modify."
I heard someone say Laserdisc.
oh, oh! The Cheat's playin' somethin' on a laserdisc!
everything's better on a laserdisc!
*nervous sweating* You misheard, he said "CED".
Completely different.
More like LaserVision.
*Techmoan wants to know your location*
I'll sell you Power Stone on Laserdisc so you can dump the entire series onto TH-cam.
I was expecting an explanation of HOW the source code ended up in the cartridge ROM. My guess would be:
1) Because the developer used a PC for editing, the source code would likely have been in the PC RAM when the assembler was run. Typically, editors don't clear RAM when you quit the editor.
2) When the assembler was run, the assembler output ("object file") would have been written into the PC RAM also. This process would likely overwrite much of the residual source code in RAM, but not necessarily all of it.
3) The SEND command that dumps the object file to the interface likely sent a fixed size block of data, which -- in many cases -- would include any data in RAM that was outside of the bounds of the actual object file data itself.
Also, DOS didn't use an MMU (the 8088 didn't even have one), so loading data into the same bytes in RAM as other data would probably happen all the time, especially given the low RAM amounts of the time.
I wish this had gone on more. I found it really interesting and was really enjoying it when it ended too soon.
True but on the other hand, if the video was over 20 minutes, I probably would have never started watching it.
A company named UnderWare and they make a product called Brief. Yeah, that’s prime British humor right there.
Very well researched, and explained spectacularly clearly.
The comparison with Prince of Persia was good. Now I can, in fact, imagine how wonky the input is!
I agree. As soon as that reference was made I was like "ok yeah, fck playing DL"
You can always count on Displaced Gamers to give you an in-depth and entertaining ASM breakdown when you don't want to do it yourself =P
Keep up the good work!
There is an actual playable version of NES Dragon's Lair that does not control like garbage? That is bizarre information to have in my brain.