| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Opinions on safe minimum $1c07 value?
Any opinions on safe values of $1c07 (disk drive interrupt/head stepper motor frequency on 1541-ish drives)?
I know $3a is the default, and $10 is something one should *never* go below. I quickly checked Remember's recent Gemini Wing release and there $20 was used. So I guess the minimum safe value, considering different disk drive clones etc. would be somewhere between $10-$20? |
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
the minimum safe value is about $20 - $28. the problem is that different drive mechanics have different stepper motor values. you can reach higher speeds safely though by accelerating the head instead of trying to go highest speed from the first step on. but it's not worth the effort because the head moves just one track in most cases. |
| |
Vulgar
Account closed
Registered: Feb 2003
Posts: 2 |
$18 should work on all drives unless their stepper is REALLY worn out |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Thanks for answers, I'm now using $28, that seems to ensure sufficient data-rate with the interleave I'm using (it's mainly the more quicker response to jobcodes I'm after, as I'm too lame to write my own routines from ground up :)) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Quote: $18 should work on all drives unless their stepper is REALLY worn out
i used $18 in deus ex machina... but then short before the competition at mekka symposium anonym/padua came to me and said it didn't work on the compo machine. i changed it to $28 and it worked. guys, you don't save much time anyway if you put your files into loading order. |
| |
DJ Gruby
Registered: Aug 2002
Posts: 30 |
I know this a super old thread, but it had been referred in the article I wanted to ask about. Perhaps someone can enlighten me, why this fast loader routine from Codebase
64 wiki requires blank screen? Majority of popular loaders do not require blank screen, but this one breaks if I remove... lda #$00
sta $d011 ...from the code (basically loading a couple of bytes of garbage from each sector). Any ideas? |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
This simply depends on the transfer protocol used. With badlines enabled, the CPU is stalled once in a while. If the protocol isn't made to handle this (lacking suitable handshaking to achieve higher throughput by synchronous access), it breaks - the drive would keep on sending data while the CPU cannot receive it, so that data is missed. Same problem emerges with other kinds of DMA caused by sprites and yes, REU DMA.
Without having looked at your specific instance, it's often possible to check for a badline before doing the handshake for a byte and wait until it has passed. |
| |
DJ Gruby
Registered: Aug 2002
Posts: 30 |
Thanks for a hint, Krill! I have tried out waiting for a bad line in several different places, but it does not seem to solve the problem. For example if I replace...charin ldx #$03
lda #$0b
sta $dd00
charin0 bit $dd00
bpl charin...with...charin ldx #$03
charin0 lda $d012
and #$07
beq charin0
lda #$0b
sta $dd00
bit $dd00
bpl charin0...it still fetches garbage. Any other ideas? |
| |
Burglar
Registered: Dec 2004
Posts: 1101 |
gruby, the loader you chose from codebase is *not* an irq loader at all and it doesn't contain the source of the drivecode.
check the code at charin:
;---------------------------------------
;-remove this if no irq is used -
;---------------------------------------
charin1 ; lda $d012
; cmp #$31 ;number of free rasterlines the higher the number, the slower the loader
; bcs charin1
so it wants you to uncomment that rasterline check if u want to use it under irq. it relies on nothing being active on some rasterlines so that the loader can transfer 4*2 bits (1 byte) without a handshake for each 2 bits. If anything happens (badline, irq, sprite, etc) during the transfer of a byte, it will fuck up.
It only does a handshake at the start of a full byte.
my advice, delete that loader and use a proper one. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
The badline condition is that the lowmost 3 bits of $d011 (YSCROLL) and $d012 match. But simply doingwaitbl: lda $d011
eor $d012
and #$07
beq waitbldoes not work, as once you detect a badline this way, it's pretty much over after this loop. You'd miss the case when the badline happens a bit later, while you do the actual byte transfer. So what you do this detect if a badline is about to happen, which means that the lowmost 3 bits in $d012 PLUS 1 match the YSCROLL bits: sec
waitbl: lda $d012
sbc $d011
and #$07
cmp #$07
bcs waitblDepending on the rest of the code and its timing, having 2 lines of tolerance might be required, i.e. cmp #$06 instead. Just play around with that.
As a sidenode, while this approach was quite common back in the days, i think it's a bit wasteful. The experimental resend method (detecting interrupts and DMA after the fact and resending the byte if so) i've added to my loader a while ago seems more promising, but it hasn't been used and tested much. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
how about checking if we're on the top/bottom border, and change transfer method for that part ? :) ofcourse sprited would be not allowed in there ;) |
... 2 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 - Next |
