| |
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: 11108 |
doh. obviously. coffee time! |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
"to tell their kind prior to uploading and executing "
prior uploading the drive is not in default state, to ask it its version the standard way? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Oswald"to tell their kind prior to uploading and executing "
prior uploading the drive is not in default state, to ask it its version the standard way? It's running loader drivecode, which in turn was selected after detecting the drive model. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
You can't write the bits to disk? |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
well another nice place would be the CIA (or VIA in 1541) latch values.
One of the 2 can be set but not read back, so it's totally hidden. So it can be set and then retrieved just by resetting the timer.
On 1541: 1808 1809 or 1c08 1c09 will do nicely.
You can store the latching value in them then reading the MSB or writing the LSB will reset it to the value you previously set and you can read it back :D |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Rastah BarYou can't write the bits to disk? The drive-side code knows the drive's type.
Quoting Zibriwell another nice place would be the CIA (or VIA in 1541) latch values. Timer latches aren't really safe, as they will be overwritten simply by using those timers with arbitrary time-outs.
And drive-side information storage is not the problem, anything in the drive can be considered safe in this thread's context. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
I don't understand the problem very well, but maybe error codes could be used to signal drive type? F.e., let the C64 try to load a nonexisting file and let the loader return a "file not found" error code that is different for each drive type. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Rastah BarF.e., let the C64 try to load a nonexisting file and let the loader return a "file not found" error code that is different for each drive type. Not a bad idea, but not really feasible in practice either.
The byte in question sent by the drive encodes a status/error code ($00: end of file, $ff: file not found) or $01-$fe for current highest consecutive bytestream position (for decrunching while loading with blocks coming in out of order) or $01-$fe for the block size of the file's last block (which of the two $01-$fe options is determined elsewhere).
So other no other values left. If there were, however, reducing the 3 values for a file not found error would take some extra space in the resident C-64-side loader code, plus a definitely non-existing filename would have to be chosen somehow, and then things like no disk inserted can happen, too (although malicious user error is not very relevant in practice). |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quote: Quoting Rastah BarF.e., let the C64 try to load a nonexisting file and let the loader return a "file not found" error code that is different for each drive type. Not a bad idea, but not really feasible in practice either.
The byte in question sent by the drive encodes a status/error code ($00: end of file, $ff: file not found) or $01-$fe for current highest consecutive bytestream position (for decrunching while loading with blocks coming in out of order) or $01-$fe for the block size of the file's last block (which of the two $01-$fe options is determined elsewhere).
So other no other values left. If there were, however, reducing the 3 values for a file not found error would take some extra space in the resident C-64-side loader code, plus a definitely non-existing filename would have to be chosen somehow, and then things like no disk inserted can happen, too (although malicious user error is not very relevant in practice).
Maybe you could send a few extra bits? In Format II I send 10-bits as status. It seems much more reasonable to let the drive keep this state as it, as you note, already knows which type it is. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting tlrMaybe you could send a few extra bits? In Format II I send 10-bits as status. Not really feasible either, as bytes are the atoms there, and i rather not send another byte for each block, then completely ignore it for the most common case of loading. =)
There is one spare bit in the two metadata bytes sent prior to a block's worth of data, though. But it's just one bit. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
