| |
Krill
Registered: Apr 2002
Posts: 2850 |
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....
|
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
The idea of using the alarm time is crazy! Depending on how many different versions of the loader we're dealing with the test loop shouldn't become too long...
Then again, reading Groepaz comment, there are certain quirks to be avoided. Guess there'll still be enough quirk-free alarm times to be used.
@Groepaz: do these kind of quirks qualify to be deep-checked and wrapped up for a certain document about ending secrets?? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11130 |
haha i'd rather NOT open this can of worms at this point... documenting all the whack CIA behaviour is another lifetime project =D |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
It's just exactly one loader version, with the installer shuffling 2 bits of information to the loader.
So querying TOD alarm for these 4 (actually 3) values shouldn't take long indeed, and the values can be chosen to avoid the quirks.
But then again, $dd03 should suffice for most usecases (demos and games) where the loader is used. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting Groepazhaha i'd rather NOT open this can of worms at this point... documenting all the whack CIA behaviour is another lifetime project =D I knew it all the time: C64 sceners need more than one life! Now off to find that extra life ;) |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
Quoting Zibri$DD03 has been used historically for example by the electronic arts loader of Archon II.
So even dumping all the memory won't help This is not about running any arbitrary program. But if it were, then then TOD approach would probably the best bet to actually "hide" information to be retrieved at some later point. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11130 |
i think the quirky behaviour was related to the alarm time occuring when the counters overflow, ie when they become 0. perhaps also to the previous state, i dont recall :=) |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Sorry for layman question again but isn't there any safe space on drive's RAM? |
| |
Krill
Registered: Apr 2002
Posts: 2850 |
Quoting JammerSorry for layman question again but isn't there any safe space on drive's RAM? Safe yes, but not enough: "[...] 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 [...]".
Then again, $dd03 FTW. =D |
| |
Oswald
Registered: Apr 2002
Posts: 5022 |
so why not ask the drive if you are before uploading the code? |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: so why not ask the drive if you are before uploading the code?
I suppose that would require drive code to actually retreive the two bits and xfer them to the c64. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
