| |
Krill
Registered: Apr 2002
Posts: 3083 |
Keeping a few bits of information in a hostile environment
If not reserving space in RAM, where would read-writable data be most likely to survive throughout the run-time of any random demo or game?
$D800-$DC00 is often overwritten entirely, $00/$01 in RAM are too cumbersome to access.
$DD03 (parallel port data direction register) might be good, or maybe the 2x4 CIA TOD registers at $DC08 and $DD08.
Or are they? What else could be usable for that purpose? =) |
|
... 72 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 3083 |
Quoting Rexa test runner based on a modified VICE that runs a gazillion programs while keeping track of which memory addresses are touched during execution Regular RAM ($0002..$ffff) can be ruled out entirely. What's left are chip registers and similar state.
Register access may be trackable using some brute force machine, but maybe some other tricks exist to access hidden state. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11510 |
I'd use the TODs, write the same data to both CIAs, consider it valid if it matches.
Then again, i wouldnt do this, because it is doomed to fail in one way or another :) |
| |
Krill
Registered: Apr 2002
Posts: 3083 |
Quoting GroepazI'd use the TODs, write the same data to both CIAs, consider it valid if it matches. More than one bit of information would be encoded with the difference between both clocks? =) |
| |
Krill
Registered: Apr 2002
Posts: 3083 |
Some background to this thread's OP (inb4 XY problem):
I'm currently working on the next release version of Krill's Loader, Repository Version 184 - next feature to implement being the hiscore saver.
Now, for that i'd like to store and retrieve 2 bits of information, encoding the type of drive the loader is currently installed on (1541, 1571, 1581), as each of the three executes entirely different and separate loader code with different custom-code plug-in hooks.
Goal is to avoid reserved zeropage/memory addresses and the like because it does without so far (entire ZP can be clobbered between load calls, C-64 side loader code incarnations can be swapped freely), and the 2 bits are required because there is no code space for the drives in question (1541 mostly) to tell their kind prior to uploading and executing the fitting piece of saver code using those custom-code plug-in mechanics. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11510 |
so you just let the user provide a symbol that points to a byte in memory. problem solved. |
| |
Krill
Registered: Apr 2002
Posts: 3083 |
Quoting Groepazso you just let the user provide a symbol that points to a byte in memory. problem solved. How does that "avoid reserved zeropage/memory addresses and the like"? =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11510 |
The symbol can point anywhere, including CIA registers or unused colorram nibbles. It solves the problem 100%. |
| |
Krill
Registered: Apr 2002
Posts: 3083 |
Then it's providing an optional manual override for the loader's default of "use $dd03 to shuffle data from installer to resident portion" to "use user-provided address".
Yeah, i guess i'd have done that. =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11510 |
By now i wonder *what else* did you expect to be able to do? :=) |
| |
Krill
Registered: Apr 2002
Posts: 3083 |
This thread is about finding a sensible default that is not in regular RAM, $dd03 being the best bet so far.
But "maybe some other tricks exist to access hidden state". Something that can (only) be manipulated somewhat indirectly.
Like "VSP channel", but obviously something else that can be set (and doesn't have weird side-effects). |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
