bridger%rcc@RAND-UNIX.ARPA (Bridger Mitchell) (11/30/87)
There is a resurgence of interest in CP/M 2.2-compatible bdos's; at least two are under active development and not yet stable: Z80DOS and PZDOS. Carson Wilson's doc file in the z80dos library tabulates the heritage and major features of a number of variants; his z80dos is largely derived from P2DOS. Version 1.0 was released. 2.0 is being beta-tested now and is available on some z-nodes. Hal Bower and Cameron Cotrill have been perfecting PZDOS, also derived from P2DOS; it is nearing release. Automatic file time and datestamping is a feature many cp/m 2.2 users already have by using DateStamper. Z80DOS implements timestamps in a manner similar to that used in cp/m 3 -- using 1 directory entry every 4 for the stamps; however, its method conflicts (destructively) with cp/m 3 file stamps. PZDOS is aiming to give the user the choice of either DateStamper or cp/m 3-type stamps. The behind-the-scenes debate about timestamp formats is multifaceted. (I'm the author of DateStamper; read with salt-shaker at hand). Some of the issues are: The DateStamper format is the most portable -- DateStamper will run with no bios or bdos modifications on virtually any cp/m 2.2-compatible system, including 8080 cpu's. DateStamper includes full create/modified/accessed times and dates. But it requires the most space -- 1.0 to 1.25 K. The cp/m 3 and z80dos formats use up 1/4th of the directory entries, require replacement of the bdos, but use no extra memory in a z80 system (8080 versions are not available). A DateStamper disk can be transported to another cp/m 2.2 system and the datestamps will continue to be maintained on that system if DateStamper is installed. The other formats require a compatible replacement bdos that supports their format. It would be desirable to standardize on a single format for all of cp/m 2.2; that would enable all of us to use all of the timestamp-featured utilities that already exist (directory, filecopy, disk catalog, unix-make, for DateStamper) and are being developed, and to exchange fully-compatible disks. But the jury is still out on whether these dos's will evolve to that point... --bridger mitchell
michaelk@copper.TEK.COM (Michael D. Kersenbrock) (12/01/87)
Summary: Expires: Sender: Followup-To: >Automatic file time and datestamping is a feature many cp/m 2.2 users >already have by using DateStamper. Z80DOS implements timestamps >in a manner similar to that used in cp/m 3 -- using 1 directory >entry every 4 for the stamps; however, its method conflicts >(destructively) with cp/m 3 file stamps. PZDOS is aiming to give >the user the choice of either DateStamper or cp/m 3-type stamps. > >The behind-the-scenes debate about timestamp formats is multifaceted. >(I'm the author of DateStamper; read with salt-shaker at hand). Some >of the issues are: > >The DateStamper format is the most portable -- DateStamper will run Actually, I'd think that the cp/m 3.0 "type" stamps that are actually cp/m 3.0 compatible would be the most portable. It would allow 2.2 users to be compatible with the already existing standard as defined by DRI in CP/M 3.0. >It would be desirable to standardize on a single format for all of >cp/m 2.2; that would enable all of us to use all of the >timestamp-featured utilities that already exist (directory, filecopy, >disk catalog, unix-make, for DateStamper) and are being developed, and > >--bridger mitchell With a timestamp compatible with CP/M 3.0, ALL CP/M-80's would use a single format! existing CP/M 3.0 utilities (such as UNIX-like "make") may be usable by 2.2 users (see the CPM3 section of Simtel20 archives). To keep the mailer happy: ------------------------ _ _ _ _ _ , ' ) ) ) / // ' ) / / / / / / o _. /_ __. _ // /-< _ __ _ _ ____ /__,_ _____. /_ / ' (_<_(__/ /_(_/|_</_</_ / ) </_/ (_/_)_</_/ / <_/_) (_(_) (__/ <_ -- Mike Kersenbrock Tektronix Microcomputer Development Products Aloha, Oregon
bill@sigma.UUCP (William Swan) (12/02/87)
Summary: In article <8711301746.AA22038@newton.arpa> bridger%rcc@RAND-UNIX.ARPA (Bridger Mitchell) writes: >There is a resurgence of interest in CP/M 2.2-compatible bdos's; >at least two are under active development and not yet stable: Z80DOS >and PZDOS. >[...] >DateStamper includes full create/modified/accessed times and dates. But >it requires the most space -- 1.0 to 1.25 K. > >The cp/m 3 and z80dos formats use up 1/4th of the directory entries, >[...] >It would be desirable to standardize on a single format for all of >cp/m 2.2; that would enable all of us to use all of the >timestamp-featured utilities that already exist (directory, filecopy, >disk catalog, unix-make, for DateStamper) and are being developed, and >to exchange fully-compatible disks. But the jury is still out on >whether these dos's will evolve to that point... >--bridger mitchell I heartily agree with the desire for a uniform time-stamp mechanism. I just brought up P2DOS in the past couple weeks so I could get this feature. Although, as Bridger points out, it uses 1/4 of the directory entries, I find I usually run out of disk space with only half of the entries used. If I'm desperate for directory entries and don't care about timestamps (as I was last night when I had to re-assemble SYSLIB3), I can always clear the directory. Giving up 1-1.25K, as DateStamper requires, is a bigger issue for me. After my years with a CP/M manufacturer (*years* ago!) I got perhaps unduly sensitive to the issue of TPA. Some of the utilities I use like as much TPA as they can get (what I hear of Wordstar 4.0, of which I am anxiously awaiting delivery, puts it in this category). I, for one, am reluctant to reduce the available TPA on my system, especially since I already have the feature without. On the other hand, if the DateStamper mechanism were to become the standard, I'd have less trouble justifying it. If the {P2,Z80,PZ}DOS reflects the CP/M-3 system, though, I'm not sure which system gets my nod. I don't know much of DateStamper (is this a commercial product, Bridger, and if so how much and where?), nor how it hooks into the system. The idea that it is 808{0,5} compatible is great, it doesn't limit this feature to us Z80 users. How is it destructively incompatible with the CP/M-3 method? Also, are utilities written using CP/M-3's timestamp mechanisms usable with P2DOS? I seem to recall somebody wrote a make utility for CP/M-3, for example. I presume they wouldn't work with DateStamper. -- William Swan {ihnp4,decvax,allegra,...}!uw-beaver!tikal!sigma!bill
mlinar@poisson.usc.edu (Mitch Mlinar) (12/03/87)
In article <1505@copper.TEK.COM> michaelk@copper.UUCP (Michael D. Kersenbrock writes: > >Actually, I'd think that the cp/m 3.0 "type" stamps that are >actually cp/m 3.0 compatible would be the most portable. It would >allow 2.2 users to be compatible with the already existing standard >as defined by DRI in CP/M 3.0. > >>It would be desirable to standardize on a single format for all of >>cp/m 2.2; that would enable all of us to use all of the >>timestamp-featured utilities that already exist (directory, filecopy, >>disk catalog, unix-make, for DateStamper) and are being developed, and >> >>--bridger mitchell > >With a timestamp compatible with CP/M 3.0, ALL CP/M-80's would use a >single format! existing CP/M 3.0 utilities (such as UNIX-like "make") >may be usable by 2.2 users (see the CPM3 section of Simtel20 archives). I disagree with both postings to some extent. (1) QP/M is actually just as portable as DateStamper and is a drop-in replacement for CP/M 2.2. Read this: you give up *no* extra memory and *no* directory entries to have full time/date stamping of create/update/ backup. If you don't have a real-time clock, that is ok; but having some sort of counting clock helps. You need a Z80 for this guy. QP/M was written from scratch as a Z80 operating system compatible with CP/M; DateStamper was initially a set of patches to 2.2 but has evolved some since. I think both are fine (but I am biased to QP/M since I wrote it :-). We already have a full set of utilities (such as QSWEEP, QPIP, QSTAT, QDIR, QBACKUP, MAKEQ, CATALOGQ) available which uses the time/date value - primarily through DOS calls explicitly assigned to time/date stamping. (2) I take issue with the CP/M 3.0 method of stamping disks. Only a *single* date/time is supported (yuck), but you GIVE UP DIRECTORY ENTRIES. Maybe this is not a problem when you: (a) start with a virgin disk (b) don't mind moving files to reformat (c) all of your files are large but it has been my experience that the ratio of disk use to directory use on many systems is pretty close percentage wise. Floppy formats are fixed, and it is stupid to increase the number of directory entries just for CP/M 3.0. A similar thought for hard drives: why search through all those extra FCB entries which are really filename related? A time/date file (such as used by DateStamper [or was] and by QP/M) is a better alternative in the CP/M world. ------------- On the issue of compatibility, I agree completely. Let's standardize on something, the first being a time/date DOS call that fetches all of the time/date information for a given file. That way, even on the different OSes, at least all time/date DOS calls would work. A complete standard would be much more difficult to implement at the file/directory level - as the issues here can become religious :-) -Mitch