| |
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....
|
| |
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. |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: 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.
So let that one bit determine if it's 1541 or not. The other types can have more drive code for further queries. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting JackAsserSo let that one bit determine if it's 1541 or not. The other types can have more drive code for further queries. Good idea, but... would like to somehow ignore that bit without adding extra code when loading, and pretend-loading an existing file (with just discarding the incoming blocks) just to determine the drive-type doesn't sound very elegant either. =) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting JackAsserSo let that one bit determine if it's 1541 or not. The other types can have more drive code for further queries. Already suggested it via pm, but since I did not fully understand what makes it fail I'll ask again (a little bit adjusted to what JA wrote): couldn't you always send the 1541-save routine and have some watch-dog-alike routines on 1571- and 1581-side that will cancel the send-procedure and request "their" routine when the watch-dog detects the (first bytes of the) 1541-save-routine incoming? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
All in 4 Bytes :=) |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
