Quote:
Originally Posted by jotd
that would be a good boost for my CDTVload project (like CD32load but for CDTV).
|
I will see if I can push some code to GitHub next week. I need to add some docs to highlight bugs and general usage.
Quote:
|
So your project would be perfect for my CDTVLoad project. And patching games directly using your code is a waste of time anyway, since whdload slaves already do it, plus protection removal plus 2/3 button support, etc...
|
LOL, I think you're being very presumptive in deciding what is or is not a waste of my time.
Slaves are fine for 512K games, but become problematic with a lot of 1MB games that do not have enough RAM left on the system to accomodate the slave and the cutdown WHDLoad implementation as well as the game code itself.
My library is currently 4K in size, 2K of which is a read buffer that could even be dropped if you can do non-buffered reads. I'm willing to bet that is a lot less than your CDTVLoad implementation and thus stands a much better chance of fitting in the constricted 1MB space of a stock CDTV player.
My use case also implements saving and reading to bookmark memory, so that CDTV users can finally save prefs and hiscores in games. The slaves do not support this CDTV specific functionality.
The downside is of course that it is a lot less scalable than leveraging slaves, because it requires manual patch work for every game, although many slaves are open sourced so they can be used as a reference. I think there is space for both CDTVLoad to do the low hanging fruit using slaves, and my solution to bring games to CDTV that could otherwise never work on a stock CDTV.