Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user hllerena78 ! (Registered 2019-08-20) You are not logged in 
CSDb User Forums


Forums > C64 Coding > Opinions on safe minimum $1c07 value?
2003-03-09 16:06
cadaver

Registered: Feb 2002
Posts: 1120
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?
 
... 2 posts hidden. Click here to view all posts....
 
2003-03-10 12:24
cadaver

Registered: Feb 2002
Posts: 1120
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 :))
2003-03-11 12:03
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.
2015-05-16 19:22
DJ Gruby

Registered: Aug 2002
Posts: 25
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?
2015-05-16 22:18
Krill

Registered: Apr 2002
Posts: 1241
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.
2015-05-17 08:34
DJ Gruby

Registered: Aug 2002
Posts: 25
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?
2015-05-17 09:19
Burglar

Registered: Dec 2004
Posts: 795
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.
2015-05-17 09:25
Krill

Registered: Apr 2002
Posts: 1241
The badline condition is that the lowmost 3 bits of $d011 (YSCROLL) and $d012 match. But simply doing
waitbl: lda $d011
        eor $d012
        and #$07
        beq waitbl
does 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 waitbl
Depending 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.
2015-05-17 10:45
Oswald

Registered: Apr 2002
Posts: 4431
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 ;)
2015-05-17 11:20
tlr

Registered: Sep 2003
Posts: 1229
Quote: 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 ;)

That's quite common.

Example (from the Superkit filecopier):
.C:3663  A2 07       LDX #$07
.C:3665  38          SEC
.C:3666  AD 12 D0    LDA $D012
.C:3669  E9 32       SBC #$32
.C:366b  90 04       BCC $3671
.C:366d  29 07       AND #$07
.C:366f  F0 F5       BEQ $3666
.C:3671  8E 00 DD    STX $DD00
.C:3674  48          PHA
.C:3675  68          PLA
.C:3676  24 EA       BIT $EA
.C:3678  AD 00 DD    LDA $DD00
.C:367b  4A          LSR A
.C:367c  4A          LSR A
.C:367d  4D 00 DD    EOR $DD00
.C:3680  4A          LSR A
.C:3681  4A          LSR A
.C:3682  4D 00 DD    EOR $DD00
.C:3685  4A          LSR A
.C:3686  4A          LSR A
.C:3687  A2 27       LDX #$27
.C:3689  4D 00 DD    EOR $DD00
.C:368c  8E 00 DD    STX $DD00
2015-05-17 13:23
DJ Gruby

Registered: Aug 2002
Posts: 25
Krill, you are the God! Thanks so much, now with your change the code seems to work and it doesn't load any garbage anymore, just an original file data:
charin  ldx #$03

charin1 sec
        lda $d012
        sbc #$03
        and #$07
        cmp #$07
        bcs *-9

        lda #$0b
        sta $dd00
        bit $dd00
        bpl charin1
Thanks, you rock!
Previous - 1 | 2 - 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
Spinball/Excess
Pantaloon/Fairlight
icon/The Silents, Sp..
iceout/Avatar/HF
JCH/Vibrants
Mason/Unicess
Guests online: 35
Top Demos
1 Unboxed  (9.7)
2 Uncensored  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 The Shores of Reflec..  (9.6)
7 Lunatico  (9.6)
8 Wonderland XII  (9.5)
9 C=Bit 18  (9.5)
10 Old Men in Used Cars  (9.5)
Top onefile Demos
1 Smile to the Sky  (9.5)
2 Dawnfall V1.1  (9.5)
3 Crystal Gazer  (9.5)
4 Daah, Those Acid Pil..  (9.5)
5 Rewind  (9.5)
6 Instinct  (9.5)
7 Pandemoniac Part 5 o..  (9.5)
8 Innervasion  (9.4)
9 Bad Boy  (9.4)
10 Ghost in the Sydney  (9.4)
Top Groups
1 Fossil  (9.8)
2 PriorArt  (9.7)
3 Performers  (9.6)
4 Oxyron  (9.4)
5 Censor Design  (9.4)
Top Hardware-Gurus
1 Soci  (9.9)
2 Grue  (9.8)
3 Zer0-X  (9.8)
4 Wiesel  (9.8)
5 Lemming  (9.7)

Home - Disclaimer
Copyright © No Name 2001-2019
Page generated in: 0.054 sec.