This is the text of a letter I wrote to Carson Wilson, author of Z80DOS, the superb new datestamping BDOS for Z80 computers, about my first few days' experiences with it. - Rick Charnes 15 October, San Francisco Carson, I'm writing this with ..... Z80DOS INSTALLED ON MY HARD DISK!! ALL RIGHT! How satisfying. Does that make me the first person on the planet? It installed with no problems. (Well, after 2 or 3 false starts that is, but that's life in the big city...) As I mentioned to you before I have no problem running DateStamper under Z8DOS and fully intend to use BOTH datestamping systems. I even did something rather risque' -- I've installed DateStamper in a non-standard, actually superior location between the BIOS and the start of the Z- System segments. Normally it is put either in high TPA below the CCP -- in which case it eats up 2k TPA in addition to what it normally uses since it prevents loaded programs from overwriting the CCP -- or inside one of the Z-System segments such as the IOP or RCP in which case all or part of that particular feature is lost. Above the BIOS it requires rewriting your whole memory map, but that was half the fun of it. With Z-COM such a procedure is quite complicated (Jay explained how in TCJ) but with the Z initialization routines written right into the BIOS such as we have with the Morrow bootable disk it's a breeze. I spent last night going in to my A0:APP and A15:SYS directories and pared off about 75 entries in order to run INITDIR on them. It was an amazing surgical procedure. As a librarian I have an extremely strong antipathy towards throwing anything away and very strong tendencies toward collectionism, but being a doctor for an hour or so, using ZFILER's group macro facility to throw tagged stuff into my COMMAND.LBR and then erase it, was most enjoyable. I think I'm none the worse for it. Running INITDIR on each of the 4 drives on my hard disk was rather scary -- sort of the "moment of truth" that officially inaugurates one into the wonders of Z80DOS -- but I did it, and I've now got room for all the date stamps. I normally have 512 possible entries per drive and now have 394. I'll try to stick to this; it's just a matter of living lightly on the land and keeping everything neat and tidy. Erasing all one's various TEST.COM's after using them. One thing, though -- if one ever decides to _not_ use Z80DOS is there then any way to restore the full number of entries to one's directory? I understand that with INITDIR you can erase the old time stamps but I don't know any way to fully restore the directory to a "4 in 4" state; one seems forevermore locked in a "3 in 4" condition. It's not that big a deal, but I'd like to know. Here's the alias I'm using for editing: VDE=NW if ex $1;app:savestmp app:datehold=$1;app:r$0 $* << app:savestmp $1=app:datehold;else;app:r$0 $*;fi Note the "R$0"; I've renamed my "real" VDE and NW to RVDE and RNW respectively; the above alias works perfectly with these and can be used for any editor. The next day ... By the way, I was initially VERY upset with WS4 insistence on behaving as a true shell in that it completely screws up any scheme to use it in an alias such as above. (I don't know if you've been following the conversation on Jay's BBS, but we discovered that since it behaves as a true shell it of course can be used only with difficulty in an alias since it will only run after the rest of the CL is cleared) In any case, Dave McCord made a suggestion on how to get around the problem: deliberately load up the shell stack ("with multiple invocations of HSH or z/filer") before WS is invoked. In this way, if WS sees the shells tack is full, it will not behave as a shell, since it can't install itself as one. Well, what I did rather than load up the shell stack was to poke the relevant bytes in the environment descriptor (FE20h and FE21h for the "standard" system) to instantly and temporarily create a system having only a single shell stack entry of 128 bytes in length: WS POKE FE20 01 80 if ex $1;app:savestmp app:datehold=$1;app:realws $* << app:savestmp $1=app:datehold;else;app:realws $*;fi;POKE FE20 04 20 works just fine. OK, I've just changed the date with TIME.COM and I want to see that BEAUTIFUL sight -- different creation and modification dates on a word- processed file... Oh, a comment about DATEDEMO. I assembled it up into a COM file. It doesn't pause every screenful. Also: the date of access information is right flush against any 11-character filename, actually touching it. Needs to be more space there. Do you intend that as a replacement for TDIR? It's your own, right? TDIR is someone else's. Was very pleased to discover, by the way, that one of programs that I had assumed was ZRDOS-specific and was sad about the fact of giving up and finding a replacement for is in fact not! VTYPE, a lovely file viewer and scanner (VERY fast moving from top to bottom; it'll do a 125k file in about two seconds flat), runs fine under ZRDOS. I wonder, actually, if it's because I left the string of letters 'ZRDOS+' in the BDOS header as you recommend doing in Z80DOS.BLD (for CP/M, I assume). Am I correct in my assumption that the CP/M _command processor_ must find the DRI header in the BDOS, and that's why you recommend leaving it in? I assume I didn't need to do the same with the ZRDOS+ header but did it nonetheless and wonder if it might be responsible for the continued successful operation of VTYPE. MOVE.COM, another program I'd assumed would only run under ZRDOS, runs fine in my new BDOS. I'd started recently using MAKE but don't like it because it does something weird with files that take up more than one directory entry: its status reporting to the screen indicates one operation for each directory entry of the file! In other words, if I am changing the user area of BBMSG.LBR which is 88k in size from D3: to D7: here's what MAKE displays on the screen: D3:UPLOAD>make bbmsg.lbr d7: MAKE - Version 2.6 for ZCPR3 BBMSG.LBR = 7 R/W DIR Non-ARC BBMSG.LBR = 7 R/W DIR Non-ARC BBMSG.LBR = 7 R/W DIR Non-ARC I suppose it is actually changing the user area for 3 directory entries but I really don't want to know about it! MOVE.COM doesn't do this. TDIR does something quite funny if run on a user area greater than 9. It's really kind of amusing. Look an an ASCII conversion chart. See the characters after 0-9? There's : ; < = > and ? . Well, that's exactly what TDIR displays after user area 9. If you do a directory of A15:, TDIR's status reporting displays the current directory as A0?: And A14: is 'A0>:' and A13: displays as 'A0=:' and A12: is 'A0<:' and A11: as 'A0;:' and A10 as 'A0::'. It's quite funny. PUBLIC FILES ------------ First time in my life I ever created public files in any way other than the ZRDOS+ way. For sentimentalism's sake I nominated NSWEEP for the job and used its good-old esoteric 'Y' command to set the flags on the 2nd filename character. Works like a charm, just like ZRDOS+'s PUBLIC directory feature did. Even left them in their old directory and kept it named PUBLIC:. Why not? The Echelon program PUBLIC.COM is interesting. Oh, I forgot: you never used ZRDOS+. It implements its public feature by setting a directory as public with a program PUBLIC.COM. COMP, SFA and DFA all at least abort and give you a message under Z80DOS that 'Error: you must be running ZRDOS'. PUBLIC.COM loads properly, seems as if it's working, and even gives you a message telling you that the directory that you specified as public is indeed public. Then when you try it -- it ain't. PUBLIC.COM needs some error- handling code. But setting the 2nd filename attribute on all my ex-public directory'ed files works just fine and dandy. By the way, I like the feature that you can only erase a public file from the home user area. ZRDOS does not have that safety feature, I don't believe. One thing I'm curious about. Your instructions in Z80DOS.BLD for loading in the newly-created Z80DOS.HEX and CBIOS.HEX intrigue me. I have always used MLOAD to create a binary file to prepare a file for this purpose. I create a COM file, and then load it in with DDT(Z) to my CPM.COM at the offset address at which the OS segment is located in CPM.COM. You know, the CCP is at D00, BDOS at 1500 and BIOS at 2300 so the offset for the "R" command is C00, 1400 and 2200 respectively. When I tried this technique, loading an MLOAD'ed Z80DOS.COM in to CPM.COM at 'R1400' -- and also my CBIOS.COM at 'R2200' it just didn't work. Since I changed the whole memory map I also needed to reassemble my cold boot loader and load that in to CPM.COM. In my system image file (CPM.COM) my cold boot loader is at 900 so I loaded in my MLOAD'ed ZBOOT.COM at 800 and it just didn't work. Why? Your method -- calculating the difference between where the segment is in CPM.COM and where it runs in memory and loading in the HEX file at that offset -- worked fine. You know what I wish TDIR or DATEDEMO would do? Something that I feel is an obvious thing for a directory program to do but very few do: tell you how many possible directory entries remain on the disk. The very first dir program I ever used in my life, so primitive it doesn't even know about user areas, does this --- but nothing I've found since, from the grandaddy XDIR to SD to Eric Meyer's DA to Terry Hazen's DD, display this. Why? With my new, more-limited-in-number directory this information becomes very important to me. Sure, you can take the number of USED entries that _is_ displayed to you and subtract from that the number that you might possibly remember you can potentially have ... but that's really the long way around the problem. Very glad you left in the code in ZFILER and PPIP that supports DateStamper. So now we have two programs that support both datestamping systems. G'night, comrade fellow Morrow user. Thanks for a great BDOS.