| |
Krill
Registered: Apr 2002
Posts: 2839 |
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....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Sounds to me like you are spending a lot of effort an solving a problem that doesnt exist =) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Please refrain from posting unhelpful non-information.
The problem is somewhat solved (unless somebody has a better idea than $dd03), and now we're at the esoteric academic what-if "fun" part. |
| |
Martin Piper
Registered: Nov 2007
Posts: 634 |
Quote: 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? =)
Use $100-$107 and check for identical values to detect corruption?
Or use the Vice's memmap to detect what memory isn't written to during the game/demo. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Martin PiperUse $100-$107[...]Vice's memmap to detect what memory isn't written to Stack bottom has been ruled out (FBUFFR), and does VICE "memmap" also log chip register access? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
it provides a seperate map for i/o, yes |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Hmm...
Bit5 of $D016 doesn't do anything but (being described as a VIC reset bit) seems to be "connected".
So, unless someone finds a brandnew vic trick using this bit, it could be used to store one bit of information. Downside (sadly rendering it unsuitable imo) is that most routines "out there" don't care about this bit position and are likely to destroy it sooner or later...
Will continue searching ;) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Copyfaultmost routines "out there" don't care about this bit position and are likely to destroy it sooner or later... Indeed. That goes for everything VIC though, it's not uncommon to call PANIC at $E5A0 (yes, they called it that) to reset all VIC registers after pressing space. =) |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
It's not uncommon to call $fda3 either, which breaks both the $00 and $dd03 approaches but perhaps not the TOD approach. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting tlrIt's not uncommon to call $fda3 either, which breaks both the $00 and $dd03 approaches but perhaps not the TOD approach. Yes, but calling $FDA3 causes the loader drive code to reset to ROM, so that should not happen in a finished production. =) |
| |
aeeben
Registered: May 2002
Posts: 42 |
Use TOD alarm time:
TOD registers may be easily overwritten if a program inits the CIA state from a lookup table.
But if you write your important number to TOD alarm time instead of TOD time, by setting bit 7 in $dx0f...
"$dx0f Bit 7: 0 = Writing into the TOD register sets the clock time, 1 = Writing into the TOD register sets the alarm time."
...you can then later recover the stored value by writing all possible values to TOC time in a loop and checking which write sets Bit 2 (1 = Time of day and alarm time is equal) in $dx0d |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
