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.
-[Unknown]
Topic: unzip a nes or smc or gba (Read 919 times)