Hey Bonknuts, when/if you see this. What about getting by with upgrading the game to Arcade Card ? I'm trying to see, is that not enough for these real difficult cases, if not, why not, etc. and so it must be something custom (like another Games Express) ?
If we are talking about Tengai Makyo (the game meniotned in the thread), there are two versions of it:
1) CD, which is what I have always counselled to base extractions from, because you can easily extend RAM usage into the SCD area, which will be untouched.
2) SCD, which was a re-release a few years later, which tried to address load times. I would advise to try not to use this one, as it's not clear what its memory footprint is.
If on the other hand, we are talking about Emerald Dragon again/still (even though it has its own thread), then there a few problems with Arcade Card, which stem from the complexity of CDROM games in the first place:
1) According to my information, it already uses Arcade Card memory if it detects it. Disabling such use would be a LOT of trouble, and then would come the problems of the repurposing
2) If a game did not use ACD memory, then great, the ACD can be used. But ACD storage would really only be viable as text storage, because it can't be used to execute code from. So it wouldn't solve problems like print functions. Also, you would still need ACD access routines which must reside in main memory, and that memory may not be easy to find.
3) Using ACD memory for text storage could be theoretically OK, but still has some issues which need to be surmounted:
- First, it needs to be stored on the disc in the first place. You need to find that storage. And the way that code and data are stored on the disc currently is like a gigantic ROM file, which gets paged into memory a few blocks at a time. You can't just shift something over without huge consequences. You could theoretically extend the end of the CDROM data track, but you'd better hope that existing CDROM access code in the game doesn't reference MM:SS:FF or LBA addresses on disc - rather that they would address tracks (which would be fine, as they would shift).
- While the text could be stored in ACD as either compressed or uncompressed, it would need to be copied to main memory prior to print.
-- If compressed, you would need to copy to the same compress buffer in main memory as would have previously been used (ie. a text page loaded from disc), and decompress as per usual. This is probably the more difficult choice.
-- If stored in ACD as uncompressed text, then the string locate (or 'pre-print') function could be replaced with ACD accesses. In such a case, instead of addressing a text page to find compressed data, and then uncompressing into a RAM buffer, and sending the start of the string to the print function, there could instead be a lookup (based on superblock, sub-block, and string #) to a lookup table to find out ACD location instead. Then all that would be needed would be a block-move into the uncompress buffer (to the start of the buffer !), and send that address to the print function. Of course, this becomes complicated if the superblock-subblocks are expected to already be decoded into the uncompress buffer at the time of print (a very real possibility). Then you wouldn't have the hook to the uncompress to support you, and you would need to worry about how big the uncompressed strings are in memory - and whether your uncompress buffer was big enough to hold the block in the first place.
So, it's not so easy.... because even imagining all of these problems, and devising theoretical techniques to deal with them is really only about 30% of the work. The techniques would then need to be implemented, debugged, and as is always the case, unforeseen events happen along the way.
