| |
Chesoner
Registered: Apr 2013
Posts: 29 |
Krill loader not working
Hi There,
We are still strungling with the Krill loader, I have to say that we have progressed a lot but we get the following problem :
If we use the following command :
Make prg INSTALL=4000 RESIDENT=9000 zp=10
The install is working good at 4000 but the loader is still located at 0400. if we forced it to load at 9000 it ain't working.
Are we doing something wrong here ? |
|
... 55 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:It is only working in winvice 2.x, not on a real c64.
it would be much easier to help if you said WHAT EXACTLY is working and what is not. and ALWAYS put ALL files on disk/d64. did you try strippig it down to a simple test case that only initializes the drive code and then loads something? does that expose the same problems? |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Aren't you just starting the first part and trying to initialize the loader without true drive emu? In that case the loader doesn't install itself in the drive and it won't work when you want to load later on. It doesnt help turning on true-drive emulation afterwards..
- put all files on a d64
- make sure you have true-drive emulation
- start winvice with the d64 |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
First testing we did :
We only had the part (file "01") to be loaded on a d64 file. we started the first part compiling with kickassembler so the first part is started in winvice and had a keyboard check in the beginning so the coding was not executed automaically further. we first put drive emulation to on and attached the d64 file with only the part what should be loaded ("01") and then press space (keyboard check) We did not get it to work this way because the loaded part freezes after decrunching/starting.
The second we did :
We now put both files to the d64 file. so the file "01" which should be loaded and the starting part "intro" are now on the d64 disk. if we run the d64 disk it is working fine in winvice 2.x but not on a real c64 because it again freezes after decrunching/starting.
I hope this will explain the problem we have a bit more. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
you have to know that loaders like this upload & execute code in the drive. true drive emulation have to be enabled before this step.
btw dont attach d64 and start true drive emulation manually. common practice is to set up true drive emulation to permanent & attach d64 in commandline.
the problem is too complex to get an answer to it on a forum like this. you have to try to pinpoint where & when the bug happens. before or after the file was loaded. before or after you have jumped on code in the new file. has the file been loaded correctly, etc etc. We cant do this job for you from here. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
I never used Krill's loader, so i can't know for sure, but seems like if loader checks for compatibilty with actual drive, and if it found a loader-compatible device, then load drive code into drive ram, otherwise load file using some "non turbo" routines...
If it is, i think there are some problems during drive code compilation in this specific case, instead a real krill's code bug...
Very very imho, eh... |
| |
Pantaloon
Registered: Aug 2003
Posts: 124 |
I've used Krills loader alot and never really had problems that wasn't caused by bad code from my own side. If you post your code here (your interrupts etc and how you setup the loader) we would probably spot the error directly. |
| |
Axis/Oxyron
Account closed
Registered: Apr 2007
Posts: 91 |
Most important is to track down, where the problem occurs (loading, decrunching or something else). So my first test whould be to stop the cpu with an endless loop after loading. And compare the loaded memory with the original file. If this looks ok, do the same with the memory after decrunch. And so on... |
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
Axis: you are obviously too simple minded then! Abstract description of obscure problem without telling which parameters got used (remember - my notice on true drive and device traps passed uncommented) are definately enough to yell for help and moan whenever no suitable solutions surfaces within the minute ...
cough - not that it turns off anyone from further following the thread ... |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
@count zero: your true drive and device trap weren't unnoticed, it's better to not comment on the rest of the post.
I found after a lot of testing what the problem was, now we have to find a fix for the problem but at least we addressed the issue.
Thanks everyone for the advice !! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
so what was the problem? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
