So, I was looking at datasheet differences between the 6526 and 8520 chips earlier and found the only real difference is the TOD clock logic of the 6526 is replaced with a 24-bit binary counter on the 8520. I also noticed many years ago that the 1581 drive schematics do show the select line to the CIA marked as "6526". The schematic also shows that a jumper is placed on the PCB when using a WD1770 FDC and left open when using a WD1772 FDC. The jumper connects the PH2 clock line to the TOD line, which drives the 24-bit counter on the 8520. This seemed a bit odd.
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:
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
;
As a result, adding the jumper would result in faster step rates and improve the performance of the 1581 Drive. Also, as it turns out, if you have no need to have a jumper on the PCB, you can simply replace the 8520 CIA with a 6526 CIA and the drive will function the same. As 6526 chips can still be found more easily than 8520 chips, anyone who would either like to build a drive from parts or need to repair one (assuming a bad 8520), using the 6526 would be a easy swap.
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:
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
;
Some years ago, I started working on the 1581 and have a handful of changes to the source code to reduce it's overall ROM size. Fixing a couple extra bugs really can't hurt. I also have a few NOS 6526A parts and will try one of these in the drive as well. Fun time...
Login
Register
FAQ
Search
