Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU Path: utzoo!decvax!ittatc!dcdwest!sdcsvax!ucbvax!UMass.BITNET!LSI From: LSI@UMass.BITNET (Peter Lawall, Logical Solutions, (413) 256-6800) Newsgroups: mod.computers.68k Subject: Answers! Message-ID: <860609000558.00000712.BKMP.AA@UMass> Date: Mon, 9-Jun-86 00:05:58 EDT Article-I.D.: UMass.860609000558.00000712.BKMP.AA Posted: Mon Jun 9 00:05:58 1986 Date-Received: Fri, 13-Jun-86 00:43:38 EDT Sender: mwm@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 35 Approved: info-68k@ucbvax.berkeley.edu 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.... Peter