Some resources were split to span across multiple disks and the original installers would concatenate them. Often for CD redistribution they just used the fully reconstituted files with q new installer instead original floppy files. So you would possibly need more than just a list of the file layout of the original floppies.

That said, that may be less of a possibility for the Tandy era games that were often intended to be played from the floppy. Those would sometimes have duplicate resources if the same resources were required at different points in the game.

collector wrote:

Some resources were split to span across multiple disks and the original installers would concatenate them. Often for CD redistribution they just used the fully reconstituted files with q new installer instead original floppy files. So you would possibly need more than just a list of the file layout of the original floppies.

That said, that may be less of a possibility for the Tandy era games that were often intended to be played from the floppy. Those would sometimes have duplicate resources if the same resources were required at different points in the game.

Yeah that's precisely the quandry I find myself in. Games like the Sierra graphical adventures are pretty obviously segmented with resource.001/etc., but something like the old SSI gold box games are a giant mystery.

This is actually a fairly important piece of classic gaming that seems to have been completely overlooked!

The SCI0 games often had RESOURCE.001, RESOURCE.002, etc., which were never meant to be rejoined because of customers that had no HDD. Any duplicate resources needed for floppy play could be added to the separate resource volumes. By the time you get to the SCI1+ games the resource files usually were named RESOURCE.P0, RESOURCE.P02, etc. and would be concatenated into one RESOURCE.000.

Another problem that you may encounter is that some resources may be compressed and the original installer will decompress/extract them.

This something

keenerb wrote:

This is actually a fairly important piece of classic gaming that seems to have been completely overlooked!

This something I have looked into quite a bit over the last few years. I have been analyzing various installers to develop my new installers, Mostly Sierra and Sierra Family, but some non-Sierra installers, too.

You can always try just using a null modem cable to do a file transfer instead of trying to reconstruct the floppies and installing from that.

Does he even have a hard drive in this Tandy?

I would not recommend that anyone play a Sierra game that uses RESOURCE.0XX files unless you can fit them on one disk (pretty much just the Hoyle card games). If you want to torture yourself with the 16-color SCI0 games like King's Quest IV and Space Quest III, put all files on the first disk except for RESOURCE.002 on up. You should use a separate disk for each resource file thereafter. If you have resource.xxx files that are sized to fit on a 360K floppy, you copy two to each 720K floppy if your Tandy has a 720K drive.

Sierra's games are easy, other companies' games are not, you really need a disk listing for them

I do have a hard drive in my 1000TL, but devices like the GoTek emulator really open retro gaming up for a lot of people unfortunate enough to not have hard disks. Sadly it's simply impossible to get some of these games playing even on the Gotek.

Technically it's not a hard drive, it's a LoTech compactflash adapter, but it counts...

Great Hierophant wrote:

I would not recommend that anyone play a Sierra game that uses RESOURCE.0XX files unless you can fit them on one disk (pretty much just the Hoyle card games). If you want to torture yourself with the 16-color SCI0 games like King's Quest IV and Space Quest III, put all files on the first disk except for RESOURCE.002 on up. You should use a separate disk for each resource file thereafter. If you have resource.xxx files that are sized to fit on a 360K floppy, you copy two to each 720K floppy if your Tandy has a 720K drive.

Sierra's games are easy, other companies' games are not, you really need a disk listing for them

you can also pack the resource files together, removing duplicates and get it small enough it might fit with a single resource where two might spill over a disk size.

BloodyCactus wrote:

you can also pack the resource files together, removing duplicates and get it small enough it might fit with a single resource where two might spill over a disk size.

Depends on the game. Something like the Sierra AGI games had duplicate VOL files, but the SCI games that could be played from the floppy drive had any duplicate resources PACKED in the lager RESOURCE.0** files. These files were often large enough to use most of an entire disk. You also cannot tamper with their contents without having to rewrite the MAP file. Again, for the SCI0 games this is not so much of an issue as these RESOURCE.0** were never meant to be concatenated.

Knowing the disk contents for some games will be enough, but the ones that need the files on the disk distribution to be processed/expanded/extracted/joined, etc. you would also need to know this extra information. You can sometimes determine what the installer does if it uses a script file. If there is none you need to track what the installer does during an actual installation. You will need to determine the contents of any self extracting archives. For dealing with compressed files you will need to determine what they were compressed with. Sometimes this is easy as the decompressor used is included on the distribution media.

In any case for some games it will involve more, but a disk listing is a start for any game.

I also think it'll be a far more valuable resource for those games that initially were runnable FROM diskette.

It's less important functionally for Doom original installation disks be recreatable from the doom installation itself, for example. It might be aesthetically pleasing, but Doom was never runnable from floppy to begin with, so there's not a particular reproduction value there, in my opinion.

collector wrote:

BloodyCactus wrote:

you can also pack the resource files together, removing duplicates and get it small enough it might fit with a single resource where two might spill over a disk size.

Depends on the game. Something like the Sierra AGI games had duplicate VOL files, but the SCI games that could be played from the floppy drive had any duplicate resources PACKED in the lager RESOURCE.0** files. These files were often large enough to use most of an entire disk. You also cannot tamper with their contents without having to rewrite the MAP file. Again, for the SCI0 games this is not so much of an issue as these RESOURCE.0** were never meant to be concatenated.

I wrote a tool that did that for you, for agi and sci games. repacked sci games, built map file etc. probably still around somewhere.

quick google shows an old version I wrote here;
http://sierrahelp.com/SCI/Wiki/index.php?titl … ource_Utilities

under 'SCI0 packer v0.1a by Dark Fiber'. its old, and maybe there is better tools around. somewhere i have a more current version from when i was hacking on sci1 as well.

the problems were back then, repacking means new crc/hash that didnt work with sarien/freesci/scummvm.

keenerb wrote:

I do have a hard drive in my 1000TL, but devices like the GoTek emulator really open retro gaming up for a lot of people unfortunate enough to not have hard disks. Sadly it's simply impossible to get some of these games playing even on the Gotek.

Technically it's not a hard drive, it's a LoTech compactflash adapter, but it counts...

If you have a LoTech Compact Flash adapter, then simply transfer the hard drive installs over to the CF card. You can use a CF card reader in the system that contains your games, or transfer the files via Ethernet.

BloodyCactus wrote:

I wrote a tool that did that for you, for agi and sci games. repacked sci games, built map file etc. probably still around somew […]
Show full quote

collector wrote:

BloodyCactus wrote:

you can also pack the resource files together, removing duplicates and get it small enough it might fit with a single resource where two might spill over a disk size.

Depends on the game. Something like the Sierra AGI games had duplicate VOL files, but the SCI games that could be played from the floppy drive had any duplicate resources PACKED in the lager RESOURCE.0** files. These files were often large enough to use most of an entire disk. You also cannot tamper with their contents without having to rewrite the MAP file. Again, for the SCI0 games this is not so much of an issue as these RESOURCE.0** were never meant to be concatenated.

I wrote a tool that did that for you, for agi and sci games. repacked sci games, built map file etc. probably still around somewhere.

quick google shows an old version I wrote here;
http://sierrahelp.com/SCI/Wiki/index.php?titl … ource_Utilities

under 'SCI0 packer v0.1a by Dark Fiber'. its old, and maybe there is better tools around. somewhere i have a more current version from when i was hacking on sci1 as well.

the problems were back then, repacking means new crc/hash that didnt work with sarien/freesci/scummvm.

So you are Dark Fiber? I did notice the mega-tokyo.com link in your sig. If you find your updated version let me know and I can update the Wiki, even if SCI Studio and the new SCI Companion can strip the duplicates, too. Also the change in hash does not matter to DOSBox, of course. At least with SCI it is easy enough to use the original interpreter. Several of the AGI fan games were sloppy with their PIC resources to the point that it created memory/stack problems using the original interpreter.

collector wrote:

So you are Dark Fiber? I did notice the mega-tokyo.com link in your sig. If you find your updated version let me know and I can update the Wiki, even if SCI Studio and the new SCI Companion can strip the duplicates, too. Also the change in hash does not matter to DOSBox, of course. At least with SCI it is easy enough to use the original interpreter. Several of the AGI fan games were sloppy with their PIC resources to the point that it created memory/stack problems using the original interpreter.

I am DF yes. I am slowly going back through some old archives, finding all sort of stuff I wrote. Often I'll find a binary with no source or something or crorrupted zip files. I'll see if I can find a later version of the packer or the agi packer if I can.

If you still have any interest in things AGI/SCI there are some interesting developments that have been occurring over the past year or so.

collector wrote:

If you still have any interest in things AGI/SCI there are some interesting developments that have been occurring over the past year or so.

cool. I've not touched agi or sci since I merged sarien into scummvm and did some odd scummvm commits years ago. These days I'm busy building my own pinball machine. On reverse engineering front I'm more interested in making a compiler for magnetic windows or re'ing the old Angelsoft games but I dont think Angelsoft did an engine (mist, james bond etc) so much as recompile an evolving codebase for each game.

🤣 we are side tracking this thread quite a bit.

BloodyCactus wrote:

🤣 we are side tracking this thread quite a bit.

Not that it really matters since keenerb has started a new thread for his project. Asking for assistance with a new project to document classic floppy disk contents

Anyway, let me know if you would like know about any of the recent developments, even if only out of curiosity.

yeah sure, it would be nice to know. I have not paid much attention since we got it into scummvm. I know there were improvements to sci1 stuff.

I did start working on enabling the agi v1 stuff but there is magic going in in finding the files at the correct sectors on disk that I never figured out and gave up.

Check your PM.