RCONN@Simtel20.ARPA (07/02/84)
From: Richard Conn <RCONN@Simtel20.ARPA> ... is coming along quite nicely. The new DU3 is finished, complete with its online documentation (which is rather extensive) and its new screen-oriented editor. The editor ties in as an optional command-line interface. You can select it in place of the simple DU3 prompt, and it displays the block you are currently positioned to, a small menu of commands, and a cursor which points to a byte in that block. You can move the cursor around to select any particular byte, and then you can enter a string of chars or a list of hex values to place into the block starting at the cursor. You can then write the block to disk, advance to the next block, backup to the previous, etc, as well as issue any value DU3 command string, including macros, to go through a more complex command sequence and then return to the editor automatically at the last block you were positioned at. DU3, by the way, stands for Disk Utility version 3. There now exists the prototype of MU3, a screen-oriented Memory Utility, which resembles the DU3 screen-oriented editor but works on memory only. Great for looking at ZCPR3 itself, testing RCPs and FCPs, etc. I am concurrently creating the DEBUG Resident Command Package which is a scaled-down version of MU3, but it can be invoked without impacting the TPA at all. Finally, the new VFILER for ZCPR3 is almost done. Just a few hours work on it to go. I was in the middle of VFILER when Hal Carter came up with the idea of having an MU3 utility after he saw DU3 run, and so the break to create MU3 occurred. I need to play with MU3 a little to decide what features it really needs before it will be finished. Once DU3, MU3, and VFILER are done, the last major utility, VMENU, will be on the agenda. VMENU is a combination of VFILER and MENU which I think will be a neat tool by itself. I have some concerns about how fast it will be, creating new directory displays every time it is invoked, and I think these concerns will be resolved only after VMENU is running and I have used it a few times. A few little utilities will also be included in the ZCPR3 Phase 2 release, but they are minor in terms of effort. The book is now outlined, with Hal Carter providing many useful ideas on what its structure and nature should be (thanks, Hal). I think it will be vastly superior to the ZCPR2 documentation, having a nice table of contents, index, appendices summarizing commands available with the various utilities and subsystems, etc. A lot of the book can be put together from the online documentation, so that should go quickly, but there are still major portions which I need to write. I hope to have the outline and online documentation fill complete and sent to the publisher by the end of this week, so this part can be edited while I proceed with the newer, detailed sections. The second book, on the ZCPR3 libraries, will also be started soon, but I'm not sure when. In the meantime, the installation manual and user's perspective document are being printed by Echelon now, and Echelon plans to distribute it with the $39 basic set of disks. You can also get these books independently from Echelon for a small price ($9 was the last figure I heard). Contact Echelon for details. You, of course, have several options in acquiring hardcopy of this documentation -- it is on disk and can be printed, but the whole thing is on the order of 160 pages. Your local computer club may decide to make a print run on it also. Note that I have been talking about the Phase 1 manuals (on the Phase 1 disks) so far. The books are a different matter and will not be available on disk (who would want to print something THAT BIG anyway?). Finally, there may be a ZCPR3 newsletter in the works. More details later if this becomes reality. Rick
RCONN@Simtel20.ARPA (08/02/84)
From: Richard Conn <RCONN@Simtel20.ARPA> You have a good point ... it is certainly not too late to correct. The reason I did that was because, while \n represented the LF char literally, the effect of using it with routines like PRINTF was to issued CRLF. Hence, I elected to let \n mean CRLF and \l was added for LF only. I think I'll move back to \n meaning LF only and either not have a char for CRLF (it is easy enough to create a word for it) or make up something. Rick
RCONN@Simtel20.ARPA (08/02/84)
From: Richard Conn <RCONN@Simtel20.ARPA> This is the message from Richard I responded to re DPROG. -- Rick Date: Thursday, 2 August 1984 06:40-MDT From: dual!islenet!richard at Berkeley To: RCONN at Simtel20.ARPA Re: ZCPR3 Phase 2 ... It all sounds very interesting. Can't wait to see it. One question; you appear to be using a lot of C conventions, which is very nice, why this funky little incompatibility? > \l Line Feed Char (LF) > \n New Line char (CRLF pair) > \r Carriage Return char (CR) Was it really necessary to have <crlf> available as a single unit? If so, why not create a new notation for it such as "\$" ? The way you have it, you have broken two of the most important C character notation conventions. Now if you were to provide the facility to have newlines (0xa) be converted to crlf's on output that would be useful. Keep up the good work. Richard Foulk Honolulu, Hawaii
RCONN@Simtel20.ARPA (09/27/84)
From: Richard Conn <RCONN@Simtel20.ARPA> Phase 2 is now on its way to SIMTEL20, XEROX, and SIG/M. The last shipment from SIMTEL20 took 2 days to get here, so I guess that it will not be long before you see it on SIMTEL20. You will be notified when SIMTEL20 has the software. Rick
RCONN@SIMTEL20.ARPA (10/03/84)
From: Rick Conn <RCONN@SIMTEL20.ARPA> Isaac, 1. As per the norm, I haven't observed the problem with ? that you mentioned. I just read your note, returned to my system, entered DU3, typed ?, and read thru the help screens. I also did the same thing from the command line: DU3 ?. I don't doubt that the problem exists as you say it does. Probably a subtle difference between our systems. Also, I'm not surprised that the problem was fixed in DU2 and it never got back to me. Under the old system (without Echelon around to be a point for CM control), that happened a lot. People would make changes and I would never see them, and, even if I did, rather than getting a DIFF file which would point exactly to the changes, I would get a new source and be expected to go thru it to figure out what they did (of course, it is still THIS way). Quite a time loss. Do you want to track the problem and point it out to me? This may be best since I am not able to duplicate it. 2. Your arrow keys problem is typical. That's why the old Wordstar sequence is still in there as well. Rather than reassembling to give you a different exit char, you could also zero the arrow key definitions for the 820-II and use the WS keys instead. Then there would be no conflict. Either way. Rick -------
RCONN@SIMTEL20.ARPA (10/03/84)
From: Rick Conn <RCONN@SIMTEL20.ARPA> Thanks to Frank Wancho, the Phase 2 files of ZCPR3 are now on SIMTEL20. They are in ITS binary format, and the directory is MICRO:<CPM.ZCPR3P2>. Enjoy! Rick -------