From: Spiro Trikaliotis (ml-cbmhackers_at_trikaliotis.net)
Date: 2006-12-17 13:11:14
Hello,
* On Sat, Dec 16, 2006 at 12:06:51PM +0200 Marko Mäkelä wrote:
> There must be some difference in the serial bus timing, then.
Well, yes, there is. Anyway, I more expect the original ROM to be defect
than this being the cause for the problems at first.
Let me add to your (?) classification on zimmers.net
(http://www.zimmers.net/anonftp/pub/cbm/firmware/drives/new/1541/):
*** Power-On message ($E5B6-$E5C7)
1540-e000.325303-01.bin:
- 73,CBM DOS V2.6 V170,00,00
1541-e000.901229-01.bin:
1541-e000.901229-02.bin:
1541-e000.901229-03.bin:
1541-e000.901229-05.bin:
- 73,CBM DOS v2.6 1541,00,00
**** Handle errors after TALK ($E683-$E685),
Handle errors after LISTEN ($E68B-E68D):
1540-e000.325303-01.bin:
1541-e000.901229-01.bin:
1541-e000.901229-02.bin:
1541-e000.901229-03.bin:
- JSR $EA4E (release bus)
1541-e000.901229-05.bin:
- NOP, NOP, NOP
*** Autoboot ($E780-$E7A2):
1540-e000.325303-01.bin:
1541-e000.901229-01.bin:
1541-e000.901229-02.bin:
1541-e000.901229-03.bin:
- implemented
1541-e000.901229-05.bin:
- rts, nop, nop, nop, ..., nop, rts
*** Delay for C64 ($E979-$E982):
1540-e000.325303-01.bin:
- not implemented
nop; nop; nop; nop
jsr $E9AE
jsr $e99c
1541-e000.901229-01.bin:
1541-e000.901229-02.bin:
1541-e000.901229-03.bin:
1541-e000.901229-05.bin:
- implemented
lda $23 <-- this is the marker if slow or fast handling of bus
bne E980
jsr FEF3 -- additional delay for C64
E980: jsr FEFB
(at $FEFB, there is jsr $E9AE, JSR $E99C, like in 1540 ROM!)
*** getting a data byte after LISTEN I ($E9DC-$E9DE):
1540-e000.325303-01.bin:
1541-e000.901229-01.bin:
1541-e000.901229-02.bin:
1541-e000.901229-03.bin:
- nothing special
1541-e000.901229-05.bin:
- patch to wait for DATA IN HI before setting the timer
jmp $FF20 (cf. there)
(This might be related to the C64 being slower than the VIC20. The
timer is only started after the C64 has started talking to the floppy;
effectively, the floppy is giving more time to the controller).
*** getting a data byte after LISTEN II ($EA0E-$EA17):
1540-e000.325303-01.bin:
1541-e000.901229-01.bin:
- and #4, bne $ea0b, lda $1800, eor #1, lsr
1541-e000.901229-02.bin:
1541-e000.901229-03.bin:
1541-e000.901229-05.bin:
- eor #1, lsr, and #2, bne $ea0b, nop, nop, nop
(What does this mean? Why does the 1541 check clock OUT?
In the 1540 and 1541-1 ROM, it was a test for data in.)
*** Set DDRA, DDRB and PB on VIA1 after RESET ($EAA4-$EAA6)
1540-e000.325303-01.bin:
1541-e000.901229-01.bin:
1541-e000.901229-02.bin:
1541-e000.901229-03.bin:
* set only DDRA
1541-e000.901229-05.bin:
* set DDRA, DDRB and PB (via patch at $FF10)
*** Set DDRB and PB on VIA1 after RESET ($EBDA-$EBE3)
1540-e000.325303-01.bin:
1541-e000.901229-01.bin:
1541-e000.901229-02.bin:
1541-e000.901229-03.bin:
* set DDRB, then PB
1541-e000.901229-05.bin:
* set PB, then DDRB (this avoids a ripple on the line)
*** contents of data blocks after formatting RESET ($FC86)
1540-e000.325303-01.bin:
- NOP (--> $00, $00, $00, ...)
1541-e000.901229-01.bin:
1541-e000.901229-02.bin:
1541-e000.901229-03.bin:
1541-e000.901229-05.bin:
* INX (--> $4B, $01, $01, ... beginnng with 2nd track)
(--> xx, $01, $01, ... on 1st track)
*** PATCHES ($FEF3-$FF00):
delay for serial bus
1540-e000.325303-01.bin:
- N/A
1541-e000.901229-01.bin:
1541-e000.901229-02.bin:
1541-e000.901229-03.bin:
1541-e000.901229-05.bin:
- implemented
txa
ldx #5
fef6 dex
bne fef6
tax
rts
(the following is needed because patch for delay needs more space than
available)
fefb jsr e9ae
jmp e99c
*** UI command ($FF01-$FF0F)
1540-e000.325303-01.bin:
- N/A
1541-e000.901229-01.bin:
1541-e000.901229-02.bin:
1541-e000.901229-03.bin:
1541-e000.901229-05.bin:
- implemented; write $2d into $23 if "UI+", or $00 into $23 if "UI-"
*** PATCH ($FF20-$FF2E)
1540-e000.325303-01.bin:
1541-e000.901229-01.bin:
1541-e000.901229-02.bin:
1541-e000.901229-03.bin:
- N/A
1541-e000.901229-05.bin:
- implemented (cf. $E9DC above)
*** $FFE2-$FFE4
1540-e000.325303-01.bin:
1541-e000.901229-01.bin:
- empty
1541-e000.901229-02.bin:
1541-e000.901229-03.bin:
- ASCII "RSR" (initial of developer?)
1541-e000.901229-05.bin:
- empty
*** Jump-Table for U commands (and NMI) ($FFFA-$FFFB)
1540-e000.325303-01.bin:
- .word $fee7
1541-e000.901229-01.bin:
1541-e000.901229-02.bin:
1541-e000.901229-03.bin:
1541-e000.901229-05.bin:
- .word $ff01
Additional, the checksums at $c000, $fee6, and the GAP between header
and data block are different:
$C000 $FEE6 GAP
1540-e000.325303-01.bin: $B7 $60 $08
1541-e000.901229-01.bin: $97 $FD $08
1541-e000.901229-02.bin: $97 $10 $08
1541-e000.901229-03.bin: $97 $0E $09
1541-e000.901229-05.bin: $97 $3E $09
Most probably, that "GAP" is what you called "differences in delay loop"
on zimmers.net. This applies to $F58C-$F58D, as well as $FCCF-$FCD0.
With the ROMs before -03, the 1540/1541 waited 8 byte for that
"intra-sector gap", with the ROMs -05, it waited 9 byte.
Notice that there are some sources which claim there is a problem when
the 4040 is writing to a disc which was written (or formatted) by the
2031/1540/1541 before. The decription of this problem was based upon
that intra-sectop gap. Possibly, Commodore noticed this and changed the
size of the GAP to take this into account.
Explanation (as I understand it):
The 4040 waited 8 DATA bytes, which results in 10 "raw" (GCR-coded)
bytes. The 2031/1540, and early 1541 waited for 8 RAW bytes. Thus, when
the 2031/1540/1541 wrote to disc, it just waited 8 raw byte, then wrote
$FF to begin the sync mark of 5 $ff byte.
Now, when the 4040 wrote to the same disc, it waited for 10 raw byte.
After this, it already was in the SYNC mark the 2031/1540/1541 had
written before. Now, the 4040 switched to write mode. If in this switch,
some "glitch" was written as if there was a zero in, we had a problem:
On reading the disc, the disc controller (DC) noticed a sync (the rest
of what was written by the 2031/1540/1541), because if was already more
than 10 bits in a row (2 byte = 16 bits). Now, the DC saw the zero and
"thought" the sync has ended, expecting some data. Unfortunately, now,
the real sync started, resulting in a read error.
With Commodore making that gap 9 raw byte with the -03 and -05 ROMs,
this problem disappeared: The 4040 started writing when there were only
8 bits (or, due to timing differences, 9 bits) of "1". This was not
recognized as SYNC, resulting in no problems.
Of course, using even 10 raw byte as inter-sector gap would have been
better. Perhaps, Commodore feared a incompatibility with older 2031,
1540 and 1541-1, 1541-2 drives.
To come back to the initial problem: We see the the 1541-05 ROM
tries to reset the bus in more circumstances than the -03 ROM.
Especially the $E9DC change might be related to some transfer problems.
Regards,
Spiro.
--
Spiro R. Trikaliotis http://opencbm.sf.net/
http://www.trikaliotis.net/ http://www.viceteam.org/
Message was sent through the cbm-hackers mailing list
Archive generated by hypermail pre-2.1.8.