Thanks for the tool radio shadow. Because it gives the addresses where it finds stuff it should be fairly easy to reverse engineer. Also the language detection is nice and assuming we can get it working on other emus, it might make sense to do it this way instead of through the brlyt editor.
The video modes seem fairly easy to detect..... it's a 57 byte section that usually has the same symbols in it. Unfortuantely there's no header or anything to help detect it, but I can simply patch a wad with each region to get the various values and simply search for all of them. I really wonder why I'm the only one that adds command-line support to their apps. This is a well-made tool and if it were there I wouldn't have to bother re-making it.
I don't think the fds wad will help me much though. As mario said, this really only applies to this one specific game. We'd need someone familiar with fds code to figure this one out. I can tell you some very simple things about the fds though if you want to research it:
1. Despite the obvious pysical differences, the fds add-on is just a glorified nes cart. It interfaces to the cartridge pins on the famicom, just through the auxillary port and shows up to the fc as a nes cart.
2. The fds itself has rom banks similar to those on an actual cartridge. When you insert a disk, what the "carts" programming does is simply copy the disc to these rom banks. Unfortuantely, because it was a early add-on, the amount of rom space is low, and thus the need for two disk games.
3. Although the code in the games *should* be perfectly compatable with the nes/fc, the fact that two disk games have code inside the game itself to prompt for a disk swap, ect.... is what is causing the issues. It could be tricky business to find a generic solution because of this.
4 Fortunately, 90% of the games released on the fds (that don't suck) were also released on the US nes and have no or very small differences.
Anyway, update time.....
I decided to go with lame to decode mp3 files for the tg16-cd injection. I pitty any poor soul who has these sets though as the audio tracks will have to be decoded to wav, read, and then encoded back to ogg. It's a painless process but a very lengthy one. Haven't done much because I was busy today, but I have determined what the experience of injecting a tg16 wad is going to be to the user. Like most of my apps, the rom manager has two path boxes and two browse buttons. The top is for the path to the rom itself and the bottom is for the path to your 5.app folder (in other words the extracted 5.app). To simplify things on my end, any "rom" that has multiple files (neogeo, tgcd, ect) must be zipped up and the program will unzip it itself and put it in a working directory. In the case of tg16cd, we have three possible scenarios..... a standard bin/cue rip or a pre-split set, a non-standard disc image (nrg, mds, iso, ect), or an actual physical disc. In the first case, the user simply points to a zip file that contains the files and the program "automagically" does the rest. In the case of a non-standard image, the user needs to mount the image (via alcohol or something similar) and then manually point the rom path to the disc drive ("D:" "F:" ect). The program will then launch turobrip, which will rip it into a split set that we can work with and treat it like the first type of rom. In the case of a real disc, you simply put it in your cd drive and again, manually type the drive path, and again turobrip will be called first. Of course, the more steps involved, the longer the injection process takes and in the case of tgcd's this could unfortunatel means a few minutes, not a few seconds. In case you download your images instead of creating them yourself, by far the quickest type would be iso/cue/ogg sets, but since those pretty much don't exist, your next best bet would be iso/cue/wav.
