| |
Krill
Registered: Apr 2002
Posts: 2821 |
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....
|
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
I think we’re getting to the point that you should let the user store the returned config value during loader install then ask them to pass that value to the save-installer. Anyone can keep track of that byte.. |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting JackAsserI think we’re getting to the point that you should let the user store the returned config value during loader install then ask them to pass that value to the save-installer. Anyone can keep track of that byte.. We have passed that point already some way up in this thread. :)
I am defaulting to $dd03 at the moment, planning to add a variable to the custom drive code upload parameter structure to override/provide drive type. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
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).
Switching codes $00 and $ff for one of the drives might provide one bit of information. |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting GroepazAll in 4 Bytes :=) Oh noes, that's not much /o\ Got the impression that there's still more free space, at least for drivecode on the non-1541-drives.
So I take it if you look at it spot on the details, especially the code on c64-side would've to be changed too much in order to make a watch-dog-driven handshake for uploading the save-routine work.
On an abstract level, I still think this would be most elegant ;) |
| |
Flavioweb
Registered: Nov 2011
Posts: 442 |
I guess i haven't really understood the problem here... but i try: why don't reserve a file name/file number which return a byte containing drive model value? |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Can't you just always upload the highscore saver right away, that is, together with the loader code?
Or is there a backwards compatibility issue? Or do you want to save RAM? Or disk space?
How does a random user know in the first place that the loader has been installed on the drive? |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting Copyfaultcouldn'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? Quoting GroepazAll in 4 Bytes :=) Quoting CopyfaultOh noes, that's not much /o\ Got the impression that there's still more free space, at least for drivecode on the non-1541-drives. The main problem with such an approach (it's nothing to do with watchdogs, though) is that it would most likely add bytes either to the 1541's regular loader code or the C-64-side resident loader code. Bytes i don't have or don't want to afford. =)
The custom code upload part re-uses the C-64->drive routines normally used to send the filename.
Some kind of receive-rejection could be implemented by the receiver permanently asserting the data line and the sender detecting that the bit it put on the bus isn't the same it reads back.
Works only with one of the two bit values, though, but should work with a canary byte that is neither $00 nor $ff.
I am still not quite certain if this can or cannot work without the mentioned drawbacks...
But then i think the simple and safe solution of having the user shuffle over the drive type from installer return values struct to save/code upload parameter struct is acceptable.
Not as elegant, of course. =) |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting Rastah BarSwitching codes $00 and $ff for one of the drives might provide one bit of information. So one type of drive would send $00 and mean "GOOD", the other would send $00 and mean "EVIL", and vice versa for $ff? How would the C-64 side know which is which? :)
Quoting Flaviowebwhy don't reserve a file name/file number which return a byte containing drive model value? Would have to be implemented on all drives, and 1541 doesn't have space for that code.
Quoting Rastah BarCan't you just always upload the highscore saver right away, that is, together with the loader code? No, there are just 2KB of RAM in the drive, almost all of it used for load operation.
Quoting Rastah BarHow does a random user know in the first place that the loader has been installed on the drive? User in this context means a person consciously using the loader library and putting loader calls all over their program, starting with "jsr install". They should know. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Quoting KrillQuoting Rastah BarSwitching codes $00 and $ff for one of the drives might provide one bit of information. So one type of drive would send $00 and mean "GOOD", the other would send $00 and mean "EVIL", and vice versa for $ff? How would the C-64 side know which is which? :)
By this clumsy method of trying to load a nonexisting file. The C64-side code expects a "file not found" error and when it receives $00 it knows it's dealing with a 1571 drive, while $ff means 1581.
Quoting Rastah BarCan't you just always upload the highscore saver right away, that is, together with the loader code? Quote:No, there are just 2KB of RAM in the drive, almost all of it used for load operation.
So the goal is to replace loader code by highscore saver code?
Quote:User in this context means a person consciously using the loader library and putting loader calls all over their program, starting with "jsr install". They should know.
Oh, I see. I was thinking that the problem was something like this: someone ran a demo or played a game that installed the loader. Then he swaps disks because he now wants to play another game, which has a hiscore saver. And now your hiscore saver code has to be uploaded. Does that make any sense, or not? |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting Rastah BarQuoting Krill[How would the C-64 side know which is which? :) By this clumsy method of trying to load a nonexisting file. Then the regular load code would also have to do this prior to loading an expected (but not guaranteed) existing file.
Quoting Rastah BarSo the goal is to replace loader code by highscore saver code? Yes. Swap out loader code to C-64 memory, swap in saver code, save, swap back loader code.
Quoting Rastah Barsomeone ran a demo or played a game that installed the loader. Then he swaps disks because he now wants to play another game, which has a hiscore saver. And now your hiscore saver code has to be uploaded. Does that make any sense, or not? Running another program usually involves resetting the computer, which would cause the drive-side loader code to reset the drive as well. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
