| |
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? =) |
|
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
$0100-$011f
Only very special demo parts or very complex games will use this memory |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Or the reset vector maybe? $fffc/d
You could store both on TOD, $fffc/d and $0100/0101 and do some heuristics to determine which value has not been overwritten |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
Very interesting question. I would say there aren't such, especially if you do not narrow your selection. For example are we talking about games with copy protection? There are some copy protection schemes were whole memory is overwritten during loading starting from load address in order to reach $01 for example and change it accordingly. Secondly are we talking about loading from tape or disk?
But you know all of that ;)
Do you need whole bytes or just bits?
How about reset vector assuming you can disable kernal rom? (we wrote the same idea with JackAsser at the same time)
How about using external ram from attached devices like disk drive ram. Action Replay and clones have interesting memory access model too.
Just my 5 cents... looking forward to other ideas. |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
The upper bits in the $00 (DDR) could often be used. IIRC Mr. Z said that he often used that for his cheat flags. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting JackAsser$0100-$011f
Only very special demo parts or very complex games will use this memory Or anything printing numbers using ROM calls. =) $0100 is FBUFFR, where numbers converted to strings are stored.
Quoting JackAsserOr the reset vector maybe? $fffc/d
You could store both on TOD, $fffc/d and $0100/0101 and do some heuristics to determine which value has not been overwritten Reset vector is sometimes written to when the adjacent NMI and IRQ vectors are set up by simply copying to them in a loop.
True about the heuristics, but those need good locations in the first place. :)
Quoting AlexCDo you need whole bytes or just bits? Yes. =)
I mean, if a register is written to, one can expect all of its bits to be changed, even if just one is required. But it's about any information, at least one bit, the more the merrier.
Copy protections can be ignored. The "hostile" wordage was just for effect. :)
I mean any kind of read-writeable machine state that is very rarely used, intentionally or accidentally. Stock machine, without extra hardware.
And for some narrowing-down, loading (tape/disk/user port) is under control and can be ignored (hence my idea of using $DD03). |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting tlrThe upper bits in the $00 (DDR) could often be used. IIRC Mr. Z said that he often used that for his cheat flags. Could some accelerators fail with that? |
| |
tlr
Registered: Sep 2003
Posts: 1714 |
Quoting KrillQuoting tlrThe upper bits in the $00 (DDR) could often be used. IIRC Mr. Z said that he often used that for his cheat flags. Could some accelerators fail with that?
Not sure. I seem to remember that flash8 uses the corresponding ones in $01 but I might be wrong. A '0' in a $00 bit will make the corresponding output effectively forced as a '1' so it may or may not be a problem even if used.
You did say "I mean any kind of read-writeable machine state that is very rarely used, intentionally or accidentally. Stock machine, without extra hardware." though. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting tlrYou did say "I mean any kind of read-writeable machine state that is very rarely used, intentionally or accidentally. Stock machine, without extra hardware." though. Yes, did not think of accelerators before your post popped up. I just wanted to rule out storing information in external/add-on hardware. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Would it be possible to use redundance? E g to store the information in several places, to increase chances of survival? |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting FranticWould it be possible to use redundance? E g to store the information in several places, to increase chances of survival? This is what Jacky referred to with "heuristics". =)
So yes, possible, but that's an add-on solution to the problem here. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
Ah, yes. Didn't read carefully enough. |
| |
Rex
Registered: Sep 2011
Posts: 14 |
If someone is willing to spend the effort I guess it is possible to write a test runner based on a modified VICE that runs a gazillion programs while keeping track of which memory addresses are touched during execution.
It may be a bit tricky detecting when the initialization and kernel loading is complete - which is when you want to start monitoring memory usage.
This should allow for finding the optimal solution. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Rexa test runner based on a modified VICE that runs a gazillion programs while keeping track of which memory addresses are touched during execution Regular RAM ($0002..$ffff) can be ruled out entirely. What's left are chip registers and similar state.
Register access may be trackable using some brute force machine, but maybe some other tricks exist to access hidden state. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
I'd use the TODs, write the same data to both CIAs, consider it valid if it matches.
Then again, i wouldnt do this, because it is doomed to fail in one way or another :) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting GroepazI'd use the TODs, write the same data to both CIAs, consider it valid if it matches. More than one bit of information would be encoded with the difference between both clocks? =) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Some background to this thread's OP (inb4 XY problem):
I'm currently working on the next release version of Krill's Loader, Repository Version 184 - next feature to implement being the hiscore saver.
Now, for that i'd like to store and retrieve 2 bits of information, encoding the type of drive the loader is currently installed on (1541, 1571, 1581), as each of the three executes entirely different and separate loader code with different custom-code plug-in hooks.
Goal is to avoid reserved zeropage/memory addresses and the like because it does without so far (entire ZP can be clobbered between load calls, C-64 side loader code incarnations can be swapped freely), 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 the fitting piece of saver code using those custom-code plug-in mechanics. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
so you just let the user provide a symbol that points to a byte in memory. problem solved. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Groepazso you just let the user provide a symbol that points to a byte in memory. problem solved. How does that "avoid reserved zeropage/memory addresses and the like"? =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
The symbol can point anywhere, including CIA registers or unused colorram nibbles. It solves the problem 100%. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Then it's providing an optional manual override for the loader's default of "use $dd03 to shuffle data from installer to resident portion" to "use user-provided address".
Yeah, i guess i'd have done that. =) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
By now i wonder *what else* did you expect to be able to do? :=) |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
This thread is about finding a sensible default that is not in regular RAM, $dd03 being the best bet so far.
But "maybe some other tricks exist to access hidden state". Something that can (only) be manipulated somewhat indirectly.
Like "VSP channel", but obviously something else that can be set (and doesn't have weird side-effects). |
| |
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 |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
That's a neat trick. =) TOD alarm is basically never used. And it's pretty much what i meant with "hidden state".
Should work on SX-64 as well, despite no clocked TOD, yeah? :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
$DD03 has been used historically for example by the electronic arts loader of Archon II.
So even dumping all the memory won't help unless you also save the value contained there before the first run, otherwise the game will start but a lot of sprites will be corrupted because the value of DD03 is later used to XOR the initial data of part of the sprites.
You won't notice this until the first one to one fight.
:D
I would hide also one in some unused SID or CIA or VIC registers. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Quote:recover the stored value by writing all possible values to TOC time in a loop
That will take a while .... :=) Also, there is some strange quirk with the alarm time in that the interrupt doesnt trigger in certain constellations (i forgot the details, the programs in the test repo might tell) so this is probably not useful for the general case and for arbitrary data. |
| |
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: 11114 |
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: 2839 |
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: 2839 |
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: 11114 |
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: 2839 |
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: 5017 |
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. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Oswaldso why not ask the drive if you are before uploading the code? As i said, because there is no space in the drive code. There is just a bare minimum routine to receive and execute custom code, the rest is taken by the actual loader code to do its thing. Any kind of extra handshake to decide which drive type it is would take quite a few bytes. Too many! :)
Quoting JackAsserI suppose that would require drive code to actually retreive the two bits and xfer them to the c64. The drives know the two bits (they encode 1541 or 1571 or 1581). Just querying that information before upload is too expensive for me on 1541. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
Cant you redirect the error handler and return the info in the error channel? mmh |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting GroepazCant you redirect the error handler and return the info in the error channel? mmh There are no such things once the loader drive code is running. It sits on bare metal and implements its own serial bus protocol. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
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. |
| |
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 :=) |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
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: 2839 |
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: 447 |
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: 2839 |
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: 2839 |
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: 2839 |
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. |
| |
Rastah Bar
Registered: Oct 2012
Posts: 336 |
Thanks for the explanations! |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Had to look up heuristics, and found this very useful definition...
 |
| |
map
Registered: Feb 2002
Posts: 27 |
Quoting KrillBut 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. =)
From all mentioned approaches this one sounds the best from my point of view. Leave the responsibility to find a good spot in the memory to the integrator of the Loader. Agreed, that it is less elegant.
Maybe having the Drive code to send some identification would be a good aproach as well as mentioned before but will cost not available resources and creates overhead. |
| |
Sparta
Registered: Feb 2017
Posts: 38 |
While waiting for Krill's saver plug-in, try out Sparkle 2's hi-score file saver! :) |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quoting CruzerHad to look up heuristics, and found this very useful definition...
lol for the "useful definition", anyway:
Heuristic comes from ancient greek and it's root is the verb EURISKO which means "to find".
A heuristic algorithm is a non deterministic one, is an algorithm, usually slower but sometimes needed, which employs a search function for a predetermined pattern or behaviour. Our brain for example uses both but mainly the heuristic method.
In short, any heuristic program or line of thought, basically does an "educated guess". |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
The better your heuristics, the more (H)EUREKA! moments you'll have. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Meanwhile, i have actually managed to query drivetype before uploading the appropriate piece of custom code. =)
All without any extra code on 1541 side or in the resident loader portion.
So no hiding nor manual shuffling-around of those two bits required. \=D/ |
| |
JackAsser
Registered: Jun 2002
Posts: 1989 |
Quote: Meanwhile, i have actually managed to query drivetype before uploading the appropriate piece of custom code. =)
All without any extra code on 1541 side or in the resident loader portion.
So no hiding nor manual shuffling-around of those two bits required. \=D/
Ossom!! |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Quoting KrillMeanwhile, i have actually managed to query drivetype before uploading the appropriate piece of custom code. =)
All without any extra code on 1541 side or in the resident loader portion.
So no hiding nor manual shuffling-around of those two bits required. \=D/ This is worth a huge HOORAY!!!
Kudos for getting it done... and thanks for putting effort into it.
Shall I use that "most elegant"-phrase more often ;) ?? |
| |
Zibri
Account closed
Registered: May 2020
Posts: 304 |
Quote: The better your heuristics, the more (H)EUREKA! moments you'll have.
Precisely.
Eureka comes from the same verb (Eurisko) and it's the first person of the past tense: Literally: "I FOUND [it]" :D |
