News: 11 March 2016 - Forum Rules

Author Topic: unzip a nes or smc or gba  (Read 919 times)


  • Newbie
  • *
  • Posts: 1
    • View Profile
unzip a nes or smc or gba
« on: August 06, 2021, 05:09:33 pm »
i know that ROMs are not winrar file types, BUT was wondering if there's a program that could dismantle and show hundreds of files, kinda like how a PSP umd is a iso file, then after we unzip, we see files, example, pmf, and if i drag drop into AnyDVDConverter, it can grab audio video or even pictures, and  i choose what file type i want them saved as and i use mp4

on reddit, i saw a discussion of "why on earth would you want to do that?"

same answer as reddit user, i want to see the files plus, listen to the audio that are in ROMs without having to play the whole game

someone mentioned a text editor and a bitmap editor but i wanted something that lists the files like how we can see what's inside a iso

if there's no such thing, then could we somehow develop one??

i know NOTHING about programming


  • Hero Member
  • *****
  • Posts: 5228
  • The cat screams with the voice of a man.
    • View Profile
Re: unzip a nes or smc or gba
« Reply #1 on: August 06, 2021, 07:24:51 pm »
i know NOTHING about programming
Yes, that is clear. But why not just consider the logistics? Some of these games have been around for thirty years or more at this point, and they're enormously popular. If someone could develop a tool like the one you describe, why exactly don't you think someone would have done it by now?

listen to the audio that are in ROMs without having to play the whole game
You are aware that people have been dumping game soundtracks for decades now, right? You can find a big archive of NSF and SPC dumps at and .  But there is no straightforward way of making these.  In the case of NSF files, someone had to analyze the ROM and isolate the specific programming used to generate the music. SPC files are different; the SNES has its own audio chip (the SPC700) with its own memory space, and when running a game in an emulator it is usually trivial to dump the SPC700's memory and get the code that plays a given piece of music in a game. It is considerably more difficult to isolate the code in the ROM that actually writes to the SPC700's memory in the first place. (There's a different music format for that called SNSF that resembles NSF, but it is very uncommon since SPC dumps are usually sufficient.)

Systems like the NES and Super NES are very underpowered and the ROMs they use are extremely small. Developers back in those days had to do everything they could to push the systems to their limits and squeeze as much as they could into every cartridge.  That often means there was simply no room for something convenient like a file system that someone else could disassemble with an arbitrary tool. (The GBA is substantially more powerful, but even in that case most of the time it was more convenient to do without.)

You may also enjoy:
The Newbie Package of REQUIRED Material FAQ: You ask, we answer! Getting Started Section: Newbies Go HERE! Documents Section!
How to ask questions the smart way.
On the Essence of ROM Hacking
Talk with experienced people in our IRC chat and ask specific questions there.
« Last Edit: August 06, 2021, 07:30:20 pm by Jorpho »
This signature is an illusion and is a trap devised by Satan. Go ahead dauntlessly! Make rapid progres!


  • Hero Member
  • *****
  • Posts: 873
  • I am the baldest romhacker
    • View Profile
Re: unzip a nes or smc or gba
« Reply #2 on: August 06, 2021, 09:48:42 pm »
The bottom line is that each of these games store data differently, and it can be located anywhere within the file. The data becomes actual pictures/music/etc during game's code execution. So the closest program to what you have described is an emulator.

You can find some sites with music and images ripped from games. For example


  • Hero Member
  • *****
  • Posts: 3517
    • View Profile
Re: unzip a nes or smc or gba
« Reply #3 on: August 07, 2021, 08:58:24 am »
Wow that is short sighted/limited vision even by reddit standards.

Anyway a file system is something mostly enjoyed by things using floppy discs, optical media or cartridges that are substantially newer and (theoretically) brushing up against certain limits of size.
Most older stuff then uses what would generally be termed "incbin" (as in include in the binary) methods of program creation.

The closest you will get to anything here is the NES' FDS addon (famicom disk system, only in Japan though quite noted for a lot of games and things it did there and outside it) or some GBA homebrew where they could do what they like (though the most common is going to be GBFS ).
Maybe a quirk with Zelda DX for the GB/GBC --

As mentioned above audio on older games (less so on the GBA, hence the Sappy stuff for the overwhelming majority of games, though there are some other things like krawall though I suppose that is a mod/s3m player which was reasonably well known post Amiga) was built around the custom hardware the consoles and to a varying extent cartridges themselves. The music creators from the old home computers on up through the 16 bit era were often immensely skilled programmers in their own right; is all Yuzo Koshiro, of streets of rage franchise fame, but you can pick anything from the commodore 64 stuff to the final fantasy peeps and see it repeated time and time again. Following the introduction of CDs then things went more wave file approaches you could just play back once you understood the format, though even on the N64 (I forget which, one of the earlier videos about where they are getting to a more "hub" area, but they do cover the audio approach used on Conker's Bad Fur Day and it is not basic) it has some tricks used. Even to this day though themed and event driven music is known -- probably one of the more famous examples being one of the Devil May Cry series where audio becomes more action packed depending upon how good the player is such that the creator even apparently quipped about being able to tell which reviewers were good at the game by how they scored the audio. Or my favourite example is for the GBA -- the tetris advance title/minna no soft tetris (only good commercial GBA tetris, hidden mode of worlds not withstanding, and spectacular homebrew versions too) has its main mode actually build up audio layers as you are playing.

I could see a more heuristic approach adopted -- we saw such a thing some years ago for the Atrius' golden sun editors for the GBA that would fingerprint various aspects of files and search for those, and compression detection for the GBA as well, though such a thing is hardly foolproof this side of some strong AI.

We are also seeing the beginnings of N64 decompilation so you might gain something on the N64, though older stuff that was all hand crafted in assembly is not going to have that.


  • Jr. Member
  • **
  • Posts: 87
    • View Profile
    • PPSSPP
Re: unzip a nes or smc or gba
« Reply #4 on: August 08, 2021, 12:28:29 am »
I'm going to go against the norm here and say this is possible, but quite difficult and you'll likely never have results that are "perfect" like with a PSP ISO (although sometimes PSP ISOs have large data files.)

On an ISO or in a zip file, files have a "table of contents."  This is what makes unzipping so straight forward.  The extraction program simply looks at the standardized list of files, which is like an address book.  This list (sometimes called a "file allocation table" if not a TOC or index) tells the name of each file, its address, and how big it is.

That turns out to be all you need to extract the files: you can create separate, normal files of the specified sizes and by copying everything from the address (like a page number in a book.)  Easy.

Older systems especially (but yes, even some PSP games) use a much more arcane approach.  Imagine that person you know that has memorized where every place they ever want to go, every person they know lives, etc. in their head.  There's no address book, and in fact they might not even know the addresses.  Want to get their favorite bookstore?  They'll have to walk there with you to make the right turns and get there.  They can get anywhere - but they're not good with street names.

Well, older systems are just like that person.  They "know" where the files start and end just in the middle of doing things.  They can only remember the place where graphics for a certain character are by going through the motions of drawing that graphic.  In other words, older systems remember files by "muscle memory."

This might sound crazy, but in many cases the developers of the game probably did deal with actual, separate files.  But space was tight, and if you had to pay a fee for every additional letter you write in a notebook, you might avoid making a list of all the addresses too.  Today, many programmers would find it very challenging - to put it kindly - to develop, debug, and bugfix software built this way.  But that's because space is cheap now.

Anyway, I know I've kinda reiterated some of the explanations above about why this is hard.  But now, for why it is in fact possible: static analysis.

A tool that read in the code of the game, broke out and analyzed functions based on the assembly instructions, and then modeled code paths could in theory reconstruct a list of addresses from all this muscle memory.  By analyzing the code paths, it would (at least sometimes) be possible to determine if certain content were being used for palette data, tile data, audio sample data, etc.

Even if that sounds complicated, it's actually oversimplifying the problem.  Often, there are layers of indirection - partial street directions jotted down on post-its within the game, and then referenced later to actually load the content.  Building a tool that can generically handle 90% of content in 90% of games even for a single system this way would be a greater challenge than writing an emulator, I'd say.

But as I said at the start - it is possible.  And maybe some clever use of AI could help, especially for simpler games with less levels of indirection.

If you're interested in becoming a programmer and some day diving deep into a project like this, you'd probably learn a lot from any progress you made on it.