The Hidden Source Code in Dragon's Lair (NES)
Вставка
- Опубліковано 16 жов 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 - Ігри
![Lp. Сердце Вселенной #30 ДВА В ОДНОМ [Один человек]• Майнкрафт](http://i.ytimg.com/vi/nrXy15orKhY/mqdefault.jpg)
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 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?
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.
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!
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.
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.
"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 UA-cam.
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.
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 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.
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.
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.
Awesome video, as always!!
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.
Thank you for producing these incredible resources! They're genuinely some of the most interesting documentaries I've seen and your creativity and dedication are truly inspiring.
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!
When this popped up on my front page I thought it was clickbait, but I gave it a shot anyway.
Very well structured and researched. I love it!
This is a really interesting topic; deducing the programmers’ situation from their old code. Amazing work as always!
Very well researched, and explained spectacularly clearly.
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.
Absolute perfection of a video! I didn't even think about going a route like this, and you did it. Wonderful. Thank you for all the hard work!
Amazing detective work! This was super simple to follow. I love when thought to be deleted data is accidentally archived in games unknowingly.
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.
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. :]
Nice piece of retro engineering. Investigative first, then technical. All that very well put in a didactic video. Great stuff.
Didactic video huh?
I am loving your channel. A "Behind the code" on the first Super Mario Bros would be great, particularly in regards to Mario's physics.
What coding goes into: Walking/running, jump height, skidding, jump height after landing on an enemy, hitting a block with momentum, etc.
But there could be other topics too: How does the timer on coin blocks work, what decides the rate which Lakitu throws spinys? Why do invisible 1up blocks sometimes not appear?
SMB is one of my favorite games of all time and seeing the inner workings would be incredible.
The code in the rom reminds me of a GameBoy game, that, when assembled, was also smaller than the rom size, and needed to be filled with junk. However, when the rom was assembled, the programmer apparently did not initialize the ram of the PC, and was, before or during the assembly, looking at porn, so the assembler filled the remaining empty rom space with urls and thumbnails from the porn sites the guy was checking out.
Programs are weird.
Oh I remember this one hahahaha
It's a buffer underflow. The code that's copying bytes out to the ROM image just keeps going -- it doesn't care that the input file isn't long enough -- and copies whatever is in the developer's RAM beyond the source image. These are the days of DOS when there is no memory protection. It's very similar to Heartbleed.
That would definitely not happen on modern systems. The extra data would just be zeros or something mundane, or the program would error out. But thanks to DOS allowing programs to just read past the end of their files/memory and get whatever else happened to be laying around, we have lovely leaks like this!
(As a previous comment mentioned, this is almost exactly how Heartbleed happened. That was able to happen because the program was still reading from its own memory. If it had tried to read some memory that didn't belong to it, it would have crashed instead.)
Apparently that cart was just a prototype and the game never got released, so the carelessness is somewhat more excusable. Still pretty funny though.
@@renakunisaki You don't need to be able to read past your allowed memory in order to have data from other programs: If they freed that memory and your program allocates memory without clearing, it can have that data. Modern systems do clear memory when giving pages to different processes, though. The developer was most likely using win 9x/me. But I wonder if it could happen with NT too.
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!
I am slowly learning Assembly through these videos, or at least how it works. Keep up the good work.
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"
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.
"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. ;)
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.
God I love these videos that delve into the codes of classic videogames. Especially when you tweak the codes to alter the functions in the game.
Since I was a kid playing these games I always wanted to create my own games but was never computer savy enough to get into it. But seeing the skeleton of these old games makes it so much easier to understand and more like a possibility than a dream.
Maybe fantasy consoles is something you want to get into? For example Pico-8 lets you examine the source code of any game you were to come across. The programming language is Lua, it's about as simple as it gets, and graphics and sound are also all simplified compared to real hardware.
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 UA-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: ua-cam.com/video/-U76YvWdnZM/v-deo.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.
Such a deep understanding of coding, dos and how programmers typically think. Great job man. Really entertaining video!
The way you reference sources and show broll really adds to the story telling and entertainment
Thanks for these videos. I am especially grateful for your explanations of disassembling games. Keep up the great 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.
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.
Quality content!! Also, very clear explanations and demonstrations. Keep it up!
Your videos are the best. Keep up the great work
This was really great! Thanks for making it.
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.
A company named UnderWare and they make a product called Brief. Yeah, that’s prime British humor right there.
This is so well done, as with your other code-related videos. Makes me miss my assembly programming days all those years ago.
Very cool video, looking forward to more. I'm not sure how you don't have more subscribers to be honest :)
Thanks for the video!
I actually own the development system Mark Cooksey used for his NES games. Would be cool to get it working someday.
That's awesome! If you get it working, make a video!
Awesome, I wonder what other games have this much source-code preserved in them like this! Seeing this video reminded me I wanna learn Assembly someday, but I don't know where to start
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.
I feel like they must’ve developed for MMC3 first, I can’t see how they could develop the game to run as slowly as the UNROM version. I think they must’ve designed it for MMC3 but were forced to make a cheaper version for the US release, so that version was modified to run without the MMC3 but that made it run too slowly, however they either weren’t given time to fix it or the publisher/developers just didn’t care.
I know on a 6502 platform like the C64 PAL machines are also able to execute code a bit faster than NTSC because of the different video refresh rate. When you're talking about a 1mhz processor every little bit helps. Not sure if the same is true on the NES and its PPU.
@@johnathanstevens8436 It’s slightly the same for the NES, but the difference is minuscule, definitely not enough to have this impact.
I'm not even a programmer, and this stuff is endlessly interesting!
"Based on the spelling in these comments, we can verify that they were written by a real programmer"
That one felt personal
The joke about knowing it was a dev based on misspelling cut me deeply. Great video!
I sure hope I get to read the source comments for my favorite game someday... where you at, GigaLeaks?
I kinda see what they were going for- small challenges you learn to get through the same way every time, like playing the Laserdisc animation, but nobody can defend how they went about it. Most action games back then rewarded you for memorization but didn't require a single way of getting through challenges. It's part of what makes them so replayable- learn new tactics or strats and make you own experience
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).
Interesting! Never knew that Dragon's Lair had sourcecode in it :) Will poke around with this myself as well :)
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.
As a weird aside, it's not exactly accurate to say that a British company "copyrighted" something in a particular year unless they did so in the US or elsewhere. Under UK IP law copyright is a non-registrable right, that subsists within a work by virtue of its creation and being in an applicable statutory category. You don't register a copyright here, you assert its existence. Thus you don't really "copyright" a thing, you create it in line with statute and copyright just naturally happens. It's weird.
There are other registrable rights like patent and trademark, and also "registered designs", but with copyright the court will (massively oversimplifying here) enforce your right if you can evidence the creation date and that it falls into one of the categories in the relevant Act.
All that said, copyright is stupid complex.
My favorite college course was an X68000 assembly course. This kind of diving into ROM opcodes is fascinating.
Seeing your videos like this, digging into game code and parsing it out and such, makes me wish you had a video series called "Some Assembly Required" - although in fairness, maybe that's just too nerdy to be taken seriously, but it's a thought, heh.
Great work! Keep up this kind of content!
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.
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...)
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.
This is my new favourite channel!
Here's a theory: Maybe MotiveTime bought a bootleg development system from Taiwan, perhaps from Sachen. Isn't that where other bootleg developers got their tech?
Sensational stuff. Keep it up!
Great content. Always loved these old school programming tales.
How I love to stumble on high quality content like this
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?
Brief was an editor that was EVERYWHERE back then.. it rocked.
Thanks for another awesome video, detective DG!
That was really enjoyable! Thanks for making this video!
Even now this happens with modern toolsets. They allocate buffers for different PE sections which are in system memory where if by chance your text editor previously used for source code, it would include that in the final binary if nothing else was linked to that location. It is often small amounts of unintentional data and can be pretty bad if you had key material used by your build process. You can see this in exe's from earlier versions of visual studio by dragging in exe's into your favorite hex editor. I doubt enough of the game exists in source to do anything but certainly interesting if only to see programming preferences and even creative naming of assembler labels
Somewhere out on the net there's a list of PS2 games with unstripped binaries; these contain debug information, so symbol names. Some games also accidentally shipped a lot of interesting things in the padfile. The disc is much faster on the outer sections than on inner ones, so it has been customary to fill the early portion of the disc with a big junk file. Well, sometimes the contents of this file was not junk. I'm sure Renderware was leaked in this manner several times for example.
i subbed and liked about 5s in after seeing a link for another tech-focus video from this channel on zelda 2, don't let me down here
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.
Man, you're content is really interesting.
I love your great channel very much.. 👍👌Thanks man.
Awesome video!! thank you so much for sharing this information :)
Great work and great explanation!
Thanks a lot
Awesome video =D
Very nice video, thanks for your effort. I love this channel
I also saw mentions of PVCS in there. "Programmer Version Control System". An early source code control system.
This video made me realize how much I miss writing code in DOS using EDIT.COM and its lovely text GUI.
I love this channel so much 😭❤
That was very interesting, thanks for making this video!
4:18 Yeah, probably a simple pointer mistake (OOB Read, CWE-125).
I screwed up writing an assembly routine once and got parts of my BIOS printed to the screen.
LOL! What your looking at is the files that were opened when the compiler did the dump. DOS real mode would initialize memory that was allocated so you could read what was in the memory before. You can this a lot in the old 8 bit DOS code when the dev would save a string to file but the string was never scrubbed. (IE filled with 0's)
My guess is in their compiler it allocate a large chunk of memory to compile the ROM, the developer of the compiler expecting that the OS would scrub the memory. So that was probably memory originally allocated by the editor. You can find this a lot in data files where the application was using pascal style strings. C strings typically fill the end of the string length with 0's BUT not always.
Great video. Love your stuff.
Did you ever deep dive into the mortal kombat source?
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.
Go Further! like what eventually happened with E.T. Make a more playable version of the US release.
There is a documentary about ET and the search for where the overproduced cartridges were dumped named "Atari: Game Over." It has interviews with the guy who programmed it. Apparently it had only 6 weeks for development time because Atari wanted to get it on store shelves before Christmas. The programmer's vision for the game was too ambitious for that amount of time.
The programmer made another adventure game for the 2600 named Raiders of the Lost Ark that is much better regarded, so you should check that out.
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.
thanks, I have zero understanding of programming. I watched this to help me sleep and it's working!
that was a sick music intermission