🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: mod.computers.68k
Article #55

Answers!

#55
From: Peter Lawall, Logical Solutions,...
Date: Mon, 09 Jun 1986 04:05
35 lines
2808 bytes
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
Technical Details
Message-ID: <860609000558.00000712.BKMP.AA@UMass>
Path: arc1-ca.pugleaf.net!utzoo!decvax!ittatc!dcdwest!sdcsvax!ucbvax!UMass.BITNET!LSI

Show Full Headers
Complete Article Headers
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: arc1-ca.pugleaf.net!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