On Mar 30, 2012, at 10:05 AM, Jim Brain wrote: > On 3/30/2012 11:30 AM, Nate Lawson wrote: >> Here are the decodings: >> >> On Mar 29, 2012, at 5:54 PM, Jim Brain wrote: >> >>> I bow to the knowledge of those who understand DOS better than I, but I am confused about the operation of the ATNACK circuit in the 1541. >>> >>> Now that I finally have a good PC-based logic analyzer, I submit two traces for perusal: >>> >>> load"$",9 >>> http://s15.postimage.org/pym7z9i23/with_ACK.png >> ATN - 29 F0 (open 9, 15) >> 24 30 ('$0') >> ATN - 3F (close 15) >> >>> If I then remove pin 10 of UB1 (the '06 that outputs the result of the ACK circuit onto the DATA line), I get this trace >>> >>> http://s15.postimage.org/ar68ewq7b/without_ACK.png >> >> Using this pic: >> http://s15.postimage.org/ciz79t9k9/without_ACK.png >> >> Same as before, but during the close (3F), Ingo is right that the drive is not in the main loop because it is servicing the dir request and thus it doesn't get back to reading the flag set by the IRQ handler to say that it should release DATA. >> >> The question is, why doesn't it ever get back to that point, maybe a few seconds later? >> > > I can confirm that, even if I hold off indefinitely, DATA never goes low. I wonder if something is clearing the flags byte? In the ROM, an interrupt caused by ATN leads to the code at $E853 storing a flag for the main loop. The main loop comes around and finds the flag active and calls $E85B in the normal case. We see this working for the first part (open command). It then releases the CLK line at $E86D and then sets the DATA line low at $E870. It then sets ATNA and then waits for either ATN to be released (entire command done) or CLK to be released (first command byte ready). If CLK was released, it begins reading the command byte. So maybe the return from handling the directory routine or close routine behaves differently? I wonder if something is getting reinitialized. -Nate Message was sent through the cbm-hackers mailing listReceived on 2012-03-30 18:00:15
Archive generated by hypermail 2.2.0.
