| |
BastetFurry
Registered: Jul 2005
Posts: 88 |
Hijacking LOAD, SAVE and the others
How is this best done so that most normal programms wont notice? |
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
just use the kernal vectors |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
Quote: How is this best done so that most normal programms wont notice?
You have D64 mounter source which does that already and you still need to ask? Check Mount() in d64plgin.asm + everything in de00.asm. Or do you mean something with limitations like "without Retro Replay or some other cartridge"? If so, then define "most normal programs" and find a memory area which is unused by any of them and put patch code there. Good luck in finding that memory, especially if your normal programs include anything packed. |
| |
enthusi
Registered: May 2004
Posts: 675 |
Strange enough I feel like most programs dont use tapebuffer-area. Well depending on HOW small your alternative loader is going to be :) At least you could start from there and have some smart code in it that branches dynamically?
Dunno :) |
| |
BastetFurry
Registered: Jul 2005
Posts: 88 |
@TNT:
Yeah, i want to give sans RR a try.
I thought of some small programm that disables Interrupt and then uses some code+puffer (Maybe i can even work pufferless?) stored under Kernal.
How long does the card wait till it thinks nobody is talking to it?
@Groepaz:
Should work as long as no programm tryes some funny stuff with them.
@enthusi:
If the puffer area is long enough for diabling kernal and enabling it again.
But the space from $0334 to $03ff should be big enough for that.
I have never before played around with the kernal, so, please let me ask my (maybe) stupid questions before i sit there and wonder why nothing works. ;) |
| |
TNT
Account closed
Registered: Oct 2004
Posts: 189 |
I've never tried if you can leave MMC/SD card "hanging" for a long tme between reads. You'd better check Sasq's BIOS source to see how he does it without extra RAM. http://www.nightmode.org/mmc/
Decrunchers generally copy the data from $ffff downwards before decrunching, so RAM under kernal isn't that safe place. Actually there isn't any safe place, as decrunchers use low memory for code, so it isn't safe either.
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
its possible to run code at the loose $dxxx area if you use the correct screen setup ;) |
| |
BastetFurry
Registered: Jul 2005
Posts: 88 |
Hrm, if some stupid decruncher kills the code then the user have to live with it for now.
But it should be save for non-packed data as most normal programms use the kernal.
Its just some kind of proof of concept after all as everybody on forum64 is crying for a direct accses mode.
As long as i can play my RPGs i am fine ;)
And if the MMC/SD dosnt like big pauses then ill have to send the byte read command (CMD17 -> $51) more often, shouldnt kill the cart.
My only problem will be when someone tries bytewise write as i dont want to kill the flashmem inside the MMC/SD cart.
Long road ahead *g*
@oswald:
Huh?
I want to be as compatible as possible with just the mmc64 plugged in, as said its a proof of concept. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11114 |
running code that accesses i/o area in the i/o area might be an interisting (but futile :=P) experience :=D |
