| |
Krill
Registered: Apr 2002
Posts: 2844 |
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....
|
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Ah, yes. Didn't read carefully enough. |
| |
Rex
Registered: Sep 2011
Posts: 14 |
If someone is willing to spend the effort I guess it is possible to write a test runner based on a modified VICE that runs a gazillion programs while keeping track of which memory addresses are touched during execution.
It may be a bit tricky detecting when the initialization and kernel loading is complete - which is when you want to start monitoring memory usage.
This should allow for finding the optimal solution. |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
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: 11116 |
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: 2844 |
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: 2844 |
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: 11116 |
so you just let the user provide a symbol that points to a byte in memory. problem solved. |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
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: 11116 |
The symbol can point anywhere, including CIA registers or unused colorram nibbles. It solves the problem 100%. |
| |
Krill
Registered: Apr 2002
Posts: 2844 |
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. =) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
