made this little test and while you can only set one
cartdata address you can use run() to do it again with breadcrumbs
and such. this is both a stupid way to store data and the biggest
brain way possible. does anyone think this is a bug?
It definitely sounds like unintended behavior - I suppose it could be a problem if someone used it to very slowly fill the target's hard drive with persistent cart data files? Or worse, if someone wrote a cart to very slowly corrupt all the other cartridge data on the target's computer.
Not sure the most elegant way to patch it out - maybe put a restriction of 16 cartdata ids per cart during each time the cartridge is launched?
A malicious cart can already create infinite files using 'printh' with filename param.
Is there a max length on breadcrumbs? If not, then this seems like a fancy and portable way to circumvent the cartdata size limit for save games. You could read and concat the 256 bytes into the breadcrumb string, with some other state info at the start.
Extremely slow, though - and you can already store over 16 kiB by using a separate cartridge's cart ROM with cstore() and reload(), so it's not that practical...
I don't think you can cstore() and reload() in BBS though right? If you can't then this method might be good if you just wanted an additional page or two of 256 bytes.
[Please log in to post a comment]
