UnderWare BRIEF is some quality dork humor.

@misterhat5823

3 жыл бұрын

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)

@MakotoIchinose

3 жыл бұрын

I love nerd jokes in programming environment and source code. I even guilty myself writing dirty jokes and rambles in my source codes.

@CyclesMcHurtz

3 жыл бұрын

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.

@JohnDlugosz

3 жыл бұрын

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.

@-taz-

3 жыл бұрын

@@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.

@NillKitty

3 жыл бұрын

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).

@shawnmulligan3471

3 жыл бұрын

@@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.

@TurboXray

2 жыл бұрын

@@shawnmulligan3471 calloc()

@shawnmulligan3471

2 жыл бұрын

@@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.

@TurboXray

2 жыл бұрын

@@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.

@akalyx

3 жыл бұрын

i've heard larry bundy jr was behind naming the MMC

@mostlyghostly6615

3 жыл бұрын

What is this? Some kinda... Fact Hunt?

@xenxander

3 жыл бұрын

Would this information go into another fact hunt later? xD but.. hello you!

@GigaBoots

3 жыл бұрын

I can't believe he would profit off of other people's content. That's pathetic and he should feel bad.

@calanon534

3 жыл бұрын

Was he almost as hated as a.. CERTAIN OTHER person who's initials might be S.M., perhaps?

"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

@renakunisaki

2 жыл бұрын

Isn't that just the British spelling though? Or was that the point?

@jaysonl

2 жыл бұрын

@@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.

@TheJacklikesvideos

2 жыл бұрын

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 was really hoping you'd show why the US release was slower than the Japanese one after looking at the ROM output.

@zippanto

3 жыл бұрын

This

@please_eject_the_disk

3 жыл бұрын

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.

@daneast

2 жыл бұрын

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.

@dredwick

2 жыл бұрын

Most likely due to too much dust in the game. But just blow the cartridge and she will most likely give you an answer.

@GiuseppeGaetanoSabatelli

2 жыл бұрын

It's because they used syrup instead of water inside the ROM chip, which flows slower.

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.

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.

@Doommaster1994

3 жыл бұрын

If you're talking about the text editor, David Wise of Rare also used it for his SNES music.

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.

@dimreturns1190

3 жыл бұрын

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

@persona83

3 жыл бұрын

Was expecting that too.

@aaendi6661

2 жыл бұрын

@@dimreturns1190 I'm guessing it's because the MMC3 allows you to swap between animation frames faster.

@Kippykip

2 жыл бұрын

A bit tricky because the US release doesn't have any junk source code in the rom

@ztoxtube

Жыл бұрын

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.

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.

@kargaroc386

2 жыл бұрын

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.

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.

@DisplacedGamers

3 жыл бұрын

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.

@BrianBates128

3 жыл бұрын

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.

@jimmyhirr5773

3 жыл бұрын

@@BrianBates128 Was the Motorola a 68HC08 or 68HC11? Those have an architecture and instruction set that is very similar to the 6502.

@BrianBates128

3 жыл бұрын

@@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.

@jeffrey44

2 жыл бұрын

True but on the other hand, if the video was over 20 minutes, I probably would have never started watching it.

Awesome video, as always!!

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.

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.

I heard someone say Laserdisc.

@KairuHakubi

3 жыл бұрын

oh, oh! The Cheat's playin' somethin' on a laserdisc! everything's better on a laserdisc!

@badreality2

3 жыл бұрын

*nervous sweating* You misheard, he said "CED". Completely different.

@OM19_MO79

3 жыл бұрын

More like LaserVision.

@edwin3928ohd

3 жыл бұрын

*Techmoan wants to know your location*

@user-ny5vp9be8v

3 жыл бұрын

I'll sell you Power Stone on Laserdisc so you can dump the entire series onto KZread.

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!

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.

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.

@Damaniel3

6 ай бұрын

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.

A company named UnderWare and they make a product called Brief. Yeah, that’s prime British humor right there.

This is a really interesting topic; deducing the programmers’ situation from their old code. Amazing work as always!

Thanks for these videos. I am especially grateful for your explanations of disassembling games. Keep up the great work.

Very well researched, and explained spectacularly clearly.

Amazing detective work! This was super simple to follow. I love when thought to be deleted data is accidentally archived in games unknowingly.

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!

This is so well done, as with your other code-related videos. Makes me miss my assembly programming days all those years ago.

Quality content!! Also, very clear explanations and demonstrations. Keep it up!

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!

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!

Such a deep understanding of coding, dos and how programmers typically think. Great job man. Really entertaining video!

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. :-)

@DisplacedGamers

3 жыл бұрын

I had a clickbait-y thumbnail (Daphne from the LD capture) made for the video, but I chickened out.

This was really great! Thanks for making it.

I am slowly learning Assembly through these videos, or at least how it works. Keep up the good work.

Nice piece of retro engineering. Investigative first, then technical. All that very well put in a didactic video. Great stuff.

@dredwick

2 жыл бұрын

Didactic video huh?

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. :]

This is my new favourite channel!

That was really enjoyable! Thanks for making this video!

Sensational stuff. Keep it up!

Your videos are the best. Keep up the great work

Awesome video!! thank you so much for sharing this information :)

Great content. Always loved these old school programming tales.

I love your great channel very much.. 👍👌Thanks man.

Great work! Keep up this kind of content!

Great work and great explanation! Thanks a lot

Thanks for another awesome video, detective DG!

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

That was very interesting, thanks for making this video!

Very cool video, looking forward to more. I'm not sure how you don't have more subscribers to be honest :)

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.

Very nice video, thanks for your effort. I love this channel

Neat video! Thanks for uploading!

Great video. Love your stuff.

This is amazing, thanks for the vid!

Just amazing work!

I love this channel so much 😭❤

The comparison with Prince of Persia was good. Now I can, in fact, imagine how wonky the input is!

@dredwick

2 жыл бұрын

I agree. As soon as that reference was made I was like "ok yeah, fck playing DL"

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.

Awesome video =D

Man, you're content is really interesting.

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

this video was amazing thank you so much

The way you reference sources and show broll really adds to the story telling and entertainment

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

@DisplacedGamers

3 жыл бұрын

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!

@jamescurrie01

3 жыл бұрын

@@DisplacedGamers he's definitely joking, hence his own spelling in the comment, all in good fun.

@DisplacedGamers

3 жыл бұрын

@@jamescurrie01 Ahh. I am a programmer, so I didn't notice anything wrong with his spelling. HAHA...Ha.... ha. aah.

@stevenschiro1838

3 жыл бұрын

lol, pretty sure that's sarcasm. You'd be surprised what we find in the comments

@AlmasyAlliances

3 жыл бұрын

@@DisplacedGamers Yeah that was 100% sarcastic. Come on, man. You're a programmer. You should know we all have dry senses of humor. ;)

Great video! Thank you!

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.

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.

@thepuzzlemaster64

3 жыл бұрын

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.

@Scribblersys

3 жыл бұрын

@@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.

@JohnDlugosz

3 жыл бұрын

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.

@JohnDlugosz

3 жыл бұрын

@@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?

@renakunisaki

2 жыл бұрын

@@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.

Interesting! Never knew that Dragon's Lair had sourcecode in it :) Will poke around with this myself as well :)

LOVE YOUR WORK

Amazing stuff. Thanks!

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.

@SianaGearz

2 жыл бұрын

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.

Well done on your rom archeology.

Great vid!

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.

@DisplacedGamers

3 жыл бұрын

That's awesome! If you get it working, make a video!

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

@renakunisaki

2 жыл бұрын

Whomever made those obnoxious bell animations needs to find something better to do.

Excellent video

Very nice video

That was incredibly cool!

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.

@pizzaiolom

3 жыл бұрын

Oh I remember this one hahahaha

@NillKitty

3 жыл бұрын

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.

@renakunisaki

2 жыл бұрын

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.)

@TheAlexSchmidt

2 жыл бұрын

Apparently that cart was just a prototype and the game never got released, so the carelessness is somewhat more excusable. Still pretty funny though.

@DiThi

2 жыл бұрын

@@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.

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.

My favorite college course was an X68000 assembly course. This kind of diving into ROM opcodes is fascinating.

How I love to stumble on high quality content like this

thanks, I have zero understanding of programming. I watched this to help me sleep and it's working!

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?

Hey Displaced Gamers, When was it discovered that the source code was at the end of the rom dump? Never heard of this!

@DisplacedGamers

3 жыл бұрын

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

@unexpecteditem7919

3 жыл бұрын

Thinking like... this got past Nintendo verification, nobody questioned why the padding wasn't just all zeroes, etc. So weird

@ColdPie

3 жыл бұрын

@@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.

@vuurniacsquarewave5091

3 жыл бұрын

@@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.

@vuurniacsquarewave5091

3 жыл бұрын

@@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.

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 KZread 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.

@jimmyhirr5773

3 жыл бұрын

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

@jimmyhirr5773

3 жыл бұрын

Also, Retro Game Mechanics Explained made a video about the SNES's memory mapping: kzread.info/dash/bejne/X4lrmLuvh8fUirA.html

@GimblyGFR

3 жыл бұрын

​@@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.

@jimmyhirr5773

3 жыл бұрын

@@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.

@SianaGearz

2 жыл бұрын

​@@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 sure hope I get to read the source comments for my favorite game someday... where you at, GigaLeaks?

I'm not even a programmer, and this stuff is endlessly interesting!

Damn this was surprisingly fun!

This is what i call good content

that was a sick music intermission

I also saw mentions of PVCS in there. "Programmer Version Control System". An early source code control system.

Brief was an editor that was EVERYWHERE back then.. it rocked.

I was hoping you found a simple hack that improves the control response.

The joke about knowing it was a dev based on misspelling cut me deeply. Great video!

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?

That... That was AWESOME !

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

@SianaGearz

2 жыл бұрын

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.

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.

Man that was great !