Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Krill loader not working
2014-10-19 20:28
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....
 
2014-12-04 07:48
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.
2014-12-04 08:00
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.
2014-12-04 08:08
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 ?!?!?!
2014-12-04 08:26
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.
2014-12-04 10:34
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?
2014-12-04 11:02
doynax
Account closed

Registered: Oct 2004
Posts: 212
Quoting Bitbreaker
Doynax: 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 Bitbreaker
What vice version is used?
Ugh. I'd have to dig through my stack of old notebooks, but probably 2.2.
2014-12-04 12:02
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 doynax
Ugh. I'd have to dig through my stack of old notebooks, but probably 2.2.


That was actually directed to chesoner, oops :-)
2014-12-04 12:37
doynax
Account closed

Registered: Oct 2004
Posts: 212
Quoting Bitbreaker
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.
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.)
2014-12-04 12:41
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.
2014-12-04 15:31
doynax
Account closed

Registered: Oct 2004
Posts: 212
Quoting Groepaz
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.
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?
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Guests online: 100
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Logo Graphicians
1 t0m3000  (10)
2 Sander  (9.8)
3 Mermaid  (9.5)
4 Facet  (9.4)
5 Shine  (9.4)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.044 sec.