LSI@UMass.BITNET.UUCP (06/03/86)
Hi,
I've been developing a small 68000 based system here, and
originally chose the CP/M 68K O.S. a few years back, as it was
the only one available. The hardware is now complete, and I
have a BIOS that works fine with the original release (Ver 1.1)
of the operating system. The problem seems to be in upgrading
to version 1.2 of 68K (did someone say that they are up to 1.3?).
When the same BIOS is linked to the ver 1.2 CPMLIB, the system
boots properly, and all the built in functions work fine. When
you try to execute one of the disk resident utilities, however,
problems crop up. The utility loads and runs properly, but as
soon as the utility tries to access a drive, the system hangs.
Weird. Anyone have any comments? Suggestions? Help?
Another thing about the BIOS: I have implemented track
buffering, but not without a hitch. It seems that all the disk
based utilities and applications programs do a proper system
warm boot on exit (either through BDOS 0 or RTS) which in turn
calls my BIOS warm boot function that marks the track buffer as
invalid. This is all fine and well, and the disks can be
swapped after this occurs. The built in commands do not appear
to call the warm boot function, however. The current track is
not marked as invalid, and if, for instance, the track in the
buffer is the directory track, the same directory will appear
for subsequent DIR commands if you change disks. The only way
around this is to throw a <CTRL C> character in after each DIR
command. What a pain in the butt! There HAS to be a way around
this! (short of switching to OS9-68K, which looks like it might
be a good idea!)
All we have and know of here for CP/M 68K is the O.S. and
its futilities, the Alcyon compiler, and Mark of the Unicorn's
Mince screen editor. How about somebody posting a list of
available software (with addresses and phone #'s!) here if they
know of any... Or is Mince the only real third party program
out there???
Petermknox@NGP.UTEXAS.EDU.UUCP (06/04/86)
Peter, That one *IS* strange. There should be NO minimal requirements to switch anything in the BIOS when going from 1.1 to 1.2. There are some extra features in 1.2 ( like type-ahead) that may not do anything unless you make BIOS additions, but they are not required. There MAY, however, have been a small unnoticed bug in the BIOS which caused no problem in 1.1, and now shows up in 1.2. I would double check the DPH and DPB tables, and make sure the ALLOC and CKS tables have enough room. Then put some kind of trace on the BIOS calls and see just how far it is getting. As for the warm-boot question: That issue goes back even to 1.1 (and before). We also ran into problems with not getting some of the functions issued when needed (so the software didn't get a chance to re-examine the density of the floppy). The trouble is that Gregg and the others were trying to get around the big delay whenever a warm- boot was done (ala CP/M-2.2). So they solved that problem, and caused others. STAT and several transient routines are NOT affected by a warm-boot. Do a DIR A: and DIR B:, then a STAT (to get the free space). Now change disks, and do another STAT. NO DISK ACCESS. And it will reference drive B:, even if there is no diskette in it (if you check the "logged in" drives). The transient commands have never forced a warm-boot anyway. We finally added a short (about 8 lines) routine called NEWDISK.68K which sent a RESET DRIVES command if needed. mknox@ngp.utexas.edu
mwm@OPAL.BERKELEY.EDU (Mike Meyer, I'll be mellow when I'm dead) (06/04/86)
My cp/m-80 system (RIP) did track buffering. They solved the problem of disk changes by caching door open interrupts from the 8" drives. Amigados does the same kind of trick on 3" drives, so I would assume that both 5" and 3" drives (of the correct make) supplied that interrupt, or something similar (door closed?). After the disk changed, the cp/m-80 system would beep at you and say "Put that disk back! Buffers not flushed!" After you put the disk in, it would say "That better be the same disk!" (gee, it must have had both open and close interrupts.) It wasn't kidding; flushing the directory cache on the wrong disk produced to pretty much garbaged both disks. <mike
marlinw@tekchips.tek.CSNET (Marlin Wilson) (06/04/86)
In writing a track-buffering bios for CPM-86, I wrote directory tracks immediately. Even for non-removable disks, since cpm machines have no requirement for a shut-down procedure and to give greater reliability in case of power glitches. A flag indicating directory sector access is set in a register on entry to the bios write routine. A little more overhead, but I think worth it. Marlin Wilson Tektronix, Inc <somewhere, usa>
mknox@NGP.UTEXAS.EDU (mknox) (06/05/86)
Mike, "My cp/m-80 system did track bufferring. They solved the problem of disk changes by caching(sic) door open interrupts..." Yeah, that works fine. The problem is that most 8" (and most 5 1/4) drives do not produce door-open interrupts. [Of course, then there are the "pushy" ones that latch the door and will not LET you take the disk; and the Persci's that have no door, but will not give you BACK the disk unless you ask 'pretty please'.] The other way to detect disk changes is to check for disk-not-ready. (which is, I suspect, how yours detected the door being closed again) The trouble with using this for detecting changes is that it normally needs to be polled, and that means most systems can be fooled during compute-bound jobs. The exception is those using NEC 765A (or INTEL 8257(?)) disk controllers. There the controller chip does the polling constantly. If you have this capability, then there is no problem adding caching to CP/M-68K. It has the usual hooks (for blocking/de-blocking) which enable write-through and read-through, as well as the standard caching options. [Now, if only I had a 765A or a door-open interrupt.] mknox
mwm@ucbvax.UUCP (06/06/86)
Minor correction: The NEC765/Intel8272 do ready polling only when they have nothing else to do. If you're reading/writing to one drive you can change the disk in the other and it won't know the difference.