| |
Chesoner
Account closed
Registered: Apr 2013
Posts: 28 |
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....
|
| |
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: 500 |
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: 11118 |
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: 2845 |
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: 2845 |
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
Account closed
Registered: Apr 2013
Posts: 28 |
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: 2845 |
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! |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
