ac@utgpu.UUCP (04/06/87)
I believe I understand now why a write to a write-protected disk will crash the system if the delay code is incorrect. The delay is required by the 1793 controller whenever a command is stored in its command register. Failure to delay will cause strange things (not sure what, they didn't say). But why does to long a delay cause problems and only for the write to a write protected disk. Well the write to a write protected disk causes an almost immediate failure return in the form of an interrupt. The code which gets control from this NMI assumes it understands the state of the stack. If the delay code is still executing at the time this interrupt occurs the stack will still have stuff left on it from the delay code (remember the lbsr to lbsr to lbsr to rts code). It seems the whole code would have been much more robusts if they had used a simple loop instead of the bizarre lbsr code. -- Name: Mark Acfield (University of Toronto Computing Services) Path: ihnp4!utgpu!ac Alias: ac@utoronto.bitnet
ingoldsby@calgary.UUCP (04/10/87)
In article <1987Apr6.165809.16100@gpu.utcs.toronto.edu>, ac@gpu.utcs.toronto.edu (Mark Acfield) writes: > > I believe I understand now why a write to a write-protected disk will crash > the system if the delay code is incorrect. The delay is required by the > 1793 controller whenever a command is stored in its command register. Failure > to delay will cause strange things (not sure what, they didn't say). But > why does to long a delay cause problems and only for the write to a write > protected disk. Well the write to a write protected disk causes an almost > immediate failure return in the form of an interrupt. The code which > gets control from this NMI assumes it understands the state of the stack. > If the delay code is still executing at the time this interrupt occurs the > stack will still have stuff left on it from the delay code (remember the > lbsr to lbsr to lbsr to rts code). It seems the whole code would have > been much more robusts if they had used a simple loop instead of the bizarre > lbsr code. > > This is a problem that occurred in the original Newdisk program (driver) by Dave Lewis. If the people at Tandy paid any attention to the goings on on this net, they would have been aware of the problem and not repeated it since both the problem and solution were thoroughly discussed months ago. It is indicative of the crummy device drivers they write (yes the code is very unsafe). Has ANYONE managed to get the CC3Disk driver to work well with 80 track double sided disks? I think there is an initialization problem since once it did work reliably for me (I had just been messing with some old CoCo2 software that I think put the machine in an unusual stae). Is anybody else having troubles? Perhaps OS9 Level II doesn't like my old controller (I've added +/- 12v). OS9 Level I thinks its OK, though. Terry Ingoldsby ihnp4!alberta!calgary!ingoldsby
jimomura@lsuc.UUCP (Jim Omura) (04/20/87)
In article <872@vaxb.calgary.UUCP> ingoldsby@calgary.UUCP writes: >Has ANYONE managed to get the CC3Disk driver to work well with 80 track double >sided disks? I think there is an initialization problem since once it did >work reliably for me (I had just been messing with some old CoCo2 software that >I think put the machine in an unusual stae). Is anybody else having troubles? >Perhaps OS9 Level II doesn't like my old controller (I've added +/- 12v). >OS9 Level I thinks its OK, though. Having read the report on the hardware fix, and having 3 disk controllers, I decided to do a test. My Disto controller worked fine. Yes, I now have 80 cylinders/double sided running! The problem is that there seems to be a design conflict here. The *only* controller I had that would read single *density* was my original Shack controller under Level I at 0.9 mHz. Now, the Disto *might* be able to read single density at 1.8 mHz., but I haven't got software capable of trying that yet. It seems I have to have 2 controllers and 2 systems to do everything I want for the time being. The Disto, to handle Level II properly, and the Old Shack controller to handle single density track 0 for OS-9 Standard format. I dunno. Maybe I'll end up with the Sardis controller. Cheers! -- Jim O. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 ihnp4!utzoo!lsuc!jimomura Byte Information eXchange: jimomura