> > > I'm not holding out much hope for the decapping of Toaplan sound chips, though, > but > > > who knows? > > > > yeah, I wouldn't hold much hope either, I'd love to close the book on that driver > > pretty much for good, but I don't think anybody even has the first idea of an > > approach for them now. > > So, would de-capping not be part of a potential solution for those games? I remember > trojaning has also worked on some games, but then again, that's no guarantee, either.
decapping might not help unless they're MASK parts (or if not, we know where the read protect bit is in the chip, and can turn it off without damaging the rest of the data, and have an adapter capable of reading out the data, assuming the read mechanism hasn't been completely disabled in them)
trojaning is unlikely to be an option, it relies on being able to get the CPU to run your own code from external RAM/ROM, but the way the Toaplan games are set up they don't appear ever attempt to execute code from external ROM/RAM, maybe there's a way to glitch them into doing so, but again, such techniques are not known / documented for this type of chip AFAIK, once you're running external code many MCUs also lock out reading from the internal area, or re-enabling it.