| |
Krill
Registered: Apr 2002 Posts: 2845 |
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: 2845 |
Quoting tlrYou did say "I mean any kind of read-writeable machine state that is very rarely used, intentionally or accidentally. Stock machine, without extra hardware." though. Yes, did not think of accelerators before your post popped up. I just wanted to rule out storing information in external/add-on hardware. |
| |
Frantic
Registered: Mar 2003 Posts: 1627 |
Would it be possible to use redundance? E g to store the information in several places, to increase chances of survival? |
| |
Krill
Registered: Apr 2002 Posts: 2845 |
Quoting FranticWould it be possible to use redundance? E g to store the information in several places, to increase chances of survival? This is what Jacky referred to with "heuristics". =)
So yes, possible, but that's an add-on solution to the problem here. |
| |
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: 2845 |
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: 2845 |
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: 2845 |
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. |
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |