PS1/2 How can I compress multiple games into one CD? Is there a special software out there?
- Thread starter Jesse32213
- Start date
- Views 1,663
- Replies 14
- Likes 1
Depends on far too many factors:
Depending if you use a rom or ciso structure will mean you'll need a emulator for either the rom or the iso.
For compression you'll need enough (RAM)space to (virtually) extract the contend to.
Depending on what games you want to combine, and for what system there might be tools for it.
Since almost everything has DRM in it, you'll need a crack for the games or a jailbroken (sometimes modchipped) console.
- Is there DRM? this might be removed first or reconfigured.
- Is it for PC, Switch, PS5, etc? this influences the structure and filesystem.
- You can trim (removing unused space of an rom.
- You can setup a compressed folder (like zip).
- You can use Ciso (compressed iso).
Depending if you use a rom or ciso structure will mean you'll need a emulator for either the rom or the iso.
For compression you'll need enough (RAM)space to (virtually) extract the contend to.
Depending on what games you want to combine, and for what system there might be tools for it.
Since almost everything has DRM in it, you'll need a crack for the games or a jailbroken (sometimes modchipped) console.
JaapDaniels above took the basics and it does vary between platform, though things with CDs (or more generally file systems) are far far far easier than any non specialist flash cart might be on most cartridge based things older than the DS and thus can be spoken of in a more generalised manner.
There are multiple areas to consider in this.
1) The basics of multidisc approaches, which will be per platform and might well have trouble games.
Short version is most old games have a disc, a list of files it knows about and can run accordingly.
You would then need something to select what game is run. Usually this takes the form of a homebrew loader as the basic systems don't tend to embed such a thing in themselves (no need and it would only help the pirates, not to mention might be impossible without a system revision), and indeed mod chips might not either (at that point something usefully defined as a custom firmware needs to kick in). Depending upon the system this might be something well known, and indeed known since the time (the original xbox for instance has a lot of nice tools).
The trouble comes in two, maybe three areas.
i) Ordinal file loading and raw file/location loading
ii) File name/directory name collisions
iii) File system limitations
i) Seen still on the DS (New Super Mario Brothers being the most famous) but the general principle is to speed things up rather than having to grab the file system, find npc_texture_56.tex (possibly in a subdirectory), figure out where the file is on the disc and then load it you instead say get me file 68 and it does that right away. This can be done at programming level or an after the fact optimisation (more on that shortly as well) when the game is finished and ready to go (makes it more annoying if you are in the middle of programming and have to get authorisation to change a name). You now cram double the files on disc and if both games use this concept and fun ensues.
The PS1 though more so PS2 did also see raw LBA (logical block address, a means of speeding things up at the cost of storage space which could also be a thing you contemplate in this) reads/raw sector reads, most famously in a lot of the Square (Enix) games for audio, wherein for whatever reason (anti piracy, anti music ripping, ease of coding... we may never know and for the purposes of this discussion don't really care) the devs reached out and grabbed data raw from the disc itself. Some DRM systems will also do things like this but most of those are hit on the head by whatever patches have long existed for them and outside of some modern PC things then the checks don't return useful data as much as act as a check so you can lose them.
ii) data.bin game.exe setup.dat... you will never know what game those belong to in my example as such things are so common and what devs will pick when they just needed a name at 5:40pm on a Friday. Get two games (even more so if the games are sequels with copy-pasted code/engine/general setup as might be common in multi game per disc setups) with the same names for directories, files and more and even if i) is not an issue you face for this then you get its cousin.
iii) So you saw ii) above and thought I will just put each game in its own subdirectory and call that instead. Great until you find file names, which includes directory names, have say 255 maximum characters (still a problem for some Windows things, or Windows things with spaces in the name) or only however many subdirectories deep as the devs did not anticipate such things.
File system optimisation, or indeed disc read optimisation. The most famous example in these circles is probably knights of the old republic on the original xbox -- discs are physical media and if you have to reposition the laser between reads that takes time someone could probably use a stopwatch to measure, rather unfortunate when you are screaming along in something almost measured in gigahertz. To that end the file arrangement on disc was actually tweaked so file pairs (and more) were nearby and able to be loaded quickly, the naive dumping tools/iso reconstruction of the basic xbox dumping tools went alphabetical instead. Consequently some earlier dumps have longer load times on burned disc than they did on stock and hard drive loading.
It is usually more of a thing for certain speedrun challenge classes and cartridge based systems but multi games (usually referred to as ? in 1) that might have officially been made can also be a thing people look into here, though most are interested in going the other way and chopping the games they don't want out (sometimes ? in 1 might be the only version for the region, or fix certain bugs) and autobooting the one they do. For the most part though anything that is on a cartridge without a file system (which is the GBA on back) then better hope your flash cart can handle it or your game is on the vanishingly small list of simple things to adapt.
2) Size limitations.
Even with the best will in the world a CD is only going to have about 850 megabytes if you overburn it and maybe find out how to use some fancy modes to bump up size for data already with its own parity checking inbuilt or less concern for read errors. More likely you are dealing with less than that, though some occasions can do more if it is some kind of SD drive emulator adapter and the baseline pointers for the system top out at a theoretically higher level (32 bits which is 2 to the power 32, and very little sense going less for most things, is around 4 gigs of raw data which is rather more than the CDs can handle, 64 bits is considerably larger still but there they will tend to opt for 48bits as a point, and that is not counting sector addressing).
Enter what was classically known as game/ROM/iso ripping, yes it gets confusing and annoying to search for as a result of the other common meaning. Not all files on a disc are used by the game (devs leave things in as easter eggs, carelessness, lack of concern -- it is not like you are in cartridge world paying for a bigger chip to store it all when on CD...) and not all files are used by the game as you wish to play it (boo hoo no online multiplayer for me, oh no can't see the end credits animation, maybe you only want a given minigame). Here people delete, relink*, replace and more (compression being a notable one but more on that shortly).
Piece of trivia a lot of people know as well is Final Fantasy 7 the entire game is on every disc and the only difference is the CGI cut scenes, indeed disc swap tricks can be performed to this end).
*relinking is a lesser seen concept outside the PSP really with UMDgen having it baked in I believe but the principle works for everything really (including cartridges with not filesystem but I will skip that one for now). Not all files can be deleted and replacements might be tricky at various levels (for one replacing a 50 meg file with a 3 meg equivalent might net you some space back but 3 megs multiplied by 10 is still real space over "deleting" things entirely, copyright is another concern**), however if there is a functional equivalent in the game itself you can point everything at that and delete all the others such that the game always grabs the file it wants. Pointers I usually describe as like a contents page of a book (think the file system above having file names and locations like a chapter name and page number), usually people want to add more data or shrink something so I liken it to removing a bunch of physical pages and then having someone dutifully count something, or have the number changed by someone else and editing the original location it was at (common enough if you want to hack an existing hack). Here though pointers would be more akin to sending everything to the same place, presumably valid data that avoids a crash when loaded (or saves you having to recode the game to handle it) and thus allowing a blanking effort elsewhere.
**back on the DS we did used to rip games (common 32 meg/256Mbit GBA era flash carts could run things but as things even early on started at 64 megs, the first non Golden Sun Team working ROM was Castlevania which included a rip to lose the opening cut scene and drop space from 64 megs to fit on said 32 meg things) and one of the smallest SDAT sound files was from Goldeneye (made for some interesting effects in game when you sword swings sounded like gunshots) which is hard to distribute as a patch or batch file to unpack, delete whatever and rebuild as was common ( https://gbatemp.net/threads/gbatemp...ew-2016-edition-out.73394/page-2#post-1799596 is a mirror of and even older still post/thread on the subject but the principles apply).
Compression.
Two general approaches, maybe three depending upon how you want to view it.
i) CISO. Short for compressed iso, basically takes the ISO and compresses it down. Useful on later systems where you can possibly have it decompress itself (the PSP being notable in this, the Wii having some interesting quirks here on the storage side of things if you go into scrubbing) or some kind of drive emulator/flash cart that can also do it behind the scenes as it is loading or whatever (saw this on the GBA for instance with some later flash carts, and presumably could be done with drive emulators). Related to this is most different region games will have largely the same data (probably still going to be the same art, code, stats and more, just text that is changed) so if you use a multi file aware level of compression (one of the major claims to fame of 7zip over various of its competitors) you can fit more ROMs on a disc if that is something your setup can handle.
ii) File level. Many systems will feature boring and basic compression of some form that can be tacked on (and possibly automatically handled). Some will do this, and much like above will usually be reflected in load times within the game.
iii) Format aware recompression. Aside from large archives used within games (some games pack all files into archive formats and operate from them for whatever reason) then usually done for audio and video stuff (which tends to be compressed by its very nature and thus gain minimal compression if boring and basic stuff from ii) is used). The human ear hears up to about 22KHz if you are young and have not been to many concerts/building sites and because maths you need double the sample rate to encode it (though even that has flaws and benefits from higher on occasion or wants further limitations on capture), the human voice tops out for most at rather lower levels meaning (also one reason music sounds awful down the phone) you can get away with lower for voice or just take the hit on music. Similar things exist for video where you might get a few more macroblocks, blurriness, frame rate drops... depending upon what you do. Some audio stuff aside for console games this is quite the advanced trick, PC less so. There are any number of things you can do this for (average European game maybe featuring 5 languages, can lose the 4 you don't speak) but at this point we are in full bore ROM hacking territory, the ripping link above being part of a thread/guide I have on it if you did want to go there, and most rippers and multi game makers dip out about now.
3) External factors
Some more modern PS1 emulators will convert the audio into something lossy (say an MP3) and what was essentially a 40 meg wave file (raw CD audio after all, about that for the average 3 minute backing music track) before is now a 3 meg MP3 (or something more modern and smaller/better quality**). It is unlikely you will want to hack the game to support such things, if indeed it is even possible (some games will be slamming the CPU for everything it has and you can't then afford to do what would have been a fairly demanding task on the hardware on top of that), where some flash carts, optical drive emulators, modern takes on flash carts (see CD audio stuff for the megacd), modern mappers for things or the like can do it trivially. Going the other way I saw similar things in the now lost art of PC game compression installers when the PS1 was almost still current.3
**playing on an emulator it is possible with various means but most likely onboard Lua support ( https://fceux.com/web/help/LuaFunctionsList.html https://tasvideos.org/LuaScripting ) to have the emulator halt/mute in the background and the PC flash up with some PC remake, high res AI upscale rerender, later port cut scene, or audio if you want to go that way and return you afterwards.
Short version. Most systems for which this is vaguely a possibility will have nice tools you can use if you can happily add ISOs/their constituent files to and make one super iso with selection screen, assuming it is not inbuilt as part of flash carts or custom firmwares. Might not work with all games but will work with a lot of them. Size is a concern but poke around the files (they usually have nice names, extensions http://wiki.xentax.com/index.php/Game_File_Format_Central https://wiki.multimedia.cx/index.php?title=Category:Game_Formats https://www.romhacking.net/documents/[469]nds_formats.htm ) and you might be able to find something to delete, overwrite, relink or otherwise subvert to still have something you want to play. You might also have the option to compress things further, usually at a cost to load time.
You can go far deeper into this but for most purposes with current mod methods, emulators, cheapness of discs (assuming it is even a disc you are burning and not a file you are loading via some other means) then such things are of limited use for most these days and thus most don't go there any more.
There are multiple areas to consider in this.
1) The basics of multidisc approaches, which will be per platform and might well have trouble games.
Short version is most old games have a disc, a list of files it knows about and can run accordingly.
You would then need something to select what game is run. Usually this takes the form of a homebrew loader as the basic systems don't tend to embed such a thing in themselves (no need and it would only help the pirates, not to mention might be impossible without a system revision), and indeed mod chips might not either (at that point something usefully defined as a custom firmware needs to kick in). Depending upon the system this might be something well known, and indeed known since the time (the original xbox for instance has a lot of nice tools).
The trouble comes in two, maybe three areas.
i) Ordinal file loading and raw file/location loading
ii) File name/directory name collisions
iii) File system limitations
i) Seen still on the DS (New Super Mario Brothers being the most famous) but the general principle is to speed things up rather than having to grab the file system, find npc_texture_56.tex (possibly in a subdirectory), figure out where the file is on the disc and then load it you instead say get me file 68 and it does that right away. This can be done at programming level or an after the fact optimisation (more on that shortly as well) when the game is finished and ready to go (makes it more annoying if you are in the middle of programming and have to get authorisation to change a name). You now cram double the files on disc and if both games use this concept and fun ensues.
The PS1 though more so PS2 did also see raw LBA (logical block address, a means of speeding things up at the cost of storage space which could also be a thing you contemplate in this) reads/raw sector reads, most famously in a lot of the Square (Enix) games for audio, wherein for whatever reason (anti piracy, anti music ripping, ease of coding... we may never know and for the purposes of this discussion don't really care) the devs reached out and grabbed data raw from the disc itself. Some DRM systems will also do things like this but most of those are hit on the head by whatever patches have long existed for them and outside of some modern PC things then the checks don't return useful data as much as act as a check so you can lose them.
ii) data.bin game.exe setup.dat... you will never know what game those belong to in my example as such things are so common and what devs will pick when they just needed a name at 5:40pm on a Friday. Get two games (even more so if the games are sequels with copy-pasted code/engine/general setup as might be common in multi game per disc setups) with the same names for directories, files and more and even if i) is not an issue you face for this then you get its cousin.
iii) So you saw ii) above and thought I will just put each game in its own subdirectory and call that instead. Great until you find file names, which includes directory names, have say 255 maximum characters (still a problem for some Windows things, or Windows things with spaces in the name) or only however many subdirectories deep as the devs did not anticipate such things.
File system optimisation, or indeed disc read optimisation. The most famous example in these circles is probably knights of the old republic on the original xbox -- discs are physical media and if you have to reposition the laser between reads that takes time someone could probably use a stopwatch to measure, rather unfortunate when you are screaming along in something almost measured in gigahertz. To that end the file arrangement on disc was actually tweaked so file pairs (and more) were nearby and able to be loaded quickly, the naive dumping tools/iso reconstruction of the basic xbox dumping tools went alphabetical instead. Consequently some earlier dumps have longer load times on burned disc than they did on stock and hard drive loading.
It is usually more of a thing for certain speedrun challenge classes and cartridge based systems but multi games (usually referred to as ? in 1) that might have officially been made can also be a thing people look into here, though most are interested in going the other way and chopping the games they don't want out (sometimes ? in 1 might be the only version for the region, or fix certain bugs) and autobooting the one they do. For the most part though anything that is on a cartridge without a file system (which is the GBA on back) then better hope your flash cart can handle it or your game is on the vanishingly small list of simple things to adapt.
2) Size limitations.
Even with the best will in the world a CD is only going to have about 850 megabytes if you overburn it and maybe find out how to use some fancy modes to bump up size for data already with its own parity checking inbuilt or less concern for read errors. More likely you are dealing with less than that, though some occasions can do more if it is some kind of SD drive emulator adapter and the baseline pointers for the system top out at a theoretically higher level (32 bits which is 2 to the power 32, and very little sense going less for most things, is around 4 gigs of raw data which is rather more than the CDs can handle, 64 bits is considerably larger still but there they will tend to opt for 48bits as a point, and that is not counting sector addressing).
Enter what was classically known as game/ROM/iso ripping, yes it gets confusing and annoying to search for as a result of the other common meaning. Not all files on a disc are used by the game (devs leave things in as easter eggs, carelessness, lack of concern -- it is not like you are in cartridge world paying for a bigger chip to store it all when on CD...) and not all files are used by the game as you wish to play it (boo hoo no online multiplayer for me, oh no can't see the end credits animation, maybe you only want a given minigame). Here people delete, relink*, replace and more (compression being a notable one but more on that shortly).
Piece of trivia a lot of people know as well is Final Fantasy 7 the entire game is on every disc and the only difference is the CGI cut scenes, indeed disc swap tricks can be performed to this end).
*relinking is a lesser seen concept outside the PSP really with UMDgen having it baked in I believe but the principle works for everything really (including cartridges with not filesystem but I will skip that one for now). Not all files can be deleted and replacements might be tricky at various levels (for one replacing a 50 meg file with a 3 meg equivalent might net you some space back but 3 megs multiplied by 10 is still real space over "deleting" things entirely, copyright is another concern**), however if there is a functional equivalent in the game itself you can point everything at that and delete all the others such that the game always grabs the file it wants. Pointers I usually describe as like a contents page of a book (think the file system above having file names and locations like a chapter name and page number), usually people want to add more data or shrink something so I liken it to removing a bunch of physical pages and then having someone dutifully count something, or have the number changed by someone else and editing the original location it was at (common enough if you want to hack an existing hack). Here though pointers would be more akin to sending everything to the same place, presumably valid data that avoids a crash when loaded (or saves you having to recode the game to handle it) and thus allowing a blanking effort elsewhere.
**back on the DS we did used to rip games (common 32 meg/256Mbit GBA era flash carts could run things but as things even early on started at 64 megs, the first non Golden Sun Team working ROM was Castlevania which included a rip to lose the opening cut scene and drop space from 64 megs to fit on said 32 meg things) and one of the smallest SDAT sound files was from Goldeneye (made for some interesting effects in game when you sword swings sounded like gunshots) which is hard to distribute as a patch or batch file to unpack, delete whatever and rebuild as was common ( https://gbatemp.net/threads/gbatemp...ew-2016-edition-out.73394/page-2#post-1799596 is a mirror of and even older still post/thread on the subject but the principles apply).
Compression.
Two general approaches, maybe three depending upon how you want to view it.
i) CISO. Short for compressed iso, basically takes the ISO and compresses it down. Useful on later systems where you can possibly have it decompress itself (the PSP being notable in this, the Wii having some interesting quirks here on the storage side of things if you go into scrubbing) or some kind of drive emulator/flash cart that can also do it behind the scenes as it is loading or whatever (saw this on the GBA for instance with some later flash carts, and presumably could be done with drive emulators). Related to this is most different region games will have largely the same data (probably still going to be the same art, code, stats and more, just text that is changed) so if you use a multi file aware level of compression (one of the major claims to fame of 7zip over various of its competitors) you can fit more ROMs on a disc if that is something your setup can handle.
ii) File level. Many systems will feature boring and basic compression of some form that can be tacked on (and possibly automatically handled). Some will do this, and much like above will usually be reflected in load times within the game.
iii) Format aware recompression. Aside from large archives used within games (some games pack all files into archive formats and operate from them for whatever reason) then usually done for audio and video stuff (which tends to be compressed by its very nature and thus gain minimal compression if boring and basic stuff from ii) is used). The human ear hears up to about 22KHz if you are young and have not been to many concerts/building sites and because maths you need double the sample rate to encode it (though even that has flaws and benefits from higher on occasion or wants further limitations on capture), the human voice tops out for most at rather lower levels meaning (also one reason music sounds awful down the phone) you can get away with lower for voice or just take the hit on music. Similar things exist for video where you might get a few more macroblocks, blurriness, frame rate drops... depending upon what you do. Some audio stuff aside for console games this is quite the advanced trick, PC less so. There are any number of things you can do this for (average European game maybe featuring 5 languages, can lose the 4 you don't speak) but at this point we are in full bore ROM hacking territory, the ripping link above being part of a thread/guide I have on it if you did want to go there, and most rippers and multi game makers dip out about now.
3) External factors
Some more modern PS1 emulators will convert the audio into something lossy (say an MP3) and what was essentially a 40 meg wave file (raw CD audio after all, about that for the average 3 minute backing music track) before is now a 3 meg MP3 (or something more modern and smaller/better quality**). It is unlikely you will want to hack the game to support such things, if indeed it is even possible (some games will be slamming the CPU for everything it has and you can't then afford to do what would have been a fairly demanding task on the hardware on top of that), where some flash carts, optical drive emulators, modern takes on flash carts (see CD audio stuff for the megacd), modern mappers for things or the like can do it trivially. Going the other way I saw similar things in the now lost art of PC game compression installers when the PS1 was almost still current.3
**playing on an emulator it is possible with various means but most likely onboard Lua support ( https://fceux.com/web/help/LuaFunctionsList.html https://tasvideos.org/LuaScripting ) to have the emulator halt/mute in the background and the PC flash up with some PC remake, high res AI upscale rerender, later port cut scene, or audio if you want to go that way and return you afterwards.
Short version. Most systems for which this is vaguely a possibility will have nice tools you can use if you can happily add ISOs/their constituent files to and make one super iso with selection screen, assuming it is not inbuilt as part of flash carts or custom firmwares. Might not work with all games but will work with a lot of them. Size is a concern but poke around the files (they usually have nice names, extensions http://wiki.xentax.com/index.php/Game_File_Format_Central https://wiki.multimedia.cx/index.php?title=Category:Game_Formats https://www.romhacking.net/documents/[469]nds_formats.htm ) and you might be able to find something to delete, overwrite, relink or otherwise subvert to still have something you want to play. You might also have the option to compress things further, usually at a cost to load time.
You can go far deeper into this but for most purposes with current mod methods, emulators, cheapness of discs (assuming it is even a disc you are burning and not a file you are loading via some other means) then such things are of limited use for most these days and thus most don't go there any more.
I only know one multigame tool, special made for the gamecube. it needs a swiss-tool (you can make the modchip yourself, the only console i know with an opensource modchip) or a modded wii.
https://multigame-iso-creator.en.lo4d.com/windows
https://multigame-iso-creator.en.lo4d.com/windows
- Joined
- Sep 13, 2022
- Messages
- 7,363
- Trophies
- 3
- Location
- The Wired
- Website
- m4x1mumrez87.neocities.org
- XP
- 22,711
- Country
There comes many exceptions if you're trying to fit as many games onto a single CD-R, such as compressing audio/video to nulling out and/or removing data, and just praying for sure that the game doesn't crash in the process.
I think the issue is the lba tables, so files need to be moved manually, one by one, or something. it's been at least 10 years since I tried doing it. I had a few failures along the way.
Post automatically merged:
edit: I just found the image of the multi game image that I did. it works perfectly from what I could tell.
Last edited by godreborn,
- Joined
- Sep 13, 2022
- Messages
- 7,363
- Trophies
- 3
- Location
- The Wired
- Website
- m4x1mumrez87.neocities.org
- XP
- 22,711
- Country
- Joined
- Sep 13, 2022
- Messages
- 7,363
- Trophies
- 3
- Location
- The Wired
- Website
- m4x1mumrez87.neocities.org
- XP
- 22,711
- Country
- Joined
- Sep 13, 2022
- Messages
- 7,363
- Trophies
- 3
- Location
- The Wired
- Website
- m4x1mumrez87.neocities.org
- XP
- 22,711
- Country
I'll have a look in a bit.
Post automatically merged:
Nope, sorry, can't find it. XBINS doesn't list PS1 or PS2 anywhere.
EDIT: Nvm found it
Last edited by SylverReZ,
- Joined
- Sep 13, 2022
- Messages
- 7,363
- Trophies
- 3
- Location
- The Wired
- Website
- m4x1mumrez87.neocities.org
- XP
- 22,711
- Country
- Joined
- Sep 13, 2022
- Messages
- 7,363
- Trophies
- 3
- Location
- The Wired
- Website
- m4x1mumrez87.neocities.org
- XP
- 22,711
- Country
Similar threads
