Closed GoogleCodeExporter closed 9 years ago
Original comment by svof...@gmail.com
on 31 Jan 2008 at 8:31
Woo. Hoo.
Even with DMA. Mutisector mode not tested as nothing seems to be using it, just
like
mutisector read.
Original comment by svof...@gmail.com
on 12 Feb 2008 at 1:09
Better reopen it.
Rewrote big part of the state machine, command begin-closure mating.. Now both
BIOSes
seem to be more happy than not, but there's still an occaional miss every now
and then.
Here's an excerpt from an erroneous write operation:
{{{
430347+`430348+`430349+`43034a+`43034b+`43034c+`43034d+`41034d+
rHST:01034d:00+
4dwHST:00034d4d:00
4d 41 49 ce 05 02 80 35 02-00 00 00 00 00 00 00 MAI....5........
}}}
According to directory entry, the data was supposed to be written to
HST:01:03:4d,
which is 5 sectors earlier than it was written here (side 0). Who switches
sides, duh!
(test case: boot from cullshit.fdd, run
cc1 aa -az
cc2 aa
the operaion above is from writing aa.crl)
Original comment by svof...@gmail.com
on 16 Feb 2008 at 2:27
Some analysis:
if MASTER_COMMAND is printed when entering Write command handler, in faulty
cases it
retains the value $80, that is ACK. Roughly this means that:
WD issued a WRITE request
WD decided that operation is complete faster than CPU acknowledged BUSY
WD issued CPU_REQUEST_ACK before CPU even started to process ?
Original comment by svof...@gmail.com
on 18 Feb 2008 at 11:26
CPU_REQUEST_ACK comes from $D0/INTERRUPT command
Original comment by svof...@gmail.com
on 19 Feb 2008 at 1:09
Mostly done. BDS C chaining is probably related, but it's a new issue.
Original comment by svof...@gmail.com
on 22 Feb 2008 at 10:25
Original issue reported on code.google.com by
svof...@gmail.com
on 18 Jan 2008 at 10:14