DSK to ROM conversion

[5thWolf]

I am hoping to get help with converting my MSX Snatcher game, which is 4 .dsk files to a single .rom file like all my other games.
I found an app called dsk2rom but all I see is the source code and can't find if there is a different way to utilize it or the tool they talk about in the readme called dsk2rom tool. I even tried just using the source download and doing the commands but it doesn't work.
I don't have to use this app, can be another I just can't find any! and guidance would be appreciated to get me in the right direction.

 

[MasterEn]

i did some checking, other people are having trouble with this game as well. there is a sega cd version of the game. that might work for you in the meantime.

 

[Clippy]

I think you're outta luck. I managed to find the actual tool and not just source code and it does convert .dsk files to .rom files but it doesn't look like it can merge them. Besides, I'm not sure if MSX or any of its emulators would even know what to do with forcibly merged files like that. My guess is that it would crash at the disk swap point.

EDIT: Here's the link if you want to give it a go yourself. Note that you'll still need command lines because the author is a linuxhead and those people just need 50 layers of complexity on top of even the most basic of tasks. Fortunately, all the commands are properly explained in the readme and even a basic GUI bitch like myself managed to fumble through it. The only problem I had was that Win 10 Powershell works a little differently than the command prompt of old used to but Powershell itself will tell you how to adjust the commands.

 

[bloodywing]

I fixed the source, you can compile it by typing `make`

 

[5thWolf]

Awesome! What was wrong with it? What was fixed?

Also I ran into this thread yesterday. This person stated that multi dsk was a success for the rom.
https://www.msx.org/forum/msx-talk/software-and-gaming/once-more-dsk-files-rom

 

[Clippy]

Awesome! What was wrong with it? What was fixed?

Also I ran into this thread yesterday. This person stated that multi dsk was a success for the rom.
https://www.msx.org/forum/msx-talk/software-and-gaming/once-more-dsk-files-rom

Weird. That's exactly what I did yesterday and it just wouldn't work. Today I decided to go deeper and fire up my Win 98 emulator and lo and behold, worked like a charm. That thread doesn't answer the question of whether or not a merged game will be beatable (or even playable at all) so while normally I'd post the rom in the game share hub I'll just attach it here.

 

[5thWolf]

I did guess it was due to command prompt not having proper DOS functions!
Going to give it try, is the only issue I have to over come is firmware not supporting larger the 512k rom.
Any suggestions? Would I need a custom firmware? I am using OpenMSX.

Post automatically merged: Jan 31, 2025

Hey @Clippy I found a forum talking about the 512k size and they mention an option for compression to make it 512k. Since I can't get the app to work thought maybe you would be able to see it?
Here is the thread I saw.

 

[Clippy]

I gave it a go and it's true you can compress an image to 512k. So long as it's a single floppy. All 4 floppies merged together can be compressed to a rom that's just over 1600k. All of that seems to be moot anyway. I tried loading the merged rom in both OpenMSX and Retroarch and both refuse to progress beyond the initial screen where the game asks you to press 0 to start or 1 to install.

Looks like there's good reason no-one's made a single Snatcher rom over the last 20 years.

 

[Sumea]

So I setup snatcher msx version myself and I think it has multiple prerequisites like right audio enhancement rom cartridge emulation from emulator and setup, it needs special config files in blueMSX to setup right. Good news is, while the setup has to be done to emulators system files it is no an issue for other games as far as I tested, and helps all Konami games work or have the extended audio capability.

I forgot the details myself but found the solution by googling a little bit. Of course with this setup, you can also play SD Snacher and other Konami/Kojima MSX disk games with enhancements.

 

[AnonymousCookieMonster]

i did some checking, other people are having trouble with this game as well.

Hmmm... i'd think it's age old problems of storage vs the CPU limitations.

Remember the original NES games could only be 20k ROM (and 20k sprites). To get past this they started swapping the ROM portions to access larger areas (called Bank Switching i believe). Which is likely why Megaman doesn't mix enemy sets and has 1 theme area per level.

Now if these are disks as it seems like it might be possible a large portion of the disks are identical (like you'd find in FF7 discs, being textures, models, world map, items, materia usage, etc etc), to which it is looking for specific files only present on different disks (or the same filenames set for an area but the header of the disk is different). So in theory making a larger disk and copying said files and then converting THAT to a ROM may indeed work, depending on limitations of sector count and size.

Though i'm thinking in terms of the Atari's disks, with 128byte sectors and probably only access to 1024 sectors total (or about 128k disks).

But these are just ramblings, not sure if it is helpful or not.

 

[bloodywing]

Awesome! What was wrong with it? What was fixed?

Also I ran into this thread yesterday. This person stated that multi dsk was a success for the rom.
https://www.msx.org/forum/msx-talk/software-and-gaming/once-more-dsk-files-rom

the source wouldn't compile with current gcc some of the stdlib imports were missing

 

[MasterEn]

Hmmm... i'd think it's age old problems of storage vs the CPU limitations.

Remember the original NES games could only be 20k ROM (and 20k sprites). To get past this they started swapping the ROM portions to access larger areas. Which is likely why Megaman doesn't mix enemy sets and has 1 theme area per level.

Now if these are disks as it seems like it might be possible a large portion of the disks are identical (like you'd find in FF7 discs, being textures, models, world map, items, materia usage, etc etc), to which it is looking for specific files only present on different disks (or the same filenames set for an area but the header of the disk is different). So in theory making a larger disk and copying said files and then converting THAT to a ROM may indeed work, depending on limitations of sector count and size.

Though i'm thinking in terms of the Atari's disks, with 128byte sectors and probably only access to 1024 sectors total (or about 128k disks).

But these are just ramblings, not sure if it is helpful or not.

yeah, that does seem to be the problem. the game is split into four separate disks, [or floppy discs, the computer system came out in '83.] and the poster wants them in a single rom for convenience. games nowadays ae packaged as a single item that can be opened up like a box.
i don't know if the msx could understand to open an iso file and use it like its supposed to. it seems to be a computer, so it probably could. but i doubt many people would know how to, due to it not being very popular outside of japan. so, not many english speakers would know how to work on it. you could have someone in japan translate necessary info, but that would take time.
and, i don't think there's much demand for it. most people just take the time to switch disks for the games that they like.
if this was about storage space, then a zip file or 7zip file would help, but i think this something that might just be unfeasible. there's another version of the game that can be played. it might have been easier for most people to use that version, which would explain why this multi-part game is stuck as four disks instead of one single package.

 

[AnonymousCookieMonster]

if this was about storage space, then a zip file or 7zip file would help

I'm talking storage of the disk media the MSX or other 8bit machines use. Storage space today is infinitesimally small in comparison. Gains of 7z over zip on these mediums will not be huge in comparison. Launchers for emulators are far more likely to just extract the files rather than use seamless decompression.

You are looking at an age where you ran at 1.5Mhz 8bit CPU (and on early atari, 90% of processing was just displaying the screen since 2600/5200 didn't have a dedicated video chip, MSX i'm sure is a little better) and had 4-48k ram (16k special purpose for ROM and special uses usually talking to controllers), and a max floppy size of 320k until they moved to the 3 1/2" disks where 720k and 1.44Mb became the standard.

 

[MasterEn]

I'm talking storage of the disk media the MSX or other 8bit machines use. Storage space today is infinitesimally small in comparison. Gains of 7z over zip on these mediums will not be huge in comparison. Launchers for emulators are far more likely to just extract the files rather than use seamless decompression.

You are looking at an age where you ran at 1.5Mhz 8bit CPU (and on early atari, 90% of processing was just displaying the screen since 2600/5200 didn't have a dedicated video chip, MSX i'm sure is a little better) and had 4-48k ram (16k special purpose for ROM and special uses usually talking to controllers), and a max floppy size of 320k until they moved to the 3 1/2" disks where 720k and 1.44Mb became the standard.

i'm not that familiar with early computers. i know that storage space is mostly irrelevant for the most part today. until about 20 minutes ago, i never even knew what the msx looked like. the only time i've heard of it is in relation to metal gear 1 and 2.
i know that early computers use floppy disks if need be, but this started with the original poster wanting to combine all the parts of a game into one package. i'm guessing that's why the game is in 4 parts. i don't know. this post is the first time i learned about this game existing.
apparently this game is good, but no one has yet made a single package file for it. it seemed like they want to keep the entire thing together so there was no chance of losing the data and to not have to go through the task of swapping discs. it should be possible since the ff9 port on the switch goes smoothly from one disc to another without skipping a beat.
i'm at a complete loss as to why this game is stuck like it is, it shouldn't be hard to fix, but i guess it's not popular enough to warrant someone working on it. and according to bloodlywing, the one person who did left out important files at some point.
i didn't know that about the atari. i could see that being a thing with the 2600 but you would think the "superior" console would have something like a video chip. just another thing to add to the immense suck factor that it has.

 

[AnonymousCookieMonster]

'm not that familiar with early computers. i know that storage space is mostly irrelevant for the most part today


i know that early computers use floppy disks if need be, but this started with the original poster wanting to combine all the parts of a game into one package. i'm guessing that's why the game is in 4 parts. i don't know. this post is the first time i learned about this game existing.

Drive/floppy space was very very limited. First drive was 10Mb and was the size of a washing machine.

Due to limitations there were fixed character lengths to express a filename. Typically it was accepted as 8+3 (8 main name, 3 extension). Databases were just as bad too.

To take the smallest amount of space while still being useful. If you have 11 bytes for the name, add size and sector start (2 bytes each) that's 15 bytes, throw one on for flags for the OS and you get 16. Date/time permissions, long filenames, large file support, etc. All utterly unused. So a 128 byte sector could safely house 8 file entries.

Filesystem design is fascinating...

8-Bit Technical Resource Center: ATR: chpt.2: Disk Operating System (D:)

Design of the FAT file system - Wikipedia

en.wikipedia.org

 

[MasterEn]

Drive/floppy space was very very limited. First drive was 10Mb and was the size of a washing machine.

Due to limitations there were fixed character lengths to express a filename. Typically it was accepted as 8+3 (8 main name, 3 extension). Databases were just as bad too.

To take the smallest amount of space while still being useful. If you have 11 bytes for the name, add size and sector start (2 bytes each) that's 15 bytes, throw one on for flags for the OS and you get 16. Date/time permissions, long filenames, large file support, etc. All utterly unused. So a 128 byte sector could safely house 8 file entries.

Filesystem design is fascinating...

that's insane. i've heard about the first computers being the size of rooms, but it seemed like they got small pretty quick.
so, if the name of a file takes up space, why does an empty text file say it is zero bytes in size?

 

[AnonymousCookieMonster]

that's insane. i've heard about the first computers being the size of rooms, but it seemed like they got small pretty quick.
so, if the name of a file takes up space, why does an empty text file say it is zero bytes in size?

Everything has to use whole sectors, so when you make a directory at least 1 block has to be allocated to it. (DOS systems have 512 minimum sector sizes, but can go as big as 128k)

So while the filename does take space of 1 file entry in the directory, unless you have a lot of files usually those don't get completely full.

The directory entry does indeed specify the name of a file, it's size, etc. But if you don't have anything allocated to a file, then it doesn't have to reserve any sectors, so it could just point to the EOF sector to begin with. Afterall the directory entry will specify how large the file is. (excess bytes in a sector are simply truncated, if you append to a file they are added to the end til you need an additional sector, in many ways it's like RAM management).

(FAT uses an allocation table to determine which sectors are used, as well as which are the next sector... If you play with it directly you can make a sector point to itself, making an infinitely sized file, not that useful since all 512 byte blocks are identical, but null... is useful...)

 

[MasterEn]

Everything has to use whole sectors, so when you make a directory at least 1 block has to be allocated to it. (DOS systems have 512 minimum sector sizes, but can go as big as 128k)

So while the filename does take space of 1 file entry in the directory, unless you have a lot of files usually those don't get completely full.

The directory entry does indeed specify the name of a file, it's size, etc. But if you don't have anything allocated to a file, then it doesn't have to reserve any sectors, so it could just point to the EOF sector to begin with. Afterall the directory entry will specify how large the file is. (excess bytes in a sector are simply truncated, if you append to a file they are added to the end til you need an additional sector, in many ways it's like RAM management).

(FAT uses an allocation table to determine which sectors are used, as well as which are the next sector... If you play with it directly you can make a sector point to itself, making an infinitely sized file, not that useful since all 512 byte blocks are identical, but null... is useful...)

hmm... so, if i understand it correctly, the bytes still exist, but if the file is empty, they are stored somewhere else until it is necessary to jump them over to the file, right? and that happens if sector [which is a block?] is filled up enough?

 

[AnonymousCookieMonster]

hmm... so, if i understand it correctly, the bytes still exist, but if the file is empty, they are stored somewhere else until it is necessary to jump them over to the file, right?

The entry exists which takes up space (of a file entry, but that was likely already allocated) which is probably 32bytes. However no sectors are allocated for an empty file.

But you CAN fill up a drive with empty files. Make enough empty files that enough is allocated to the directory. I've done this on an experimental FAT12 system, takes a lot of files pointing at nothing, but it can be done. Though filling the space of a drive is a lot faster if you make files of 1 byte... as 511 bytes (plus 32) are wasted with each file.

 

[MasterEn]

okay. so the bytes from the file name are stored in the directory. they would be added to the file if it has a sector assigned to it, which is what stores the bytes in general. did i get that right?

 

[AnonymousCookieMonster]

okay. so the bytes from the file name are stored in the directory. they would be added to the file if it has a sector assigned to it, which is what stores the bytes in general. did i get that right?

No. The filename and everything about it (when it was made/modified, who owns it, how big it is, permissions, etc) remains in the directory structure.

The file's sectors (pointed to by the directory) is just the file's raw data.

Directory:
["Filename", DATE, Size, ID, Sector XYZ]

Sector XYZ:
"Star Wars - A new hope, by George Lucas.
In a galaxy far far away, the evil empire is hunting down Leia who is on a 'diplomatic mission' "... etc etc

 

[MasterEn]

oh, okay. i don't know much about the specifics how a computer operates in detail, this is all new to me. so, directory for file name, property data and permissions and such; and sectors are for the data contained in the file itself.

 

[Clippy]

Whoa, things got technical in my absence. To think all of this stemmed from OPs desire to play an MSX game. Unfortunately as I expected, smushing floppies together has produced an unusable rom. Perhaps it would be possible to do if we could extract all the assets on the floppies, get rid of duplicate stuff, cobble everything else together and carefully construct a ROM that way. This is not only a long shot in theory but in practice it would require access to source code since we'd have to rewrite quite a bit of it. Catch all the pointers and jumps to sectors/addresses and redirect them to their new locations in our Frankenstein's ROM. That's all assuming the resulting data could be crammed and compressed into 512Kb to begin with. I'm no programmer, my understanding is layman's at best and ignoramus's at worst so chances are I'm barely half-correct in my assumptions but it looks like a herculean task either way.

The game does offer an option to install so I thought that maybe we could try and make an installation to a virtual HDD and then share that the same way most PC-98 games are distributed on the Internet but I'm not gonna lie, the scant few descriptions I found on how to even attempt such a thing were way too dense for me; I couldn't make heads or tails of any of it.

So I figured that a difference in approach is in order. The whole thread exists because OpenMSX is touted as the best MSX emulator out there. Maybe it's true, I have no idea, but the problem is that that the freeware BIOS you get with it is incapable of playing floppies. Maybe instead of wrestling with the floppies I could wrangle the emulator itself. And boy, did I ever wrangle that thing. In order to make full use of OpenMSX's capabilities you need a system ROM package which you can find in this thread. I wasn't entirely sure where I was supposed to put the files but the emulator is uncharacteristically helpful in that regard. If you go to Machine->Test MSX Hardware->Open system wide ROMs folder it will point you exactly where it wants those ROMs. After that you can test hardware again to make sure everything's OK. Don't worry about some things listed as not working - I still have 2 extensions listed as not working but that seems inconsequential. Now we need to pick a machine that supports floppies. Go to Machine->Select MSX machine. Seeing as Snatcher is a game released well into the life of the MSX line of computers I picked 'openMSX Team Boosted MSX2+ JP' though I assume quite a few other models will be up to the task as well. Once you've found your machine click 'Replace current machine' and you're pretty much done there. There will be a new button 'Make this the default machine' above the list and filters which you can click just so you don't have to repeat the procedure every time you fire up OpenMSX. Once you're done with all of that you can just go Media->Disk Drive A and find your floppy. I played the game for a few minutes and by the looks of it Disk0 serves as a boot disk and Disk1 is the intro. After you get to Disk2 you should be free from having to swap floppies for a while. One final tip. The game can be really slow. F9 toggles fast forward. Enjoy.

Oof, this developed into an unexpected wall of text. I know this isn't exactly what you wanted, @5thWolf but a man's gotta know his limitations sometimes. If someone figures out how to make an MSX HDD and install Snatcher onto it then that would be great but considering there are no images of such nature floating around on the web (or at least I couldn't find one) I assume that it's either excruciatingly hard or downright impossible.

 

[MasterEn]

AnonymousCookieMonster knows his stuff. i learned a little bit more about how a computer functions because of this. makes me appreciate the hard work people put into programming stuff a lot more.
it should be possible, but the most likely outcome is someone just porting all of the game data and doing some reconfiguring to make it run naturally on a pc. the msx might not be able to run the game properly if it is recompiled into a single file.

 

[5thWolf]

I found this guy talking about a CD-ROM mod. Maybe this could help in the future of C64 emulation. I am assuming this would help with all file size limitations once you create an image.