| |
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 ? |
|
| |
HCL
Registered: Feb 2003
Posts: 728 |
I always claimed that this loader is not working.. ;) |
| |
algorithm
Registered: May 2002
Posts: 705 |
delete the files in the build directory and try
make prg RESIDENT=9000 INSTALL=4000 ZP=10
(make sure ZP is in capitals :-)) and in this example the used ZP would start from $10, not $0a |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
Why is it if I call the loader after setting up an irq the irq stops and so is the loader and if I do not use an irq everything loads just fine ?
I have tested with different irq's but it keeps hanging after calling the loader. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
try disabling the watchdog in the loader config |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
And try not to trash registers with your irq :-) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
does the irq work without the loader ? does it work with a dummy irq ? (doing nothing) try to pinpoint the bug. |
| |
algorithm
Registered: May 2002
Posts: 705 |
To add to this, Are you also ensuring you run the correct load call (if depack options are enabled, make sure that you run the correct section) |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
I don't know what caused the problem but I build the loader again with more options and it is working fine now.
Thanks for the help |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
Almost there .... so here is another question :
I have now loaded a small program (with the krill loader) at a certain location and relocated to $0801 when possible. i have packed the file with pucrunch and now want the file to be decompressed while running an irq. What do i do now ?
I cannot use $080d because the irq will stop untill the file is decompressed.
Can i still use krill's loader to decompress the file and how do i do that ? |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
anyone an idea ? |
| |
Knut Clausen
Registered: Apr 2013
Posts: 18 |
I don't know how that depacker works, and I'm not sure if this is what you're after, but you could depack outside of your IRQ and check within your IRQ if the content is depacked. Simple example:
lda #<IRQ
sta $fffe
lda #>IRQ
sta $ffff
lda #rasterPos
sta $d012
cli
jsr $080d
inc depackDone
jmp *
depackDone:
.byte 0
IRQ:
..
lda depackDone
beq notDone
jmp setupNextPart
notDone:
// continue running this IRQ
edit: The loader can depack as part of the loading process, but I'm not very familiar with loaders, so I can't give any input on that. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
self depacking prg files is not the way, they assume they have the whole machine themselves, so they can not live within an "irq loader"/"trackmo" enviroment.
there are packers which can pack data on the pc side, then you put it into a d64, and use the accompanied depacker code to inflate what has been loaded.
krill's loader can do this too, it has built in depackers, which can depacj while/after loading IIRC. but never used that so cant help with that. |
| |
Firehawk
Registered: Aug 2011
Posts: 31 |
You can use the load_compd call in krillloader to automatically depack the file on-the-fly (you need to recompile the loader with the option turned on). You must pack without basic-start, in puchrunch I belive the option is -c (check this). This works in exomizer also. You can run the irq during this load/decompress, but beware not to stall the loader (cpu starvation from too little time outside irq), as the load will fail, and the drive will reset (or so I've heard).
Good luck.
PS! I would advise you to put the loader on either a very low address (i.e. $0400) or very high address (i.e. $c000), otherwise you will constraint the next loaded part to be below the stated value (in your case $9000) both in compressed and decompressed mode. |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
Thanks for the replies. Indeed I tried to depack with jsr $080d outside of the irq but the irq will stop for a moment and continue when the file is depacked.
I've searched for documentation of the krill loader to depack the file after it is loaded but there is almost no documentation of that loader. if someone could point me to the right direction I would be a happy person :)
I have the same routine as Knut Clausen but when i use the jsr $080d outside the irq like his routine the irq will stop for a moment. I only use 0314 instead of fffe, I can try that but i don't think that it's the solution. |
| |
algorithm
Registered: May 2002
Posts: 705 |
Once the loader is setup to allow decompression and loading on the fly, an example below
data file to be loaded "test.raw" $2000-$3ffc (containing lo/hibyte of start at beginning
exomizer -f test.raw comp.01
then simply call the compressedload call with the file name and it will depack and load to $2000-$3ffc with forward depack (allow some extra bytes at the end) |
| |
algorithm
Registered: May 2002
Posts: 705 |
Sorry, should be something like exomizer mem -f test.raw -ocomp.01 |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
The drive reset only happens if you keep the watchdog option enabled. It has been discussed many times :-) Also. in general, no problem with starting a SFX, but one needs to take care that if things get depacked under IO, that the IRQ is safe with $01 being #$34, also usually the SFX extractors lock the IRQ, one needs to remove the SEI to keep the irq running. Better choice is to do levepacked files, means files without an own decompression code per file. Many packers support that and many packers also include a decompression code for standalone use, in case of loadcompd (load and depacking on the fly) the decompressors are even integrated into Krill's loader for a bunch of packers. There's all the comfort one can think of. Btw.: Placing the loader at $c000 is even more of a hindrance, the mem above is not bad or smelly, it's there and usable. |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
After a lot of testing it looks like kickassembler/krill with winvice is not a great combination. if I attach the drive and set true drive emulation on in winvice and start code with kickassembler it is kind of random if it will load and decrunch a file from the attached drive correct. If i put all the files on a d64 en start the coding from the d64 file it will load/decrunch good.
I can't see why this is but at least it is working. |
| |
Count Zero
Registered: Jan 2003
Posts: 1932 |
Did you make sure that virtual device traps in vice are disabled and no 2nd drive is enabled? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:and start code with kickassembler
???? |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
Quote: Quote:and start code with kickassembler
????
I use sublime for coding and kickassembler to compile and start the code in winvice. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
And you are sure that you don't have clashes regarding the used zeropage-addresses and you only write sane values to $dd00? I did whole demos with that loader and things always worked out of the box. There's some common pitfalls however regarding the use of irq loaders in general. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
" if I attach the drive and set true drive emulation on in winvice and start code with kickassembler it is kind of random if it will load and decrunch a file from the attached drive correct. If i put all the files on a d64 en start the coding from the d64 file it will load/decrunch good."
its hard to understand whats the difference between the 2 scenarios, altho that is the key to your problem.
a) start up winvice, attach _DRIVE_ (?) manually in WinVice, THEN start the program with kickass ???!? (files are not in d64 now??)
b) put everything on a d64 then start coding from d64 ?!?!?! |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
I forget the details, and never completely tracked down the cause in the first place but IIRC the "Handle TDE for autostart" option triggered similar issues in older VICE versions. Something about the stepper motor phase getting into an illegal state and seemingly not being possible to realign. As I recall attaching the image late aggravated the problem.
This may have been G64-specific though. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Doynax: i happend to have that kind of autorun problems on 1541u version 1 with my loader :-)
What vice version is used? |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting BitbreakerDoynax: i happend to have that kind of autorun problems on 1541u version 1 with my loader :-) Originally I also had a similar problem with the stepper motor being out-of-phase at start-up. Essentially the rotation angle is not determined by the register/coil state and so you have to do a little stepping dance to align it properly.
Of course for the most part the initial stepping during the loading of the loader program would fix this, at least if it isn't entirely on the directory track.
However in this particular case VICE hadn't fully emulated the initial load and while it did allow me to read from the directory track no amount of "alignment" (even outright BUMPing) appeared to get the drive into phase. Still, the whole thing might easily have been a bug/misunderstanding on my part.
Quoting BitbreakerWhat vice version is used? Ugh. I'd have to dig through my stack of old notebooks, but probably 2.2. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Quoting doynax
Of course for the most part the initial stepping during the loading of the loader program would fix this, at least if it isn't entirely on the directory track.
Not necessarily as for the 1541u it seems the bootloader is transferred directly without using the floppy first, and thus no alignment of the head happens.
I fixed that by loading an arbitrary block before starting the loader itself (need to load the dir anyway beforehand), so the floppy kernal brought the head to a good position before taking over with the loader.
Quoting doynaxUgh. I'd have to dig through my stack of old notebooks, but probably 2.2.
That was actually directed to chesoner, oops :-) |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting BitbreakerI fixed that by loading an arbitrary block before starting the loader itself (need to load the dir anyway beforehand), so the floppy kernal brought the head to a good position before taking over with the loader. Be careful. I managed to run into a case where the floppy already started up at the directory track but with the alignment still out-of-whack, so while the initial load did succeed the next step landed the head on a half-track.
I suppose the "proper" way of handling this would be to dynamically detect the problem and try to realign after a prolonged read failure. Instead I ended up using the floppy DOS to repeatedly SEEK one full-step outward, while cycling through the bit-rates.
Your method, except with a pair of reads across two tracks, seem like the most reliable approach but I was trying to avoid BUMPs, and didn't have any DOS sectors to read on the remaining tracks.
(Actually the best way is probably to wait for the oracle of drivecode, i.e. Krill, to weigh in on the proper way to handle the issue.) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:I managed to run into a case where the floppy already started up at the directory track but with the alignment still out-of-whack, so while the initial load did succeed the next step landed the head on a half-track.
That cant happen on a real drive (and i doubt it can on a recent VICE either). Unless of course the disk was written with a misaligned drive, which results in valid data on 17.5 or 18.5. Or if your stepping routines are broken :) Remember the relation of active coils vs absolute track is fixed - The problem arises whenever you only step relative. You can solve it by assuming certain active coils refer to specific tracks, see here. |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting GroepazThat cant happen on a real drive (and i doubt it can on a recent VICE either). Unless of course the disk was written with a misaligned drive, which results in valid data on 17.5 or 18.5. Or if your stepping routines are broken :) Remember the relation of active coils vs absolute track is fixed - The problem arises whenever you only step relative. You can solve it by assuming certain active coils refer to specific tracks. Thank you, that makes a lot of sense. Admittedly the problem was encountered with an old version of VICE as opposed to real hardware, and may well have been caused by a drivecode bug. I really should get into the habit of working out what is actually going on instead of fiddling until stuff works.
Incidentally I never considered that the coils may not be magnetized while the drive motor is off. So I always need to recalibrate after restarting the motor. No idea where I'm going to find the RAM for that :(
How much force/tilt is required to make head slip in practice? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Maybe we should move the stepper discussion over to another thread. But i'll come to that in a future post.
Chesoner: Why did you post here before sending me a PM or mail or similar? Also your choice of topic is unfortunate, as it implies something is wrong with the loader, while so far it seems that the error lies elsewhere. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Concerning the stepper:
I'm not entirely sure if that's on-topic, but the stepper coils can indeed be misaligned with regard to the actual position, on real hardware and in emulation alike.
This is the case when the upper of the two stepper bits is flipped with regard to the "correct" value - the coil opposite to the "correct" coil is magnetized, but the head won't move.
In normal operation, by incrementing or decrementing the 2-bit stepper value, you'd magnetize either of the two other coils clockwise or counter-clockwise next to the original one, and the head would move one step.
However, with the upper bit flipped, the head would go in the wrong direction upon the first increment or decrement on the 2-bit stepper value, but in the intended direction afterwards, thus ultimately landing a bit off the desired destination.
In practice, a misaligned stepper value may happen on a drive reset. Disregarding the current stepper value, the two stepper bits are initialised to %00, and, when misaligned, only upon the first disk access would they be aligned with the actual position by the firmware.
Now, of course, if no disk access happens before running your custom loader code, it must correct things itself. In my loader, i solved the issue like this:
lda INITBUF_TRACK_DIFF
bne findtrackn; branch if the drive had already seeked before the loader has been started
; the drive was reset immediately before running the loader -
; step down a track: this works normally if the stepping bits are congruent with the stepper motor;
; however, it may happen that the bits are misaligned (opposite to the actual stepper position, bit 1
; reversed), this alone does not move the head but stepping makes it go into the direction opposite to
; the one desired when moving; the stepping down two halftracks will actually step up and step down one
; halftrack each and thus will end up on the same track as before, but align the stepper bits to the motor.
ldx #$02
stx CURTRACK
dex
jsr trackseekx
; find current track number
; this assumes the head is on a valid half track
findtrackn:Thus, if the stepper bits were aligned, the head is moved for two steps, i.e., one track. If they were misaligned, the head is moved one half-track in one direction and another in the opposite, ultimately landing on the same track as before. |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
Quote: Maybe we should move the stepper discussion over to another thread. But i'll come to that in a future post.
Chesoner: Why did you post here before sending me a PM or mail or similar? Also your choice of topic is unfortunate, as it implies something is wrong with the loader, while so far it seems that the error lies elsewhere.
Next time I post : Krill loader is working great but is not working correcly at my place.. oke ? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
I'd prefer something more or less neutral, e.g. "Problems with Krill's loader".
Anyhow, feel free to send a minimal build that exhibits the symptoms you mentioned, and i'll see if i can find something. |
| |
Celtic
Administrator
Registered: Jan 2002
Posts: 807 |
Krill to the rescue! |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Chesoner: Sorry about all of the off-topic discussion. My bad.
Now then, to further compound my sins..
Krill: Good to know, thanks. I see you're testing $42 (seek target) instead of $22 (current track), thereby avoiding avoiding any problems if the drive should start-up on a misaligned directory track. I really should have taken a close look at all of these subtle details when rearranging your code into a loader of my own ;)
Did you ever notice the track slipping between motor stops? There's a big warning sign in the VICE sources which Groepaz linked to about the coils are being demagnetized while the motor is off, presumably to avoid overheating the coils. I suppose it might be safest to at least avoid parking the head too close to track 35. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting doynaxDid you ever notice the track slipping between motor stops? There's a big warning sign in the VICE sources which Groepaz linked to about the coils are being demagnetized while the motor is off, presumably to avoid overheating the coils. I suppose it might be safest to at least avoid parking the head too close to track 35. No, i never noticed. The motor is turned off long after the stepper has settled, and switching off the current coil presumably would not move the head.
Why track 35? Because you might end up in the woods (track 35.5) on a standard-format disk and wouldn't find your way out? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
btw: there are original games that step by toggling the motor off/on |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting Groepazbtw: there are original games that step by toggling the motor off/on Without touching the stepper bits? How would they control in which direction to step? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
of course the coil bits are changed as well, else nothing moves :) but the motor is started and stopped in between, and coils changed several times when motor is off (to obscure what really happens) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Okay, obfuscation, i see. But as long no stepping happens by simply turning on and off the motor, no problem. Then no code is required to handle that, as doynax feared. |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting KrillNo, i never noticed. The motor is turned off long after the stepper has settled, and switching off the current coil presumably would not move the head. That's comforting to hear. Probably means that there's enough inertia not to have to care much about it, especially not in demos.
Quoting KrillWhy track 35? Because you might end up in the woods (track 35.5) on a standard-format disk and wouldn't find your way out? Precisely. A loader which reads the tracks of the sectors flying by can adjust to unexpected movements as long as it stays in the formatted area, but drifting beyond the edge of the map would require harder (i.e. more RAM-consuming) to recover from.
Actually my old D64 loader couldn't do this but I imagine you'd need to be decoding the sector headers anyway for out-of-order reading to work. |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
After we get the loader working in winvice 2.4 we tested it in winvice 2.2. it is also working good in winvice 2.2 so we tested it out on a real c64 and after the part is loaded and decrunched the part freezes.
What is the difference between winvice 2.x and a real c64 ? |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
what exactly did you have to do to get it working? |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
Quote: what exactly did you have to do to get it working?
I got it working if I put all the files on a .d64 file and start the .d64 file.
If I compile the coding with kickassembler and start it with the .d64 file attached we have the same problem the the part what is loaded freezes after decrunching. |
| |
iAN CooG
Registered: May 2002
Posts: 3194 |
if you attach a prg, true drive emulation is not active and prolly virtual device traps are on. always use d64 |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
If i don't put all the files on a d64 :
I have a file which will be loaded put on a d64. I then have my sublime/kickassembler with coding. I start the compiled coding (1st part) from kickassembler so winvice is started. I have a keyboard check so i can first put drive emulation to on and attach the appropiate d64 file (2nd part) with attach drive. I then press the keyboard so the coding is executed further and the file should be loaded from the d64 disk.
But after the decrucnch the part starts and immediately freezes.
Now if I put the compiled coding (1st part) also to the d64 so I don't have to attach anything then winvice will start the first part, the second part is loaded and decrunched correctly so it starts all good but it won't run on a real C64. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
so does it load and decrunch on the real C64 too? if yes, then the problem isnt the loader at all |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
chesoner, sounds like you were thinking that all required files magically would appear on the correct d64.
You just need to build the d64 correctly (using the vice cmdline tool c1541.exe for example).
also, save your vice settings so you always have true drive emu on, manually changing settings every time will bore you to death ;)
and do *not* use multiple attached devices if you use krill's default 2bitatn loader or it will not work at all. just 1 1541 attached, no more no less. |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
Quoting Groepazso does it load and decrunch on the real C64 too? if yes, then the problem isnt the loader at all
It is only working in winvice 2.x, not on a real c64.
@burglar: The to be loaded file in on a d64 which is attached with the drive in winvice so all files needed is on the d64 file, i think.
Maybe we are doing something real stupid but we can't figure out what. |
| |
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? |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
Quote: so what was the problem?
I used an existing d64 file and when I put the files on the d64 disk it was kind of random if it loaded correctly.
Now I have automated this process so a new d64 file is created and the files are on a fresh new d64 disk and everything runs fine.
It seems that the used .d64 file is not valid (anymore) for some reason. The first part always runned fine on the disk but loaded random the next part correct. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
what did you use to copy the file to the old d64? |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
Quote: what did you use to copy the file to the old d64?
I used DirMaster v2.2.009 for transfering files |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
there is your problem =P |
| |
Chesoner
Registered: Apr 2013
Posts: 29 |
hehe, it would be a logic conclusion |
