Internal ROM Header - Super Nintendo Entertainment System Features Pt. 09c
HTML-код
- Опубликовано: 28 сен 2024
- Did you know most published SNES games have ROM metadata stored inside them? It's all explained right here.
LINKS
Twitter (updates): / retrogamemechex
Patreon (support): / rgmechex
Discord (discussion): discord.rgmeche...
PATRONS
Thank you to all of my patrons who support the channel!
Anthony Losego, Dan Salvato, F. Murmel, Jonathan Aldrich, Ange Albertini, Avi Drissman, Mike Gerow, Larry Koubiak, Tina Wuest, Owen Christensen, Gynvael, Alec Johnson, Buddy, Chris Margroff, Brandan Lennox, Nik, Jason Hughes, Diamond Ice, Chris Post, Cypher Signal, Shannon Potter, Rupix, Gabe S, krivx, Walter Huf, Pixy011, David Spalding, Acceleration Shark, David Johnson, Rory Kelly, Carl Cassler, Joe Mecca, Michael Greb, Kefen, Nightcap, leftler, Scott Beca, 19day, Michael Dragone, John Losego, Travis, Patrick S, Arthur Kunkle, tripper, Nebelwerfer Granitara, Sten, 333Rich333, Glenn hEADcRASH Sugden NPC, Alex Yancey, David Mazarro, Steven, LiraNuna, null, Ryan, Corey Ogburn, Martin Trozell, Garret Kelly, Jake Hickman, Narskogr, Joel Kuhn, Dan Shedd, Sembiance, Xander, 4F Panda, Max Roncace, A Sentient JDAM, Brian Henriquez, Travis Nellor, Zach Hugethanks, dishsoap42, Mikely Whiplash, Yakov, Oxygen Chen, Israel Jacquez, RetroReversing.com, yuriks, Ceres, Jeremiah, jesugtz, Chris Roy, Chris Connett, Mark, Matthew, sapslaj, Jonathan Scott, Xkeeper, Bjoern Hansen, ers35, Daniel Bernard (ReckedCat), Lukas Kalbertodt, Vier Ladair, Bwangry, iPaq, Phil Clayburn, zephyrin, Kit Spindler, Johnathan Roatch, Jeremy Wright, Brandon, Matt Shepard, Felix Freiberger, Sypwn, Niles Rogoff, Kusabi, Reflet, Yann Le Brech, Evan, Eugene Bulkin, Walter Weaver, Gethiox, Articate, Julian Meinking, Julien Oster, buzzert, Steve Losh, Samuel Stoddard, Unkie Herb, HattyJetty, Paige ? Hex, Yeero, Cruz Godar, Linh Pham, Noah Greenberg, Nick Rogers, Bryce, Andrew Yukhymchak, Sean Bryant, John Gabriel, BazBadger, Kyle, Master Knight DH, Tim Romero, Michael B., Eric Loewenthal, Adrian Haslinger, Proxy, Nolan Varani, Thoscellen, Wii2, Daniel Robinson, Hans Jorgensen, waielal, Daniel A.A. Pelsmaeker, Aaron, & Max Gartung!
![State of Play | September 24, 2024 [ENGLISH]](http://i.ytimg.com/vi/fVs0suPHAX8/mqdefault.jpg)
"Nintendo, can you give me a ROM header"
"For dev information"
"Yeeeeees, for dev information"
*Actually uses it to make ROM images without needing to worry about metadata for the physical hardware like a boss*
*Emulation time*
lmfao
Oh certainly for development information.
Dig up information on "Silhouette". If the tale is true, Nintendo developed an internally used emulator called Silhouette that would later resurface on the internet. It bares a striking resemblance to Snes96. It would make sense that the ROM header would need to know information about the state of the machine like this.
Silhouette was leaked by its creator, so the story goes, after Nintendo shut down the development team in the mid 90s.
"Nintendo, can you give me a ROM header"
"For dev information"
"Yeeeeees, for dev information"
*Actually uses it to make ROM images without needing to worry about metadata for the physical hardware like a pirate*
*Emulation time*
I'd imagine these ROM headers were probably also used by Nintendo when actually producing cartridges, to know what board and chips to use.
I believe they were. The SNES dev manual has an entire section on filling out the header before sending the ROM image to Nintendo for production. Honestly, that manual is a fascinating read just from a historical perspective, even if one has no inclination toward software development.
The bit about how there are ways of detecting the expanded header, and that there are two versions of the expanded header was something I didn't know about. Plus, that would explain why EarthBound and the PAL version of Super Mario All-Stars + World had a seemingly random Dev ID of $33.
Great video, as always!
Me too since I was confused where the supposed 16 bytes of the SMW's SNES header ended up missing.
Fun fact: this recordkeeping information is not always trustworthy, nor does it cover all the wild and wacky ways a game's ROM chips can be wired up. Practice, not theory.
You made me think that maybe even back then storage controller was getting cheap so someone just fit in a tiny HDD as the ROM lol Though nowadays I guess there's nothing to stop someone from just releasing a 4GB SNES cartridge even though the system would still only allow ~12MB of RAM, by using a storage controller to load sections of the flash storage onto the RAM.
Especially if you include bootlegs that just didn't bother to fill it in.
@@FlameRat_YehLon There's a video floating around about a similar topic: "reverse emulation" where you run a program and have that program write output data to a "rom" address that the console reads, letting you do some *really* weird things.
@@scorinth I've been hoping to try that sometime. Fascinating stuff.
@@scorinth What I'm talking is more similar to how a flash cartridge works, though. In the case of reverse emulation, the console itself is nothing but a graphics card, but in the case of storage controller, it's similar to how FDS works, the cartridge itself only provides RAM and IO, without providing any additional CPU power.
The game name was not in ASCII, it was in JIS X 0201. For example, Milandra had the following byte sequence in the name area: D0 D7 DD C4 DE D7, which corresponds to ミランドラ
@obsoleteUbiquity I just checked few other games, many of them Japan-only ones, and uppercase Latin is much more frequent, even if the title is pure Japanese with no Western loanwords. Apart of Milandra the only other example of katakana title I found is Panel de Pon, which has CA DF C8 D9 20 C3 DE 20 CE DF DD as the title (パネル デ ポン -yes, with the spaces)
The official developer documentation (US/Western version of the documentation to be exact) shows all text fields in the header should be in ASCII (or JIS 8 bit)
That's what the official guidelines say.
But it's well known that many international character sets are ASCII compatible in the first 128 entries.
Even unicode is ASCII compatible.
If you see an 8 bit codeset with only the first 128 characters in use, it's probably impossible to identify whether this is ASCII, unicode or something else without additional context...
@@vytah I'm sure Bandai used katakana titles (titling themselves "SFX" followed by katakana)
Good follow-up. As always, I have to add my 2 cents about the competitor, the Genesis / Mega Drive, which I actually know about.
Sega put their ROM header after the interrupt vectors, due to their choice of processor (the Motorola 68000) requiring the vectors to be at offset $0. (The system also mapped ROM into address $0, so the vector table was also at address $0 - i.e., ROM offsets in the Genesis are identical to addresses at runtime.)
A more interesting difference is that the Genesis did not checksum the vectors or the header, which removes the need to have the complement in the ROM. The problem, of course, is that someone could change a vector or a header value and the checksum would still verify (note that the game would have to code itself to do this; the Genesis didn't run the checksum automatically).
Finally, unlike the SNES, the Genesis hardware actually *does* read the ROM header at runtime - well, certain models do, at least. The ROM header has to begin with the letters "SEGA" (encoded in bytes corresponding to ASCII with the high bit clear) or else the system won't boot. This was an attempt to use trademark law to prevent unlicensed copies, but a later legal ruling rejected this, setting precedent that a company couldn't claim trademark infringement if the infringement was an engineering requirement in order to use their product. Nintendo had the same idea with their logo for the Game Boy.
6:01 "at offset hex B6" i think you misspoke, but the animation is correct
He also said offset "FF" when he meant "BF" just a little before that. No worries, the animation was right there, too.
@@Darxide23 if you mean at 4:34, i think he actually said that part right. he was saying the **entire** header now goes from FFB0 to FFFF.
The Game Boy had something very similar, even changing the developer ID to 0x33 for an updated version that added the game ID. It also includes a checksum over just the header which the system actually does verify.
On GBA, I think some games even intentionally put wrong information in the header to confuse emulators.
N64 also has a header that includes the entry point, and many games did a trick where they'd return wrong information if the header was read a second time, which would fool copiers and GameShark into using the wrong address.
Actually, just to nitpick a little, the 0x33 developer ID predated the gamecode. 0x33 came with SGB and four letter game ID came with GBC.
@@Gameboygenius Nintendo switched from 2- to 4-letter game IDs sometime in the latter part of 1994. I once kept track of the ID codes to all my SNES/SFC games and noticed by December 1994 games were consistently using 4-character IDs. Supposedly Samurai Shodown (released in Japan September 1994) was the earliest known game to use it.
@@spartonberry To be clear, we are talking about Gameboy specifically here.
Holy shit... I bit off more then I can chew.... I'm still gonna watch the whole thing like I know what's going on.
I've never heard of an SNES game using FLASH memory, only battery-backed RAM for saves. What are some examples of SNES games using FLASH?
There are a couple Japanese horse race betting cartridges that used FLASH memory. JRA PAT was one of them.
Can't recall offhand SNES games using Flash memory for saves (I know the Japanese re-writable Nintendo Power carts used Flash to store the installed ROMs) but Bandai was using EEPROM for saves on some of their Famicom games.
What fonts do you use in these videos? (the formulas remind me of the default article font in LaTeX)
The main font in this series is Mode Nine. You are exactly correct about the formula font, because they were generated with LaTeX!
I swear, you'd except videos of this quality to be made by a large team. You'll get us all through the lockdowns and quarantines Dots!
So let's find out if Super Noah Ark 3D was made by id Software.
I think your last sentence in this video is the most important. It seems odd that a console or microprocessor from that era would care about all that extra stuff.
Haha, region code 3 is Sweden. Owe Bergsten has an amazing story, and it even made it into here. lol
i would love if you explained some super metroid glitches, there is a lot of them.
One of the first videos I actually understood
Cool Vid! It was quite Interesting!
I Got an Idea: How The Super FX Chip works, I Know it can render 3D Graphics and Rotate/Scale Sprites
It's not as interesting as you might think. (unless you like details)
It's got a single special-purpose function to draw pixels (mostly needed because the SNES draws in bitplanes rather than packed pixels, and that's hard to work with)
But other than that it's a RISC CPU.
About the only thing interesting about it is that it has a large instruction cache, and if you can fit your entire program in that it will run a LOT faster...
On the downside? Not that interesting.
On the upside? Given it's a CPU, you can do almost anything you like with it...
There is nothing special on rendering polygons and perform a linear transformation. The difference has more to do with how the chip is specialised for rendering graphics on its own. You _can_ do it on the SNES but it's severily limited since the SNES can do 8-bit times 8-bit math with the CPU and 8-bit times 16-bit with the PPU but especially its graphics format is planar i.e. pretty unfriendly for dynamically rendered graphics (i.e. polygons and linear transformation) unless you're using Mode 7 (which uses linear graphics but you can't use PPU multiplication).
This is where enhancement chips are coming into place: Advanced once like SA-1 (a 65c816 CPU much like the SNES) or Super FX (a RISC with an own processor, often called "Graphical Support Unit") have got shotcuts which transforms linear graphics into SNES planar graphics. They're 10.74 MHz and 21.48 MHz, respectively and transform the graphics in their own way: SA-1 uses a special memory mapping where BW-RAM (Backup Work RAM i.e. cartrdige RAM) is mirrored in a way where a single byte is split into two 4-bits or four 2-bits (depending on whether you're using 4bpp or 2bpp graphics) which is then transformed into planar graphics through Character Conversion DMA whereas Super FX can "plot" linear graphics i.e. takes a value, stores it to a buffer until 8 pixels are filled and then stores it to the graphics buffer. (I know the procedure sounds complicated but there is so much which I can explain in a single sentence. xD ) Another advantage is that they can perform 16-bit times 16-bit multiplication which allows for more precise values especially with trigonometry i.e. rotation.
Naturally, both chips can also be used for general processing. For example, Vitor Vilela, who implemented SA-1 for SMW, moved the sprite logic to SA-1 whereas Yoshi's Island uses Super FX not just to perform linear transformations but also uses it for other repeating tasks such as HDMA tables and OAM tiles but even more general processing such as the camera or player physics (but the CPU still handles sprite logic mostly on its own).
This is also how internet packets are transmitted.
Damn, developers had only 4 bytes of game code? They must've put a *lot* of effort into getting those older games to run as neatly as they did.
I think, he meant "Game ID". It's one of the things Nintendo kept that way since the Gameboy era.
1:41 Why the heck would you put a battery on a cartridge if it doesn't have SRAM?
RTC
@@furrtek Makes sense, though the only two games I know of to use RTCs were RPGs which thus by good design practice needed SRAM anyways. :D (looking at you, Super Ninja Boy, the only RPG franchise on the SNES to still use password saving)
nice.
What if someone actually had the developer ID $33 in a ver 1/2 header?
Developer IDs were allocated by Nintendo, and since Nintendo was the only manufacturer of licensed game cartridges, they likely knew this ID was unused. If some developer had put it there, and it got all the way to certification time, Nintendo likely would have failed their ROM submission for having incorrect developer information in their header.
It's possible that unlicensed cartridges or ROM copiers may have accidentally used Developer $33, but this wouldn't be an issue, as Nintendo wasn't making any of those. Absolutely none of the ROM header is actually used by hardware either. (Hell, the NES didn't even have one...) It is only useful for Nintendo's own internal manufacturing. Emulators *can* make use of the header, but that wasn't the point of it being there, and it doesn't do a very good job of documenting how the cartridge is wired up for emulation.
@@SuperSmashDolls I've only recently learned as well Nintendo did create a header on the NES but the same doc estimated only a third of games used it (so of course that makes it quite unreliable). It was also of course VERY incomplete (being only able to identify mappers as "MMC" or "Other". I mean, even if a large portion of the licensed Famicom library used Nintendo mappers, there was even enough difference between the PCBs. I know at least several iNES mappers cover JUST wiring/hardware variations of MMC3 with little differences that are still significant enough to impact emulation.) Not to mention that the seven third parties who made most of the "licensed" mappers in the set are probably some of the most prominent (Konami mappers alone can probably be called a cluster****, like apparently even the dude programming the Ganbare Goemon Gaiden ending probably messed up which wire-variant Konami was using that day. :P And Namco did their own weird things...)
Jeeses christ, I've never clicked a notification faster in my life.
early gang
Hi
Isn’t it great when someone tells you something in great detail and you still don’t know what’s going on
I have a question about screen drawing for the SNES (or other consoles of the era):
Since they were intended to be used with a CRT, could any 8-/16-bit consoles output line-21 captions? (During gameplay I mean, I know the PS2, etc. support captions for dvd playback, but that doesn't really count.)
It could be used as a simple hud/menu overlay without occupying graphic resources, but from what I gather in your videos the SNES couldn't send the data during v-blank, unless it were possible to override the normal graphic-updating routine for the next frame.
I've wondered that too. The N64 and GameCube allowed a bit more control over the video signal generation, so maybe them?
From what I know of these systems? I would say... No.
Not as an explicit feature, anyway.
And I don't think most of them support directly messing with the video signal in software.
It is _vaguely_ possible that the early Atari systems could do it I guess, just because of how 'to the metal' their video chips were.
I mean, to even draw more than a single line of graphics on an Atari 2600, you have to actively change data in sync with the scanline generation.
The Atari 8 bit microcomputers (And by extension the 5200, which is near identical hardware) could maybe also do it. After all, you control these systems through a 'display list' normally, but can for instance cause the image to roll if you create your display list incorrectly.
There's also been examples of 240 line output even though officially the system is meant for 192 lines, and even someone has managed to get it to do 480i interlaced, even though it (like most computers and consoles of the era) is designed to operate using a signal hack that produces a progressive scan signal. (essentially by ignoring one of the fields and drawing the other one twice. Perhaps part of the explanation for the 'scanline' effect of old hardware, given that half the lines are permanently blank.)
It also helps that drawing blank lines for overscan purposes is an explicit instruction; That means if you draw something other than a blank line in what should technically be an overscan area, you MIGHT get the intended result. (specifically, programming manuals tell you to always insert 3 instructions that produce 8 blank lines each. That's 24 blank lines before you draw an image. It's therefore possible that if you do something other than draw a blank line on the 21'st line, you might get something... That's actually something that would be interesting to test, come to think of it. There are instructions for generating anything from 1 to 8 blank lines, so you could target line 21 specifically - assuming the system's internal logic lines up directly to how a TV signal works.)
Would be pretty hacky, but sounds like an interesting experiment...
However, while you could probably abuse these systems into doing this, you'd gain no benefit from it. Since it lies so far outside their original intended purpose, instead of gaining performance from it, you'd lose performance from all the extra calculations you'd have to do to send out the non-standard signal (non-standard from the console's perspective that is.)
So... Overall I wouldn't count on this being useful on any hardware, even assuming it's actually possible...
But you never know. (I believe there's a handful of computers in existence that can output teletext compatible signals, for instance.)
This is a very good question! Unfortunately, for the SNES and NES at least, the game developer doesn't have enough direct control of the picture processing to produce any signal in the vertical blanking period. The most control you have is enabling force-blanking during the normal drawing period, but not the converse. The PPU is responsible for generating the video signal, and it doesn't have any support for line-21 captions.
For older systems like the Atari 2600, you may have more luck since producing a proper video signal is put more on the developers, but I'm not sure if it could actually pull it off.
@@RGMechEx so, the PPU is generating the sync signals and everything for you, and there's no way to convince it that it's on one line when it's really on another?
@@RGMechEx That's sort of what I expected.
Not enough direct control to hijack the signal, but also not enough flexibility to fully support the format.
Later systems might support it natively or with modded firmware, but then there's no real pros to using it when the hardware is already so capable.
And earlier systems pre-date it being supported by all TVs, so it couldn't have been relied on then, though it might be interesting for modern homebrew.
Concerning the internal ROM name, I think that it’s actually 1 byte Shift-JIS. At least one game stored its name in half-width katakana. The Japanese game "Asameshimae Nyanko" internally stored its name as 「アサメシマエニャンコ」, although this could just be an anomaly.
Look whose back, back again. RGMEx is back, tell a friend.
2:44 Hmmm...I wonder how many games have this set to 0E...
That was an interesting look into the game ROM.
I know that DVDs have a similar 'international' region that's specifically intended for cruise ships and stuff (for some reason)
potentially some internal test or debugging program ?
Now explain the weird port on the bottom of the original NES!
That's where a NES version of the Famicom Disk System was planned to go. I've also heard that years later someone planned to use it to release a modem to allow the Minnesota State Lottery to digitally sell lottery tickets (I wonder if that instigated updated gambling laws to cover online gambling, or if they were already in that process). Needless to saw the law is probably a good reason that got shut down (or Nintendo being Nintendo, and being the last company wanting press about kids using their console to literally bankrupt their parents. Especially for like 1991, decades before lootboxes.)
Video has weird artifact during your ROM map chart... otherwise, I will enjoy your video as always. Thanks for putting hardwork!
I wonder how they used this header, if there was special computers with slots to connect the cart etc..
Great video, thank you! I used the latest header in most of my homebrew SNES games, but I didn't even know there was an intermediate header format for 3rd party special chip games.
The irony of the ROM header is the console ignores it entirely...
Yet emulators depend on it to work correctly. XD
And then there is the Gameboy Advance, which has multiple checks on it's own header; the very existence of the header itself is the first check and won't boot without it (as in zeroes) as it includes the Nintendo Logo bitmap, which is included in the checksum calculation. And the ARM Jump Opcode into ROM Area, of course, which can also be a Jump into RAM on some multiboot ROM.
Its not really ironic, because emulators don't have the cartridge; they have only the ROM image. So there's essentially a bunch of "hardware code" that they have to do themselves that on the NES was done by the cartridge, and they need to guess what that "hardware code" is.
So... How did the SNES deal with header updating? Did it notice?
The SNES is pretty much "dumb" in the manner it handles running a cartridge. The header is specifically metadata to tell Nintendo how to manufacture the cartridges.
If the region encoding is just a byte, can a game genie code be used to modify that and play games essentially region free without modding hardware?
The one Person who disliked this video propably had a memory error to give the video a thumbs down instead of up.
Yeah, they're definitely missing a few op-codes too... like, for example, the op-code to prevent this from getting into your recommended feed is NOT the *_Dislike._*
But rather, there's vertical "Triple-Dot" with the instructions:
Add to queue
Save to Watch later
Save to playlist
Not interested
Don't recommend channel
Report
I cant wait for the register episode
whats the deal with $33? its also used in the GB header since the SGB released
..and I just made an eeprom emulator with a teensy.
Funny Dutch cartridges apparently had their own separate region numbers. I always thought they used exactly the same cartridges and just put a Dutch manual in there (games themselves usually weren’t translated in Dutch back then for as far as I know)
Short but to the point, i feel fully fluent in snes header speak now :) i wonder it any games made use of header data as part of piracy checks etc
Notification squad, nice
I dont understand a thing of it, but i love it and how you al explaine how the games worked.
When I was in school they taught us it was kind of like a envelope you receive in the mail, there's instructions for assembly in the package, but all the internet, surface of the system looks at is the header.
do you mean the complement or 2's complement of the checksum
It's just the one's complement. All the bits are flipped.
What do you use for your visualizations and transition graphics? This looks so slick.
He did a video on how he does this.
After Effects and BizHawk
wow, i can almost program for the snes, i just need to learn how to code now xD
Not only learn to code. But learn to code 65c816 assembly. Which isn't very beginner friendly.
Edit: I meant compared to high level languages like Python and Java. Not compared to other assemblers.
@@mrmimeisfunny Hence why I am starting with 6502 😎
@@Porygonal64 That's... Not much better.
But good for you.
@@mrmimeisfunny I disagree, my first assembly language was 65c816, and I thought it was pretty trivial. Actually, 6502 felt much harder to use to me. Granted, that is after several years of programming in other languages, but the lowest level I'd ever dipped to before that was Java. I'd say that something like ARM is much easier to write code in than 65c816, but that doesn't mean that 65c816 is too beginner unfriendly
65x816 assembly isn't beginner friendly?
Compared to what? XD
Assembly in general is perhaps not very beginner friendly, but I'd take 6502/65816 assembly any day over z80, 68000, or worst of all, by far, x86 assembly. Bleugh.
Now THAT is some nasty stuff...