LSI@UMass.BITNET (Peter Lawall, Logical Solutions, (413) 256-6800) (06/09/86)
Hi again,
Thanks for all your suggestions... I have finally tracked down the
problem with version 1.2 of 68K, and it is somewhere within the OS!!
The disk controller generates interrupts for data request and command
complete, but as CP/M 68K doesnt really have any nice provision for
background data transfers, I have merely been polling the controller
for data request and completion. Anyway, the interrupts are still applied
to the 68000, and herein the problem lies. Apparently version 1.1 left
the interrupt mask in its power-up state (all interrupts masked) but for
some strange reason version 1.2 DOESN'T!! So when the interrupt comes
along... BANG! Off the CPU goes to the interrupt vector, which my booter
fortunately set to a BRA tight loop so nothing got creamed...
Anyway.... blah! Pretty cruddy of them to do that without any mention
anywhere of it! Glad its fixed, and now I can look forward to debugging
version 1.3 soon... Hope no gremlins are lurking there....
As far as the track buffering goes, I was WRITING directory tracks
immediately (CP/M sets d1.w to 0001 as a flag -- nice of them) but the
problem is that the data still remains in the buffer and can be accessed
by subsequent DIR commands, etc even when the disk is out or swapped...
The built in commands don't allow you to mark the buffer as invalid after
the command finishes. Anyway the best kludge (short of the disk change
interrupt... not a bad idea, but it puts excessive restrictions on the
type of drive used...) that I have come up with is a timer that is set
each time the BIOS read or write sector commands are issued, and is counted
down to zero after a delay of say 1 second. So one second after the last
disk access an interrupt is generated, marking the buffer as invalid. It
should work, but there is NO reason that it couldnt have been done in the
OS with a call to BIOS function #0 (warm boot)! Grrr....
Anyone have any further comments about 1.3? Is the C Compiler still
messed up? or was that a single occurance of a bad disk?
Thanks....
Petermknox@NGP.UTEXAS.EDU.UUCP (06/13/86)
[Still waiting to hear anything about the 1.3 C compiler problem. My latest ploy (since tech support has not yet been any help), the DRI sig on CompuServe] A suggestion for a slight improvement: Your idea to set a timer to let one second elapse (to handle possible disk changes, without relying on a "open door" signal) is fine. But if you can get regular timed interrupts like that, don't unconditionally mark the track buffer invalid after one second. Instead, after each interrupt, check the READY signal from the drive (they ALL have that). If it is not present (NOT READY), *then* mark the track buffer invalid. That way you still get the benefit of the buffering on the startup for new tasks. One further note: if you put in the above, then ONLY mark the buffer invalkd on NOT READY. In other words, don't reset it unconditionally on WARM BOOT. mknox