Note that a functional difference between the WD1770 and WD1772 FDCs are the step rates. There are 4 available step rates, but the first two between the chips are the same. I went back to the source code and found out what they're doing... albeit it doesn't makes any sense! Turns out the code preloads memory locations with the FDC commands from ROM. The command options are part of the command, which includes step rates for Type I commands, which move the R/W heads. The hardware uses the jumper to increment the counter, which is checked in the controller reset code... if the counter has NOT been incremented (meaning, no jumper is on the PCB), they take a different path and increment the Type I commands which also has the default step rates. As the step rates are the lower two bits, they change from 00 to 01. Here's the problem however...
for the WD1770, step rates are:
0 0 = 6ms
0 1 = 12 ms
1 0 = 20 ms
1 1 = 30 ms
for the WD1772, step rates are:
0 0 = 6ms
0 1 = 12 ms
1 0 = 2 ms
1 1 = 3 ms
So, without the jumper, the step rate changes from 6ms to 12ms. Logically, it would appear that Commodore was attempting to switch step rates if a WD1772 was installed and leave the defaults if a WD1770 was installed. Problem is, the code doesn't actually address the different step rates... it just increases it for the WD1772 (when the jumper is absent). Perhaps they had a preliminary datasheet that was marked incorrectly which could account for the bad code. Here's the source code section that does this:
Code: Select all
reset_ctl ; reset disk controller
ldy #all
jsr xms ; no access for 500 mS
ldy #all
jsr xms ; *
lda #bit7
sta cachetrk ; *
lda #0
sta dirty
jsr psetdef
jsr setdef
lda #$4e
sta ctltimh
lda #$20
sta ctltiml ; IRQ's
jsr resetim ; reset controller timers
lda #$08 ; setup wd177x commands
sta wdrestore
lda #$18
sta wdseek
lda #$28
sta wdstep
lda #$48
sta wdstepin
lda #$68
sta wdstepout
lda #$88
sta wdreadsector
lda #$aa
sta wdwritesector
lda #$c8
sta wdreadaddress
lda #$e8
sta wdreadtrack
lda #$fa
sta wdwritetrack
lda #$d0
sta wdforceirq
lda #18
sta setval ; 18 mS
ldy #all ; test registers
1? sty wdtrk
sty wdsec
sty wddat
jsr delay16
cpy wdtrk
bne 3?
cpy wdsec
bne 3?
cpy wddat
bne 3?
dey
bne 1?
jsr wdabort ; abort the wd17xx
lda #0
sta todlsb
jsr delay40 ; wait for 40 uS
lda todlsb
bne 2? ; default wd1770
inc wdrestore
inc wdseek
inc wdstep
inc wdstepin
inc wdstepout
2? bne okdone ; bra
3? lda #$0d ; controller error
.byte skip2
okdone lda #0 ; ok
done jmp errr
;
I think I'm going to modify the code... use a table to load up the RAM locations and remove the code that checks the 24-bit timer and get the faster step rates. Granted, I do need to get my 1581 out, along withe a C64 and Monitor to do final testing... so I'm also looking at another problem area in the source code that could hang the drive if a certain error happens with the FDC.
This one is a bit tricky... as it tests for the FDC to no longer be busy, then checks the status register for specific errors, sets a controller_status byte with an error code and exits. The problem here is stack usage in the code for testing an initial status bit, the S2 bit (Data Lost).... if it's a problem, the stack is left with the CPU status register (PHP instruction) and no PLP to get it back, so the return address pulled via the RTS will be incorrect and result in a hang condition. I'm going to look at changing this code as well and likely fix an odd error that would hang the drive once in a great while.
Code: Select all
getwdstat
;
jsr wdunbusy ; wait for unbusy first
;
wdstatus
;
php
WDTEST
lda wdstat ; get status
lsr a
lsr a
lsr a
bcs 1?
;
and #bit3+bit1+bit0
tax
plp ; restore carry
lda wdtrans,x
.byte skip2
1? lda #9
sta controller_stat
lda controller_stat
rts
;
wdtrans .byte 0,5,2,0,0,0,0,0,8
;
