1-Jun-87 22:41:53-MDT,1127;000000000000 Return-Path: Received: from decwrl.dec.com by SIMTEL20.ARPA with TCP; Mon, 1 Jun 87 22:41:16 MDT Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34) id AA03540; Mon, 1 Jun 87 21:40:19 PDT Message-Id: <8706020440.AA03540@decwrl.dec.com> Date: 01-Jun-1987 1658 From: w_smith%wookie.DEC@decwrl.DEC.COM (Willie Smith, LTN Components Eng.) To: info-cpm@simtel20.ARPA Subject: re: UUENCODE and UUDECODE in Z-80 assembly I just realised when I saw the call for a faster UUDECODE that I have most of the pieces I need to put together such a program, but I don't fully understand the 'protocol'. Is there a protocol document available somewhere? I sort of get the basic idea, but there's a number in the first line of the file that doesn't change with different files, but I've heard changes with different versions of the encoder, and there's an 'M' as the first character of every line, and such like that. Many thanks in advance. Willie SMith w_smith@wookie.dec.com w_smith%wookie.dec.com@decwrl.dec.com {usenet backbone}!decwrl!wookie.dec.com!w_smith 2-Jun-87 17:18:09-MDT,1010;000000000000 Return-Path: Received: from beaver.cs.washington.edu by SIMTEL20.ARPA with TCP; Tue, 2 Jun 87 17:16:46 MDT Received: by beaver.cs.washington.edu (5.52.1/6.3) id AA25799; Tue, 2 Jun 87 16:13:47 PDT From: tikal!amc!jon@beaver.cs.washington.edu Return-Path: Received: by tikal.Teltone.COM (smail2.3) id AA12200; 2 Jun 87 15:46:32 PDT (Tue) Received: by amc.APPLIED-MICROSYSTEMS.uucp (5.51/AMC-1.8) id AA24523; Tue, 2 Jun 87 14:51:48 PDT Date: Tue, 2 Jun 87 14:51:48 PDT X-From: amc!jon (Jon Mandrell) Message-Id: <8706022151.AA24523@amc.APPLIED-MICROSYSTEMS.uucp> To: tikal!uw-beaver!simtel20.arpa!info-cpm@beaver.cs.washington.edu Subject: posting information I have just finished work on a version of UNIX make which runs on CP/M. I am going to be releasing it as a share-ware product, and would like to post it to the list. Do you have any problems with this? Or any suggestions of how to go about it? 2-Jun-87 18:54:22-MDT,2176;000000000000 Return-Path: <@wiscvm.wisc.edu:A-PIRARD@BLIULG12.BITNET> Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Tue, 2 Jun 87 18:53:47 MDT Received: from BLIULG12.BITNET by wiscvm.wisc.edu ; Tue, 02 Jun 87 11:55:59 CDT Received: by BLIULG12 (Mailer X1.23b) id 1015; Tue, 02 Jun 87 16:09:18 ULG Date: Tue, 02 Jun 87 16:07:13 ULG From: Andre PIRARD Subject: CP/M on the V20 To: info CP/M I started microcomputing on a self built CP/M machine (I wrote my own ROM and BIOS). Now I own an IBM PC clone in which I plugged a V20 chip. Of course I'd like to be able to use it to run CP/M. I have tried several software emulators, but just one using the V20, giving a mere 52K TPA. They are of several type: 1) stubs to concatenate ahead of a CP/M load module. 2) simulators executing the filename in the parameter line. 3) emulation of a CP/M environment with CCP. Completeness of the simulation varies. Some features such as get allocation vector (function 1B) or BIOS physical disk access are virtually impossible to emulate when using MSDOS disks and files. But many miss the point that if MSDOS returns code 3 to a file read (partial record read, filled with zeroes), it should be translated to 0. That's why I feel best to own source code. I like to have the complete CP/M environment, but solution 1 gives the best of both worlds if one concatenates the stub to a relocating and reloadable CCP. I have read an article stating that GFI sells a V20 type 1 product with source code. It achieves the tremendous TPA size I am looking for, but the sample code listed was not too encouraging. Any comment? Is there anything available in the public domain? I wouldn't mind spending some time adapting a CCP to a type 1 stub. Some additional MSDOS commands such as change path would be useful. Thanks in advance. Andre PIRARD SEGI - Universite de Liege 15, av. des Tilleuls B4000 LIEGE (Belgique) +32 (41) 520180(449) Bitnet: A-PIRARD%BLIULG12 Arpanet: A-PIRARD%BLIULG12.BITNET@WISCVM.WISC.EDU 2-Jun-87 21:54:14-MDT,1469;000000000000 Mail-From: KPETERSEN created at 2-Jun-87 21:54:04 Date: Sun, 31 May 87 12:00:45 CET Message-ID: Sender: "Eberhard W. Lisse" From: "Eberhard W. Lisse" To: Keith Petersen Subject: Floating Point Routines ReSent-From: KPETERSEN@SIMTEL20.ARPA ReSent-To: Info-Cpm at SIMTEL20.ARPA ReSent-Date: Tue 2 Jun 1987 21:54-MDT Hi, a friend of mine is looking for the following: Source of a BASIC-Interpreter with floating point arithmetics in 8088/Z80 or 80286 assembler or floating point arithmetic routines in same assembler languages to be incorporated into a to be written BASIC interpreter. Purpose: He is working on his thesis in chemistry engineering which involves develop a portable real time data aquisition system (hardware and software). That system will run under a BASIC enabling the useres to write the programs for each run in a high level language. We are also looking for ISAM routines either in source code or OBJ files to be run on an IBM-PC/XT/AT, preferably public Domain. I'd appreciate any pointers to where to get those files if they exist. I have no ARPA access here in Germany. I can access the ARCHIVE- REQUEST@SIMTEL20.ARPA by mail if they are already there. Otherwise one can send the files as UUencoded mail to this account. thanx in advance, el 2-Jun-87 23:40:54-MDT,5049;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Tue, 2 Jun 87 23:40:07 MDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA15223; Tue, 2 Jun 87 22:28:27 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Jun 87 02:42:29 GMT From: phoenix!pguhatha@princeton.edu (Puragra Guhathakurta) Organization: Princeton Univ. Computing and Information Technology Subject: zcpr3.3 Message-Id: <365@phoenix.PRINCETON.EDU> Sender: info-cpm-request@simtel20.arpa To: info-cpm@simtel20.arpa ZCPR3.3 : some first comments Peter Teuben, June 2, 1987 This concerns ZCPR3.3, the latest update in the line of command processors for CP/M, and my first experiences. We have all watched ZCPR grow over the past years to a fairly grown up module of what we now call the Z-system. None of the original modules from Digital Research are still used, the CCP being replaced by ZCPR and BDOS replaced by ZRDOS (often we write our own BIOS's). ZRDOS can be only be obtained commercially (Echelon), but ZCPR(3.3) can in principle be obtained for free (although at Echelon you have to pay $4x, but I guess they will accompany my order with a nice installation manual). However, I was impatient, and got the 100k of initial startup sources from SIMTEL20. (That's for free, as most BBS's are, I presume) For me this kind of installation is just an evening of work, and very amusing to do so. I installed ZCPR3 last summer in just an evening, including all modifications to the BIOS (thanks to the excellent documentation by Richard Conn). Last september I witnessed a rough discussion between Richard Conn and Jay Sage, on their use of the appropriate assembler for the 'Z-Libraries', i.e. ZAS (Echelon) versus Z80ASM (SLR). I also listened to Richard Conn's story on his building of ZCPR33, on last years Trenton Computer Festival (april '86), and now it is there! To my great surprise the author of ZCPR3.3 turened out to be .... Jay Sage! What ever happened to Richard? (are you listening Richard?) Or his code. But, and this is now perhaps not a big suprise, I completely failed in installing ZCPR3.3 (I thought it was advertised as having an even easier installment as with V3.0, which I thought was already pretty simple), because all of my 'reliable' compilers failed: ASM, MAC, RMAC, M80, Z80MR. (ASM, MAC, RMAC couldn't help it, the new code is now written in Z80 opcode, which I can perhaps agree with; what will happen to the poor old 8080 users, or did they all die?) Apart from a few trivial problems (who EVER came up with the idea of replacing brackets (yes: ()'s) with square bracket's []????), the author used a compiler where one needs now at least an 8 character- length variable name detector. We all now that M80 exports only 6! I phoned SLR, the experts there told me that M80 V3.44 exports 6 yes (because of the .REL format), but can internally use 16 character lenght!! I tried mine (V3.4 from 1980!!), and even a little test, but no way. Does anyone know of that (newer) 3.44 version, and is it true what SLR told me. Other than that, M80 would probably have done the job (apart from two extra needed .PRINTX's and having MACLIB filenames in full and uppercase). Even compilers with 7 character length variable names will fail, as a quick glance over the code learned. The end of the story you can probably guess: I dialed into Jay's machine last nigh and found an order option for the SLR compiler (and Linker, but one could live without this one). After reading the description of the compiler, I'm really impressed. Like 5-10 faster than M80, and so many more possibilities. It will be quite an improvement for assembler programming, but I keep thinking of the funny stories I read in these rebuttals last september. I am looking forward to receiving my SLR compiler from Jay, (Btw Jay, I have a Kaypro 4, DS DD) and will perhaps let you netreaders know what happened. After all, ZCPR is really a fantastic piece of software, and moreover, allows YOU to write and modify part of the operating system (&utilities), which is not possible on many machines for a price like we pay for this Let me know what your experiences are, do all of you know have these fancy new compilers, like ZAS and Z80ASM? I am just old fashioned? Afer all, at some stage we have to make use of the Z80 itself. Of course if we extrapolate this, soon the Z80 users will find themselves deserted, because ZCPR4.0 will be written for Z280 or HD64810 only. Peter Teuben Institute for Advanced Study School of Natural Sciences Princeton, NJ 08540 TEUBEN@IASSNS.BITNET or pjt@astrovax.uucp (PS: I have no regular means of up/down loading to BBS's, in particular the Z-nodes. I would appreciate if someone could distribute this) ---- 3-Jun-87 06:28:24-MDT,2261;000000000000 Mail-From: RCONN created at 3-Jun-87 06:28:14 Date: Wed, 3 Jun 87 06:28:13 MDT From: Rick Conn Subject: Re: zcpr3.3 To: phoenix!pguhatha@PRINCETON.EDU cc: info-cpm@SIMTEL20.ARPA In-Reply-To: <365@phoenix.PRINCETON.EDU> Message-ID: <12307534865.12.RCONN@SIMTEL20.ARPA> Hello, Peter, Thanks for your message on ZCPR 3.3. The basic story is that I'm not involved with Echelon wrt ZCPR any more, and I've handed over ZCPR 3.x, TERM3, DISCAT, etc to them so they can continue to support the Z System users. Jay sage and others are merrily hacking away at the Z System, building upon the ideas in my original ZCPR3, mutating it as they desire. In the meantime, I'm working on two main thrusts: Ada and a new ZCPR 4.0 (at least, that's what it is called at this time). I talked about both at the last Trenton Computer Festival and can probably make the ZCPR 4.0 information available if anyone is interested. In the Ada arena, I manage the Ada Software Repository on SIMTEL20. The introduction of Ada technology is also a big part of my main job. In the ZCPR 4.0 arena, I'm back in the original environment that spawned ZCPR 3.0. There is no time pressure, no delivery dates, and complete freedom to create. There is also no requirement to deliver at all, so I really don't know if what I am working on will materialize in the user community. At one point I was working on ZCPR 3.3, moving in the direction of my current ZCPR 4.0; the effort was quite large, leading to something larger than the original ZCPR 3.0 and TERM3 combined. The ZCPR 3.3 that Echelon is supporting is not the original ZCPR 3.3 at all, but a completely different effort headed by Jay Sage that is a fraction of the original ZCPR 3.3 effort. That original ZCPR 3.3 is now the ZCPR 4.0 I'm working on. The bottom line is that the Echelon effort is available to the users now (i.e., the ZCPR 3.3 of Jay Sage). Continue to follow it and enjoy the work of Jay and the others involved. The work I'm doing may or may not be released some day, and you can see then if you want to continue with them, move to mine, do both, or whatever. To the user community, this should be a win-win proposition. Rick Conn ------- 3-Jun-87 22:41:40-MDT,1726;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Wed, 3 Jun 87 22:41:16 MDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA13125; Wed, 3 Jun 87 21:38:31 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Jun 87 00:44:12 GMT From: phoenix!pguhatha@princeton.edu (Puragra Guhathakurta) Organization: Princeton Univ. Computing and Information Technology Subject: comp.os.cpm usage and zcpr3.3 Message-Id: <366@phoenix.PRINCETON.EDU> Sender: info-cpm-request@simtel20.arpa To: info-cpm@simtel20.arpa A few days ago I posted my suprises with ZCPR3.3 and it's required new assemblers (I guess both ZAS and Z80ASM will do), I got curious what actually happened to the old assemblers. To me this is quite a change with older versions of ZCPR, but we all know, one day the old 8080 code will be replaced by Z80, and by Z280 and HD64180... Now, I am curious how many people that read this messages actually do still use assemblers, and if so, which one. I only knew of ASM, MAC, RMAC and M80, but know we need either ZAS or Z80ASM. Also a public domain Z80MR is available, but there maybe more. I would appreciate some responses, and will summarize to the net in a couple of weeks when things slow down. It seems that I was a rather oldfashioned user, and that most of the community has changed to the more modern assemblers. Let me know. Peter Teuben Institute for Advanced Study Princeton, NJ 08540 email to either: TEUBEN@IASSNS.BITNET, pjt@astrovax.uucp or my friends account (see header) 4-Jun-87 02:41:11-MDT,2985;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Thu, 4 Jun 87 02:41:02 MDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA16484; Thu, 4 Jun 87 01:36:43 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 3 Jun 87 18:20:36 GMT From: tektronix!teklds!copper!michaelk@ucbvax.Berkeley.EDU (Michael D. Kersenbrock) Organization: Tektronix, Inc., Beaverton, OR. Subject: Re: posting information Message-Id: <1088@copper.TEK.COM> References: <8706022151.AA24523@amc.APPLIED-MICROSYSTEMS.uucp> Sender: info-cpm-request@simtel20.arpa To: info-cpm@simtel20.arpa Keywords: In article <8706022151.AA24523@amc.APPLIED-MICROSYSTEMS.uucp> jon@amc.UUCP writes: >I have just finished work on a version of UNIX make which runs on CP/M. >I am going to be releasing it as a share-ware product, and would like to >post it to the list. Do you have any problems with this? Or any suggestions >of how to go about it? There is an excellent PD non-shareware (cheaper: as in free) "make" in the SIMTEL20 archives that works rather well under CP/M 3.0, so you might want to keep your price on the low side. 8-) I have been meaning to send Keith P. my updated version that I've been using for a while but I seem to have trouble sending things to him & haven't heard from him since my last two or three mailings (this is a hint in case you're reading this Keith). My newer version isn't all that much better though...the "old" one is perfectly fine. My dancing fingers like to do the creeping-feature waltz...... The version I generated (the two above) are ones that I "strongly-ported" from the version USENET-posted by a gentleman in Australia whose name I don't recall (his name is in the bit of documentation I wrote up for the package). His version was *for* UNIX (of some flavor). One of the changes I've made is so that when "my" make is used with CCP105 (my update of CCP104), execution of the "make-proceedure" optionally will terminate upon a step-wise error (RSX's are provided in the CCP105 package to make you compiler, assembler, linker, etc cooperate). This was one of the last "features" that I debugged and got actually working. I don't think the "old version" of make will keep the "steps" out of CCP105's csh-like history mechanism, but my current version does. Anyway, if your version is for CP/M 2.2 (which my version doesn't work for), then this surely is a needed "product". If so, you might mention what file timestamping mechanism (or equivalent) you require the target system to have. I don't know about the distribution policy on the ARPA side of things, but I've seen some shareware across the USENET side (most noteably "ARC"). -- Mike Kersenbrock Tektronix Microcomputer Development Products Aloha, Oregon 4-Jun-87 10:15:13-MDT,1328;000000000000 Return-Path: <@RELAY.CS.NET:kenw%noah.arc.cdn@UBC.CSNET> Received: from RELAY.CS.NET by SIMTEL20.ARPA with TCP; Thu, 4 Jun 87 10:14:58 MDT Received: from relay2.cs.net by RELAY.CS.NET id aa10968; 4 Jun 87 11:51 EDT Received: from ubc by RELAY.CS.NET id aa07933; 4 Jun 87 11:46 EDT Received: by ubc.csnet id AA24538; Thu, 4 Jun 87 08:20:29 pdt Date: 4 Jun 87 0:19 -0800 From: Ken Wallewein To: info-cpm@SIMTEL20.ARPA MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET Message-Id: <176*kenw@noah.arc.cdn> Subject: CONIX v/xs ZCPR For about the last year I've been drooling over the ads for CONIX, the super-duper CP/M replacement. It got good reviews, and looks better than ZCPR3 in many ways. I use ZCPR2 now, but a lot of that stuff is only really useful for hard drives and multiple users (I run dual 8" DSDD floppies and a RAM disk). However, there seems to be a lot of fuss and bother over ZCPR3, but not a peep about CONIX. How come? Doesn't *anybody* use it? I would really like to see some discussion. For that matter, has anybody tried out that PD BDOS replacement I read about recently (can't remember who by)? /kenw A L B E R T A Ken Wallewein R E S E A R C H C O U N C I L 4-Jun-87 11:09:51-MDT,1849;000000000000 Return-Path: Received: from lll-lcc.ARPA by SIMTEL20.ARPA with TCP; Thu, 4 Jun 87 11:09:19 MDT Received: Thu, 4 Jun 87 10:07:52 PDT from lll-es-s05.arpa by lll-lcc.ARPA (5.51/) id AA07018; Thu, 4 Jun 87 10:07:52 PDT Return-Path: Received: by lll-es-s05.ARPA (1.1/SMI-3.0DEV3) id AA19640; Thu, 4 Jun 87 10:08:54 PDT Message-Id: <8706041708.AA19640@lll-es-s05.ARPA> Date: Thu Jun 4 10:08:51 1987 From: hanscom@lll-es-s05 (Roger Hanscom 423-0441) Subject: Re: Floating Point Routines To: Info-Cpm@SIMTEL20.ARPA Cc: hanscom@lll-es-s05 X-Orig-Date: Sun, 31 May 87 12:00:45 CET X-Orig-From: "Eberhard W. Lisse" X-Orig-Message-Id: Status: N Eberhard W. Lisse writes: >a friend of mine is looking for the following: > >Source of a BASIC-Interpreter with floating point arithmetics in >8088/Z80 or 80286 assembler > >or > >floating point arithmetic routines in same assembler languages to be >incorporated into a to be written BASIC interpreter. I don't know what is available on SIMTEL20 in this area, but a publication appeared years ago (part of the "wizard-series") with a title something like "mysteries of Radio-Shack Microsoft Basic revealed". It is a paper copy (dis-assembly??) of the Z80 assembler for Radio Shack's BASIC. As I remember it was a f.p. BASIC, although not awfully fast. Another possible source is the government clearing house for technical information (N.T.I.S.) in suburban Wash. D.C. Seems to me that they had a BASIC called LLL-BASIC that was developed at Livermore Lab. Don't know much about that one either, except that it exists, it had f.p., and was written in either 8080 or Z80 assembler. Good Luck! 4-Jun-87 12:51:44-MDT,1986;000000000000 Return-Path: Received: from LL.ARPA by SIMTEL20.ARPA with TCP; Thu, 4 Jun 87 12:51:10 MDT Date: Thu 04 Jun 1987 14:49:26 EDT From: Subject: Unauthorized ZCPR33 Files To: info-cpm@simtel20.arpa Cc: W8SDZ@SIMTEL20 Message-ID: The ZCPR33 files on SIMTEL20 at this time (June 4, 1987) are NOT the official release versions. They are beta-test versions that should NEVER have been distributed publicly. Someone, without authorization, uploaded the files to Keith Petersen's Royal Oaks system, and Keith, understandably, assumed that they were the release versions that had been announced. I have asked Keith to remove these files as soon as possible. If anyone uses these files, they do so at some risk. There were some last-minute address changes. It is, therefore, quite possible that a number of the release-version utilities and auxiliary packages will not work properly with this version of ZCPR33 (I have not determined for sure whether or not the last changes got into this version). Some of the failures will be quite subtle. I recommend that if you downloaded any of these files you destroy them. If you distributed them further, please try to track them down and have them removed as well. It will be very unfortunate if bad copies end up in wide distribution. The official release versions are currently available from many Z-Node remote access systems, including mine at 617-965-7259 (password=DDT, on entering operating system enter user ID of "NONE" for 60-minute access). As soon as I can, I will arrange for the proper distribution files to be put up on SIMTEL20. The files have to be converted from squeezed form to crunched form, and CRC values have to be tabulated. Since there is more than 500K of code, this may take a little while. I will try to get the material onto SIMTEL20 by June 6. Jay Sage 4-Jun-87 13:10:10-MDT,10086;000000000000 Return-Path: Received: from LL.ARPA by SIMTEL20.ARPA with TCP; Thu, 4 Jun 87 13:08:35 MDT Date: Thu 04 Jun 1987 14:50:29 EDT From: Subject: Some Comments on ZCPR33 and the 8-Bit World To: info-cpm@simtel20.arpa Cc: TEUBEN%IASSNS.BITNET@WISCVM.WISC.EDU Message-ID: Peter Teuben's comments about the ZCPR33 release that appeared today over the network finally got me to sit down and compose this message. These comments are in no way addressed specifically to Peter; his remarks simply provided the impetus for me to collect these thoughts in writing. Although I follow the INFO-CPM exchanges on the DDN, I do not spend much time contributing to the discussion. My work with 8-bit computers is almost entirely a personal-time activity, and I try to avoid spending time at work on it. For those of you who do not know, in real life I am an ANALOG device physicist, always trying to show that only analog devices, and not digital ones, can solve the world's really pressing signal-processing problems. Right now I am working in two areas: analog focal-plane image preprocessors, chips that use the same devices (CCDs for example) not only to capture an image but also to figure out what it means (an artificial retina, to put it in grandiose terms); and artificial analog neural network chips, integrated circuits that function in a simplified brain-like way to perform associations and to recognize patterns. First of all, I hope everyone has seen my message about the files on SIMTEL20. In brief, those files were NOT authorized versions. They were beta-test versions that were improperly sent to Keith Petersen. I do not know for sure, but they may contain code that is not up to date, code that will malfunction in subtle ways with release versions of system segments and utility programs. Second, on the matter of the assembly-language format. The release files are in a format that permits assembly with Echelon's ZAS assembler. Bear in mind that ZCPR33 is a COPYRIGHTED COMMERCIAL product. Its release for personal, noncommercial application at no cost is a privilege, not a right. Understand that Echelon is trying to stay in business so that all of us can continue to benefit from further developments. Without Echelon, I think it is quite likely that ZCPR, if not 8-bit computing in general, would come to an end. Some of you know that Echelon and I have not always been on the best of terms. It is not my love for Echelon but rather our common purpose in advancing 8-bit computing that has brought us together. One of the famous sore points between me and Echelon concerns the ZAS assembler and, among other things, its idiosyncratic use of square brackets where standard assemblers use ordinary parentheses. Nevertheless, I understand that it is not only reasonable but entirely appropriate that Echelon products, like ZCPR33, be capable of assembly using THEIR assembler. I personally use the highly professional assembly-language tools from SLR Systems and adjust for ZAS compatibility when the development is complete. Fortunately, Steve Russell (SLR) was kind enough to make his tools accept ZAS-format expressions, which greatly facilitates this process. ZAS, by the way, is currently undergoing a significant upgrade (by a different programmer), and I have good reason to believe that my objections to it will soon be corrected and that it will become an acceptable product that will function particularly nicely in a Z environment. With ZCPR33 we made a conscious decision not to be tied to the limitations of the 1970s-vintage CP/M. Six-character labels may have been reasonable in the early days of computing, but that is no longer the case. We have worked very hard to make the ZCPR33 source code extremely readable and educational. It is carefully organized and heavily commented. Using meaningful labels makes the code easier to understand and maintain (if anything, the labels are probably still too short). We have also dropped support for 8080/8085 processors and made free use of highly efficient Z80-specific opcodes. This includes not only the commonly used relative jumps but also word subtraction, direct double-register transfers, block moves and compares, and the alternate register set. What about those people with older assembly-language tools or computers with 8080 or 8085 processors? The basic answer is that the ZCPR33 COMMERCIAL PRODUCT does not support them. The market does not justify the work required to do so. For users, there are two solutions. First of all, I think it is entirely reasonable for someone to spend $69 for ZAS/ZLINK or $50 for the SLR Z80ASM or SLR180 assembler (plus $50 for SLRNK if they want a linker, too) so that they can take immediate advantage of the released code without significant effort on their own part. If they do not wish to do so, the source code is there, and they have the alternative of spending their time to make whatever conversions are required. The same comment applies to conversion to work with Intel microprocessors. Converting the code to work with M80 or ZASM (the copyrighted Cromemco assembler) is actually rather easy for those who are expert at using those assemblers. A number of my beta-testers did it quite regularly (though I wondered why they were willing to waste their time when they could be using Z80ASM with its five-times speed advantage). The files can most likely be adapted to Z80MR as well, though I don't know of anyone who has done it already. Files will undoubtedly appear in due course (from the user community) that will describe the procedures in detail or even perform them semi-automatically (using SUBMIT or ZEX scripts). Some owners of 8085-based computers may even have the necessary motivation to put in the time to develop 8080 versions of the code, as Charlie Strom did for ZCPR2. Installing ZCPR33 on a system that is currently running ZCPR30 is extremely easy (provided, of course, that you have a suitable assembler). No changes in the memory map are required; the ZCPR33 command processor is a simple drop-in replacement for ZCPR30. Highly detailed procedures, including some new techniques that take advantage of existing ZCPR3 facilities, are described in the ZCPR33 User Guide available from Echelon (while the code has been released for personal, noncommercial use, the documentation will be available only in printed form). This brings me to an important general comment. I have enjoyed working in the 8-bit world, despite the rip tide sweeping people in the direction of 'DOS' machines, because I like the values and attitudes in the community much better than those I perceived in the 16-bit world. Programmers in the 8-bit world freely shared their source code and their ideas so that the talents of the entire community, and not just those of a single programmer, could be brought to bear on a given program or problem. This is good. But there is a bad side aspect to the attitudes in the 8-bit world. Too many have come to assume that they have a RIGHT to receive everything for free -- both the programs themselves and instruction and help in their use. I recently experienced an extreme example of this when one of the users of my Z-Node kept calling me on voice with questions, for hours at a time, during the most critical period of ZCPR33 development. I finally lost patience with this person when he starting asking for help using Z80ASM, which I knew he had not paid for but had stolen. His attitude seemed to be that because of HIS GREAT INTEREST in 8-bit computing he had a right to ask for all this free consulting time. The trouble with this attitude is that without adequate financial compensation to those programmers who spend exceptional amounts of time developing programs, there will be fewer and fewer programmers developing significant new 8-bit programs. We will then all be complaining that the trouble with CP/M is that there are no new application programs available! If we refuse to spend even modest sums of money to purchase programs and if we illegally copy them, then to be sure no more will be developed. Programmers will turn to the 16-bit world. As a general rule, the software products offered by Echelon, SLR Systems, Plu*Perfect Systems, and the few other remaining producers of CP/M-compatible software (and hardware) are very reasonably priced. I stronly encourage people to support them (and have been doing so since long before I found myself on the other side of the fence as a member of the Echelon team). My case is a simple example of this. Unlike the people at SLR Systems or Echelon, who devote full time to their activities and have to support themselves on the income from them, I do programming in my spare time, largely for the fun and challenge of it. The development of ZCPR33 from my experimental ZCPR315, however, took about three and a half months of full- (spare)time work, typically from middle evening until one or two in the morning. Unless that effort realizes some 'spending' money that my whole family can enjoy, there is no way I will be able to devote that kind of energy to further developments. So much for the soap box. One final comment. Many further developments are still anticipated, not only for the 64180 and Z280 processors (the ZOS operating system) but also for the Z80. I have actually started work already on ZCPR34 (any suggestions?). The RCP package that was released with ZCPR33 is far from finished (actually, it was very little more than RCP145, the experimental version that complemented ZCPR315). If things go well with this first release, there will be many follow-on developments appearing at a rapid pace. Jay Sage June 4, 1987 5-Jun-87 00:12:38-MDT,1977;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Fri, 5 Jun 87 00:11:25 MDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA07127; Thu, 4 Jun 87 22:50:31 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 4 Jun 87 15:22:19 GMT From: tikal!sigma!bill@beaver.cs.washington.edu (WIlliam Swan) Organization: Summation Inc, Kirkland WA Subject: Re: posting information Message-Id: <1235@sigma.UUCP> References: <8706022151.AA24523@amc.APPLIED-MICROSYSTEMS.uucp>, <1088@copper.TEK.COM> Sender: info-cpm-request@simtel20.arpa To: info-cpm@simtel20.arpa In <1088@copper.TEK.COM> michaelk@copper.UUCP (Michael D. Kersenbrock) writes: >>I have just finished work on a version of UNIX make which runs on CP/M. >>I am going to be releasing it as a share-ware product, and would like to >>post it to the list. Do you have any problems with this? Or any suggestions >>of how to go about it? >There is an excellent PD non-shareware (cheaper: as in free) "make" in the >SIMTEL20 archives that works rather well under CP/M 3.0, so you might >want to keep your price on the low side. 8-) >[...] >Anyway, if your version is for CP/M 2.2 (which my version doesn't work >for), then this surely is a needed "product". If so, you might mention >what file timestamping mechanism (or equivalent) you require the target >system to have. Michael, I don't want to diminish your efforts, but Jon's make runs on vanilla CP/M 2.2, which some (many? I don't know) of us are stuck with. I might like to get going with 3.0, to use some of its advantages but my system doesn't bankswitch, and I don't know where to even get the 3.0 manuals (which I would like to have) much less the software. -- William Swan {ihnp4,decvax,allegra,...}!uw-beaver!tikal!sigma!bill 5-Jun-87 17:56:23-MDT,1279;000000000000 Mail-From: KPETERSEN created at 5-Jun-87 17:56:08 Date: 4 Jun 87 0:34 -0800 Message-ID: Sender: Ken Wallewein From: Ken Wallewein To: info-cpm-request@SIMTEL20.ARPA Subject: zcpr3.3 ReSent-From: KPETERSEN@SIMTEL20.ARPA ReSent-To: Info-Cpm at SIMTEL20.ARPA ReSent-Date: Fri 5 Jun 1987 17:56-MDT I run CPM for two or three reasons: it's cheap; it has a history which makes it interesting; there's a large and public-spirited user community; there's lots of PD software around. I guess that's more than 3. Anyway, none of those things jive very well with the way Z-system appears to be going, if I have to buy their assembler to use it. When I can afford to buy it, I don't have time to use it enough to justify it, and vice versa (huh?). Besides, I've heard that ZCPR3 chews up too much TPA for what it gives people who don't run hard drives. As far as hardware goes, I run and S-100 bus system. Anybody know how I can upgrade that to a super-Z80 without spending hundreds of bucks or hundreds of hours? I know, there are lots of different processors for S100. Did you ever price one? Enough flame, I guess. /kenw 6-Jun-87 01:09:13-MDT,4715;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sat, 6 Jun 87 01:08:49 MDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA08115; Fri, 5 Jun 87 23:38:27 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Jun 87 03:17:18 GMT From: mnetor!utzoo!utgpu!water!watmath!watdragon!mdapoz@seismo.css.gov Organization: U. of Waterloo, Ontario Subject: Re: zcpr3.3 Message-Id: <2884@watdragon.UUCP> References: <365@phoenix.PRINCETON.EDU>, <12307534865.12.RCONN@SIMTEL20.ARPA> Sender: info-cpm-request@simtel20.arpa To: info-cpm@simtel20.arpa I just finished getting zcpr3.3 to assemble with M80 version 3.44 (dated Dec 9, 1981). The following is a summary of the changes that are needed to get the CCP portion to assemble (I still haven't recieved the RCP & FCP portions from SIMTEL so I don't know what changes need to be made to those files). 1. In all files the square brackets "[" & "]" need to be changed to "(" & ")" respectively on all conditional assembly statements (ie if's). DON'T do a global change with a text editor since some square brackets don't need to be changed! in the file ZCPR33.Z80: 2. The maclib command must be converted to upper case along with it's arguments 3. The commands .Z80 and ASEG should be added. in the file Z33HDR.LIB: 4. The extmpath, extmpathadr and whldir equate statements should have the EQU changed to a DEFL (this should be changed anyways, I think). in the file Z33MAC.LIB 5. M80 can only handle 6 chars for a macro argument (even in version 3.44) so the 'command' macro needs to be changed. Following is an updated version: ; Command table entry definition macro ; Macro to form an entry for one command in the table. The first parameter is ; the name to be used for the command (no quotes); the second parameter is the ; flag that indicates whether or not the command is to be enabled; the third ; parameter is the wheel control flag; and the last parameter is the jump ; address to the code that carries out the command. The command names are ; automatically padded out to the correct length (they will be truncated and ; an error message will result if a command name is too long). The characters ; in the command name are automatically converted to upper case. command macro cmdnam,enaflg,whlflg,addr if enaflg ;; Generate command only if enabled whlmask defl whlflg ;; Initialize variables count defl cmdsize ;; Initialize to size of each command name irpc char,cmdnam ;; Repeat over letters in command name count defl count - 1 ;; Count down characters in name if ( count lt cmdsize ) ;; If character is lower case, convert to upper case if ( '&char' ge 'a' ) and ( '&char' le 'z' ) if whlmask defb ( '&char' and 5fh ) + 80h else ;;not whlmask defb ( '&char' and 5fh ) endif ;;whlmask else ;;not lower case if whlmask defb '&char' + 80h ;; If controlled by wheel, set high bit else ;;not whlmask defb '&char' ;; If not restricted, leave high bit clear endif ;;whlmask endif ;;lower case endif ;;( count lt cmdsize ) whlmask defl false ;; Turn off high-bit setting after first char endm ;irpc ;; Pad command name with blanks if ( count gt cmdsize ) ;; If we underflowed *** Command name "&cmdname" is too long / truncated *** else rept count defb ' ' endm endif ;( count gt cmdsize ) dw addr ;; Dispatch address for command endif ;enable endm ;command After successful assembly, the resultant .REL file was converted to a HEX file using RELHEX.COM and then merged with the BIOS in the standard manner. Even though M80 only outputs 6 char labels in the REL file, it still keeps larger labels during assembly, so the use of large labels in zcpr3.3 doesn't affect M80 in the least. Hope this helps in getting people stared with assembling zcpr3.3 with M80. A side note: zcpr3.3 came up the first time I tried booting it! It did take me 2 hours to figure out all the changes that needed to be made to the source files for M80, but after that first successful assemble, it booted with no problems. Regarding zcpr 4.0, I'd love to hear what you're doing with it Richard, how about posting a summary of what's going on with it, either that, or send it directly to me. -Mark "If a hardware problem causes system software to crash, the customer engineer will blame the system programmer." Mark Dapoz mdapoz@watdragon.UUCP 6-Jun-87 01:12:23-MDT,1413;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sat, 6 Jun 87 01:11:10 MDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA05686; Fri, 5 Jun 87 20:41:04 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Jun 87 15:41:48 GMT From: tikal!sigma!bill@beaver.cs.washington.edu (WIlliam Swan) Organization: Summation Inc, Kirkland WA Subject: Re: CONIX v/xs ZCPR Message-Id: <1239@sigma.UUCP> References: <176*kenw@noah.arc.cdn> Sender: info-cpm-request@simtel20.arpa To: info-cpm@simtel20.arpa In article <176*kenw@noah.arc.cdn> kenw@noah.arc.CDN (Ken Wallewein) writes: >[...]However, there seems to be a lot of fuss and bother over ZCPR3, but not a >peep about CONIX. How come? Doesn't *anybody* use it? I would really like to >see some discussion. > > For that matter, has anybody tried out that PD BDOS replacement I read >about recently (can't remember who by)? Ken, I don't think anybody on the net is running CONIX. I posted a request for info a year or so ago.. nothing. I've seen one or two other requests, same result. Ditto for the BDOS replacement (it's on my list to do - but way down it). -- William Swan {ihnp4,decvax,allegra,...}!uw-beaver!tikal!sigma!bill 6-Jun-87 01:14:54-MDT,2785;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sat, 6 Jun 87 01:14:42 MDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA04045; Fri, 5 Jun 87 18:45:17 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Jun 87 16:39:46 GMT From: hao!gatech!hubcap!ncrcae!ncr-sd!crash!mwilson@husc6.harvard.edu (Marc Wilson) Organization: Grossmont College, El Cajon, Ca. Subject: Re: CONIX v/xs ZCPR Message-Id: <1177@crash.CTS.COM> References: <176*kenw@noah.arc.cdn> Sender: info-cpm-request@simtel20.arpa To: info-cpm@simtel20.arpa In article <176*kenw@noah.arc.cdn> kenw@noah.arc.CDN (Ken Wallewein) writes: > > For about the last year I've been drooling over the ads for CONIX, the >super-duper CP/M replacement. It got good reviews, and looks better than ZCPR3 >in many ways. It doesn't look better once you put both of them side by side and compare features. > > However, there seems to be a lot of fuss and bother over ZCPR3, but not a >peep about CONIX. How come? Doesn't *anybody* use it? I would really like to >see some discussion. > You haven't seen any discussion of ConIX for the simple fact that it isn't worth much. It adds a whole *bunch* of resident commands, but that's about it. It allows I/O re-direction, but it will only work with its own programs. ZCPR3 is much better. > For that matter, has anybody tried out that PD BDOS replacement I read >about recently (can't remember who by)? >/kenw The BDOS replacement you are thinking of ( I think ) is SUPRBDOS. It came originally from the Netherlands... then it was known as P2DOS. Very nice bit of programming. Much like ZRDOS... detects changed disks and re-loggs them, fixes the delete key, increases the max. file size to 8 Gbytes, etc. Also allows time/date stamping, if you have a clock. Email me if you want more info... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Marc Wilson ( mwilson@crash.CTS.COM ) ARPA: ...!crash!mwilson@nosc ...!crash!pnet01!pro-sol!mwilson@nosc UUCP: [ akgua | hp-sdd!hplabs | sdcsvax | nosc ]!crash!mwilson ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Marc Wilson ( mwilson@crash.CTS.COM ) ARPA: ...!crash!mwilson@nosc ...!crash!pnet01!pro-sol!mwilson@nosc UUCP: [ akgua | hp-sdd!hplabs | sdcsvax | nosc ]!crash!mwilson ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 6-Jun-87 02:08:14-MDT,2446;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sat, 6 Jun 87 02:08:03 MDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA09706; Sat, 6 Jun 87 00:43:01 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Jun 87 01:11:59 GMT From: poisson.usc.edu!mlinar@OBERON.USC.EDU (Mitch Mlinar) Organization: University of Southern California, Los Angeles Subject: Re: CONIX v/xs ZCPR Message-Id: <2539@poisson.usc.edu> References: <176*kenw@noah.arc.cdn> Sender: info-cpm-request@simtel20.arpa To: info-cpm@simtel20.arpa In article <176*kenw@noah.arc.cdn> kenw@noah.arc.CDN (Ken Wallewein) writes: > > For about the last year I've been drooling over the ads for CONIX, the >super-duper CP/M replacement. It got good reviews, and looks better than ZCPR3 >in many ways. I use ZCPR2 now, but a lot of that stuff is only really useful >for hard drives and multiple users (I run dual 8" DSDD floppies and a RAM >disk). > > However, there seems to be a lot of fuss and bother over ZCPR3, but not a >peep about CONIX. How come? Doesn't *anybody* use it? I would really like to >see some discussion. > > For that matter, has anybody tried out that PD BDOS replacement I read >about recently (can't remember who by)? >/kenw > A L B E R T A >Ken Wallewein R E S E A R C H > C O U N C I L Ken, I am not even sure CONIX is still trying to sell it. They released a big portion as freeware to the public domain almost a year ago due to lack of response, hoping to generate a set of users who would pay for the full upgrade. These files are located on Blaise Pascal System (NY) at (718) 604-1930. I do not know if they are still there. I never fully implemented the CONIX stuff. After a brief experimental period, I abandoned the project. It seems very usable, but suffers the same memory constraints and disk problems as ZCPR. Considering ZCPR is well supported, a choice between the two would favor ZCPR. However, I am a developer (in my all too short spare time) who can't afford a smaller TPA. So, I remained with my current OS: QP/M with Qplus extensions. Check out the NY board for the files and good luck. -Mitch Signature: none Disclaimer: none Ignorance: plenty 6-Jun-87 12:07:47-MDT,2845;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sat, 6 Jun 87 12:07:30 MDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA16798; Sat, 6 Jun 87 10:40:16 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 6 Jun 87 16:53:28 GMT From: barry@AMES-AURORA.ARPA (Kenn Barry) Organization: NASA Ames Research Center, Mt. View, Ca. Subject: Re: CONIX v/xs ZCPR Message-Id: <693@aurora.UUCP> References: <176*kenw@noah.arc.cdn> Sender: info-cpm-request@simtel20.arpa To: info-cpm@simtel20.arpa In article <176*kenw@noah.arc.cdn>, kenw@noah.arc.CDN (Ken Wallewein) writes: > For about the last year I've been drooling over the ads for CONIX, the >super-duper CP/M replacement. It got good reviews, and looks better than ZCPR3 >in many ways. I use ZCPR2 now, but a lot of that stuff is only really useful >for hard drives and multiple users (I run dual 8" DSDD floppies and a RAM >disk). > > However, there seems to be a lot of fuss and bother over ZCPR3, but not a >peep about CONIX. How come? Doesn't *anybody* use it? I would really like to >see some discussion. Since no one else has mentioned it, I'd like to point out that ZCPR and CONIX can be used *together*; they get along fine on my system. I run ZCPR2 on an Apple - CP/M system with Sider hard disk (never managed to get ZCPR3.X to work - Softcard CP/M is strange, and I'm no expert in the Z80 world), and have the PD CONIX stuff from SIMTEL. It needs no installation in the system, it's just run like an application, and it gets along just dandy with ZCPR2. I like both enhancements, but generally don't bother running CONIX since: 1) ZCPR eliminates all the worst limitations of vanilla CP/M; 2) CONIX has many, many features, and somewhat cryptic commands, making it less valuable for my occasional use - I can never remember the commands :-(; I'm mainly using a 68000 system these days (Amiga), and thus forgetting what little I did know of CP/M. Nonetheless, CONIX seems, from my occasional use, to be a good product, especially since it can be run when needed, and removed when in the way, without altering one's system software, or needing to choose between it and the Z-system. If it's as compatable with ZCPR3.0 and 3.3 as it is with ZCPR2, the choice is obvious: get both. - From the Crow's Nest - Kenn Barry NASA-Ames Research Center Moffett Field, CA ----------------------------------------------------------------------------- ELECTRIC AVENUE: {hplabs,seismo,dual,ihnp4}!ames!borealis!barry 6-Jun-87 12:26:34-MDT,1500;000000000000 Mail-From: KPETERSEN created at 6-Jun-87 12:26:17 Date: Friday, 5 June 1987 11:55-MDT Message-ID: Sender: From: To: W8SDZ@SIMTEL20.ARPA Subject: ZCPR 3.3 official release files uploaded to SIMTEL20 ReSent-From: KPETERSEN@SIMTEL20.ARPA ReSent-To: Info-Cpm at SIMTEL20.ARPA ReSent-Date: Sat 6 Jun 1987 12:26-MDT The following official release files of ZCPR 3.3 are now available on SIMTEL20: Filename Type Bytes CRC Directory PD: SHOW11.LBR.1 BINARY 41600 447BH Z33ERR07.LBR.2 BINARY 10880 D711H Z33FCP10.LBR.3 BINARY 41600 92BDH Z33RCP01.LBR.1 BINARY 49280 C06CH ZCPR33.LBR.3 BINARY 83968 F32CH ZCPR33.LBR is the command processor. Z33FCP10.LBR is version 1.0 of the new flow command package -- fairly mature. Z33RCP01.LBR is version 0.1 of the new resident command package -- not very mature, hence the low version number. SHOW11.LBR displays information about one's operating system configuration. This version has greatly improved displays of the information included in the earlier version plus much new information about ZCPR33 features. Z33ERR07.LBR is an early version of an advanced error handler that reports to the user what caused the error (in Z30 there was basically only one kind of error -- command not found). Z33 traps many other kinds of errors, such as invalid numerical format, illegal directory, bad password, etc. 6-Jun-87 14:37:59-MDT,937;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sat, 6 Jun 87 14:37:42 MDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA18545; Sat, 6 Jun 87 13:36:56 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 5 Jun 87 19:03:17 GMT From: ihnp4!alberta!calgary!arcsun!kenw@ucbvax.Berkeley.EDU (Ken Wallewein) Organization: Alberta Research Council, Calgary, Ab. Subject: Re: comp.os.cpm usage and zcpr3.3 Message-Id: <251@arcsun.UUCP> References: <366@phoenix.PRINCETON.EDU> Sender: info-cpm-request@simtel20.arpa To: info-cpm@simtel20.arpa I use M80, mostly. Not sure what version, but it's old. Can't afford to spend a lot on a hobby. All these commercial users are ruining it for us hobbyists, I think sometimes:-). /kenw 6-Jun-87 15:10:13-MDT,1155;000000000000 Return-Path: Received: from rand-unix.arpa by SIMTEL20.ARPA with TCP; Sat, 6 Jun 87 15:09:59 MDT Received: by rand-unix.arpa; Sat, 6 Jun 87 13:49:24 PDT Received: from newton.arpa by rcc.arpa; Sat, 6 Jun 87 13:50:08 PDT From: Bridger Mitchell Received: from localhost by newton.arpa; Sat, 6 Jun 87 13:50:28 PDT Message-Id: <8706062050.AA05801@newton.arpa> To: tikal!sigma!bill@beaver.cs.washington.edu (WIlliam Swan) Cc: info-cpm@simtel20.arpa, bridger%rcc@rand-unix.ARPA Subject: 'make' utilities for cp/m 2.2 Date: Sat, 06 Jun 87 13:50:25 PDT Another unix-style 'make' can be found on the DateStamper Toolkit disk. It was developed by Neal Maron for DateStamper-equipped systems from a public-domain MSDOS version . DateStamper runs on 8080 and z80 cp/m 2.2 systems and several emulators - including zrdos and some apple systems. It supports automatic file date and time-stamping. (If no real-time clock is available, the 'time' is a sequential number on the given date.) DateStamper and the toolkit are available from Plu*Perfect Systems. --bridger mitchell 6-Jun-87 15:59:38-MDT,691;000000000000 Mail-From: KPETERSEN created at 6-Jun-87 15:59:18 Date: Sat, 6 Jun 1987 15:59 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@SIMTEL20.ARPA Subject: CONIX v/xs ZCPR Conix is available from SIMTEL20 as: Filename Type Bytes CRC Directory PD: CONIX.LBR.1 BINARY 212096 71B7H It's also available from my RCP/M and GEnie's CP/M RoundTable. --Keith Petersen Arpa: W8SDZ@SIMTEL20.ARPA Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz GEnie: W8SDZ RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST) 6-Jun-87 16:07:48-MDT,838;000000000000 Mail-From: KPETERSEN created at 6-Jun-87 16:07:39 Date: Sat, 6 Jun 1987 16:07 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@SIMTEL20.ARPA Subject: Public domain BDOS replacements There are several public domain BDOS replacements available: Filename Type Bytes CRC Directory PD: DOSP25.LBR.1 BINARY 105344 CC77H (really DOS+25) P2DOS21.ARK.1 BINARY 74624 A8C6H SUPRBDOS.ARK.1 BINARY 61696 8386H These are available from SIMTEL20, my RCP/M, and GEnie's CP/M RoundTable. --Keith Petersen Arpa: W8SDZ@SIMTEL20.ARPA Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz GEnie: W8SDZ RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST) 7-Jun-87 07:30:05-MDT,2640;000000000000 Return-Path: Received: from decwrl.dec.com by SIMTEL20.ARPA with TCP; Sun, 7 Jun 87 07:28:26 MDT Received: from rhea.dec.com by decwrl.dec.com (5.54.3/4.7.34) id AA16641; Fri, 5 Jun 87 23:32:29 PDT Message-Id: <8706060632.AA16641@decwrl.dec.com> Date: 06-Jun-1987 0132 From: w_smith%wookie.DEC@decwrl.dec.com (Willie Smith, LTN Components Eng.) To: info-cpm@simtel20.ARPA Subject: Z-80 assembly UUDECODE is (sort of) done. I just (moments ago) finished the Z-80 assembly version of UUDECODE. Thanks to all those who sent me mail, I was unable to reply due to problems finding paths back to you. A few questions still remain however: 1) What on earth is the 'mode' number? That's the number that shows up between "begin" and the filename on the header line of a UUENCODEd file. I'm just ignoring it, is that safe? 2) The Eunichs online 'manual' claims that "the body is terminated by a line with a count of zero. This line consists of one ASCII space." However, the UUENCODE I got from SIMTEL20 does not conform to this, but rather sticks a "`" (60H) into the file, which being an out of band character, I guess is supposed to signal something. Which is right? I'm currently calling it an error and closing the file properly (which works), but this makes me nervous.... 3) The online 'manual' says that each line can be up to 62 characters long, including the trailing newline. What is meant by 'newline'? Is it CR, or LF, or both, or what? 4) Is there a real honest-to-gloz protocol definition out there somewhere that someone could send me? Please don't tell me to RTFM, the nearest Eunichs machine is miles away, and I can only talk to it thru our network. 5) I find that my program tends to stick on a final sector full of NULL bytes. This causes strange things to happen with CRC checking. How can I get the total byte count of the output file by looking at the UUENCODEd file? I suspect that this may go away when I figure out what the 'right' way of terminating the file is. Teaser: Once I get all this info together, I can write the encoder and submit them both to SIMTEL20. The decoder seems to run about 7 times as fast as the PASCAL version that's floating around [your milage may vary, I have a hard disk cache...]. The size of the decoder executable is 3.125 K bytes, less than one third the size of the PASCAL version. Anyone want to be a Beta test site? Willie Smith w_smith@wookie.dec.com w_smith%wookie.dec.com@decwrl.dec.com {usenet backbone}!decwrl!wookie.dec.com!w_smith 7-Jun-87 10:08:05-MDT,11360;000000000000 Mail-From: KPETERSEN created at 7-Jun-87 10:06:37 Date: Sun, 7 Jun 1987 10:06 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@SIMTEL20.ARPA Subject: New CP/M files uploaded to SIMTEL20 during April and May The following is a complete list of CP/M-oriented files uploaded to SIMTEL20 during the months of April and May, 1987. The numbers following the filenames are the file size in bytes followed by the file format. (7) means ASCII, (8) means binary. For a complete list of all CP/M files, see: PD:CPM.CRCLST - Complete list with CRC values PD:FILES.DIR - Abbreviated list with only directory and file names PD:FILES.IDX - Similar to below, no descriptions, comma delimited There is currently no complete listing of all files with descriptions. That is in the process of being created and will be announced when available. In the meantime, see PD:GENIECPM.MZY which is a complete listing of all CP/M, files on GEnie, each with a one-line description. Since SIMTEL20 and GEnie have many of the same files, this will be a very useful listing. It is updated monthly. Note: to save space in the following listing, the device name PD: which normally appears ahead of the directory name has been omitted. APGRAF.LBR 8832(8) Pascal Grafx for Softcard and AEng APLVIDEX.ARK 7552(8) Apple ][ w/Videx screen speedup PCPI-RTC.LBR 23040(8) RTC for Applicard using CTC PCPIPM11.ZZ0 3712(8) Applicard/Poor Man's Network driver PCPISSCX.LBR 17536(8) Applicard/SuperSer/MEX experiment SSCDRVR.AQM 5632(8) Apple SSC interrupt driver WSPATCH.LBR 21760(8) Hints on patching WordStar for Apple ZORKFACT.INF 896(7) ZORK STORY utility info DELBR11A.BUG 1148(7) Bug report - DELBR program FASTNULU.LBR 14720(8) Update to library maintenance utility NULU.PZT 768(8) Patch to speed up NULU start up UNARC16.ARK 38656(8) ARK/ARC file extraction utility UNARC16S.ARK 68096(8) Source code of UNARC version 1.6 PAGE0.LBR 1792(8) Memory dump of page 0 in hex ASTRMENU.LBR 44800(8) Astronomy calculations in MBASIC QBBS4-A.LBR 112000(8) Compiled MBASIC Bulletin Board - A QBBS4-B.LBR 88576(8) Compiled MBASIC Bulletin Board - B RCPM0687.LZT 36224(8) Remote CP/M system phone list, June BGIIDEM3.LBR 142720(8) Demo version of super OS enhancement BGQUICK.LBR 2432(8) Ease the loading of BackGrounder ii KUGEL.DZC 9088(8) Review of BackGrounder ii BW2-COMM.LBR 165504(8) Communications set up for Bondwell 2 BW2INFO.TZT 1024(8) Port/pin info for Bondwell 2 FATCATSB.LBR 40192(8) File cataloging for the SB180 CNKYOS20.LBR 30208(8) New BIOS for Columbia M64 "Shoebox" DEMCOMAL.LBR 53248(8) Comal-80/Z80 Rev 2.10 demo HIST197.LBR 45952(8) Recall last 9 CP/M command lines VERIFY.LBR 2560(8) Find bad sectors for CP/M Plus AXCAL87.LBR 58368(8) Monthly appointment calendar LEDGERS.LBR 71296(8) dBASE menu-driven general ledger sys DBASEBG.LBR 24704(8) .HLP files for DBase DBCLOCK.LBR 2176(8) DateStamper driver for dBaseII DOZ.ARK 9344(8) dBASEII menu command file; good FAMILY.LBR 28032(8) Church Membership Management system DDTPORT.LBR 39552(8) Screen-oriented I/O port debugger BAK11.LBR 2688(8) Erases BAK files from disk DL.LBR 1536(8) Unix-like replacement for CP/M's ERA SD121.LBR 69888(8) Super Sorted Directory utility WIPE12.LBR 4480(8) Erases work files from disk drive Z80DIS22.LBR 85248(8) Screen-oriented Z80 Disassembler BD04.LBR 11520(8) Find bad disk sectors and files FRENCH.LBR 30592(8) Learn French with flash cards PPIP15.LBR 66048(8) File copy with DateStamper support APRBEST.LZT 23552(8) Best of public domain software - Apr GENIECPM.MZY 94080(8) List of files in GEnie CP/M Libraries ROYALOAK.DZR 19840(8) List of RCP/M RoyalOak directories CRCKK33.LBR 41216(8) Calculates 16-bit CRC of a file INVEST.LBR 107392(8) Investment calculations in MBASIC MONYFUND.LBR 18560(8) CalcStar Portfolio Review LUCKY11.LBR 28928(8) Lottery number generator/checker LUNCH.TZT 2048(8) A look at CP/M versus MSDOS RESPONSE.FZG 5888(8) CRUNCH author responds to FOG STANDARD.FZG 5632(8) FOG standards for file submissions Z280-GNE.IQF 3968(8) Run CP/M twice as fast as IBM-AT ZORKFACT.INF 896(7) ZORK STORY utility info CANADA-G.NIE 6009(7) How Canadians can join GEnie GT-RECTS.LBR 20736(8) Drawing demo for the GT180 HFPROP.BZS 6656(8) HF propagation program UNIGRID2.BZS 6912(8) Update to N6NB's gridlocator prog. VHFPROP.BZS 11392(8) VHF/UHF propagation program IMP-OVL.CZS 2304(8) IMP Overlay customization notes IMP-OVL.LZT 3200(8) List of IMP overlays, May 30, 1987 IMP244.PZT 2560(8) Three patches to IMP 244 JUN87.MZG 22400(8) June $R/O (ReadOnly) news magazine KP-VDUMP.LBR 1024(8) Screen dump for Graphic-type Kaypro KPENG13.LBR 15616(8) Disk analysis program MAY87.MQG 31744(8) The $R/O (ReadOnly) News Magazine MAY87.MZG 24960(8) The (ReadOnly) News Magazine RAMTOOLS.LBR 24576(8) RAM resident utility for Kaypro 4'84 EDFONT.LBR 25216(8) Full screen editor to create fonts EPUP.LBR 18048(8) Send control codes to Epson FX-80 GEMPRINT.LBR 10752(8) Sets up the Gemini 10x printer LBLMKR4.LBR 14080(8) Prints mailing lists on labels PDSW.LBR 10752(8) Print text on print sideways SEND.LBR 6400(8) Sends string to LST: device MXH-AP54.AZM 11776(8) MEX overlay Applicard/SuperSerial MXH-AP55.AZM 13184(8) MEX overly for Applicard w/Ring Buffer MXH-KP53.AZM 13696(8) MEX Overlay - Kaypro computers MXO-HU11.AZM 12928(8) MEX overlay - HZ-100/USR S-100 HBAUD11.LBR 11520(8) Sets baud rates for Hitachi HD64180 MEGALINK.DZC 7936(8) Info on MegaLink Protocol PCP-0587.LZT 7680(8) List of RCP/M systems with PCP PCPIMP03.LBR 28032(8) PC Pursuit auto-dial program PROTOCOL.DZC 10496(8) Info on modem protocols ALLQ.MZD 1024(8) Finds solutions of 8 queens problem CASE.LBR 27648(8) Modula-2 programming tool DICETEST.MZD 2048(8) Dice rolling test in Modula-2 PROCON.FZX 896(8) Producer/Consumer Test Module PROCON.MZD 1024(8) Producer/Consumer Test Module SHELLIF.MZD 1920(8) ZCPR3 MOD for IF/ELSE in a shell XFRTOOL.BUG 297(7) Problem with XFRTOOL PMO-SB10.ZZ0 3456(8) Poor Man's Network driver - SB180 QSOLVE11.LBR 29056(8) A spread sheet for CP/M. UNARC.COM-Z80 4736(8) ARK/ARC file extraction utility UNARC.HEX-Z80 11412(7) ARK/ARC file extraction utility UNARCA.COM-8080 5760(8) ARK/ARC file extraction utility UNARCA.HEX-8080 14030(7) ARK/ARC file extraction utility CHGDISK.FZX 2176(8) Fix to Advent Ramdisk configurer CHGDSK11.LBR 22912(8) Change Advent Ramdisk parameters XOUT.LBR 896(8) Allows removal of XtraKey CELLAUTO.LBR 11264(8) Plot Cellular Automata CHOP18.LBR 14976(8) Chops large text files for editing CHOP18A.LBR 17664(8) Copies large files to smaller ones EXTEND11.LBR 6400(8) Enhanced append-string utility. I-21.LBR 9728(8) Small bi-directional text display ROFF4161.LBR 48512(8) Powerful customizable text formatter VDE251.LBR 54016(8) Full screen text editor/processor WRITE.WS4 691(7) Writein form WordStar 4.0 for CP/M WSWSHLST.0Z1 9472(8) Wishlist for WordStar 4.0 EDXE.LBR 19840(8) EDFILE modified for the Xerox 820 Z8E13.LBR 165248(8) Screen-oriented Z80 debugger ARUNZ09D.LBR 14080(8) ZCPR 3.3 extended command processor HSH33PAT.LBR 9856(8) Patch to HSH15 for ZCPR 3.3 SAVE04.LBR 11008(8) Transient SAVE for ZCPR 3.3 SLTRAP.LBR 6784(8) Trap console/printer output to file SUB33.LBR 15488(8) A submit processor for ZCPR3.3 XSUBZ.LBR 9600(8) ZCPR 3.3 Extended submit processor Z33ERR07.LBR 14464(8) Latest Z33 error handler Z33FCP10.LBR 41088(8) New FCP for ZCPR 3.3 Z33LIB.LBR 6656(8) Subroutine libraries for ZCPR 3.3 Z33UPD.DZC 7936(8) News about ZCPR3.3 Z33UTIL.LBR 27136(8) ZCPR3.3 Error Handlers ZCPR33.LBR 78976(8) ZCPR 3.3 command processor ARUNZ09B.LBR 18048(8) Creates command line from ALIAS CMD CORREC10.LBR 17920(8) Use CORRECT-IT with user areas LX14.LBR 12416(8) ZCPR3 Library eXecute tool M24.LBR 17280(8) Displays memory in HEX and ASCII RENAME31.LBR 15616(8) Rename files in ZCPR33 environment T3M-ERR.MZG 512(8) T3MASTER/T3SERVER error codes T3M-HI2.ZZ0 5120(8) Term3 overlay for SB180/HD64180 Z-NEWS.7Z3 11904(8) ZCPR3/SYSLIB/ZRDOS Newsletter #703 Z-NEWS.7Z4 12544(8) ZCPR3/SYSLIB/ZRDOS Newsletter #704 Z-NEWS.7Z5 12800(8) ZCPR3/SYSLIB/ZRDOS Newsletter #705 Z-NEWS.7Z6 10240(8) ZCPR3/SYSLIB/ZRDOS Newsletter #706 ZBOXWYSE.LBR 4352(8) Graphics for Wyse 50 Terminal ZNODES44.LZT 3456(8) Znode phone list -- April 4, 1987 ZPATCH11.LBR 53504(8) Screen-oriented ZCPR3 file patcher These files are also available from my RCP/M and GEnie's CP/M RoundTable. --Keith Petersen Arpa: W8SDZ@SIMTEL20.ARPA Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz GEnie: W8SDZ RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST) 7-Jun-87 16:08:08-MDT,2155;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Sun, 7 Jun 87 16:07:46 MDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA04592; Sun, 7 Jun 87 14:38:13 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Jun 87 19:10:12 GMT From: ecsvax!tcamp@mcnc.org (Ted A. Campbell) Organization: UNC Educational Computing Service Subject: Kaypro Robie For Sale Message-Id: <3354@ecsvax.UUCP> Sender: info-cpm-request@simtel20.arpa To: info-cpm@simtel20.arpa <<<<<<<<<<<<<<<<< KAYPRO ROBIE SYSTEM FOR SALE >>>>>>>>>>>>>>>>>>>>>> Hardware: Kaypro Robie, Z80 cpu 2 2.6 meg (that's right!) removable floppy drives internal clock/calendar Kaypro '84 series graphics internal 300-baud modem, auto-dial Hardware is less than 2 years old, very good condi- tion, completely serviced in January of this year Software: CP/M 2.2 operating system Wordstar 3.3 word-processing The Word Plus spell checker dBase II, 2.43 relational database management with ZIP, dGen, dSort utilities CalcStar electronic spreadsheet Microplan electronic spreadsheet MITE telecommunications MBASIC interpreted BASIC language CBASIC pseudo-compiled BASIC SBASIC fully compiled BASIC System includes all packaging, tutorial and reference manuals, and diskettes. The software is integrated by a MASMENU program. Price: $ 900.00 Contact: Ted A. Campbell email: tcamp@ecsvax home: 919-493-6523 work: 919-684-6365 8-Jun-87 15:59:45-MDT,1841;000000000000 Return-Path: Received: from LL.ARPA by SIMTEL20.ARPA with TCP; Mon, 8 Jun 87 15:54:55 MDT Date: Mon 08 Jun 1987 16:14:37 EDT From: Subject: 'Commercial Users' vs 'Hobbyists' To: info-cpm@simtel20.arpa Message-ID: The following message that just went over the network is a perfect example of what I was talking about in my earlier message (no, I did not put this out as a plant). >> I use M80, mostly. Not sure what version, but it's old. Can't afford to >> spend a lot on a hobby. All these commercial users are ruining it for us >> hobbyists, I think sometimes:-). This user apparently thinks that he has a right to expect all of US to put in lots of extra time so that HE does not have to do any work to make it possible for him to use his antiquated assembler to take free advantage of our code. If we don't, then we 'commercial users' are ruining things for 'us hobbyists.' Just as an aside, I wonder if he ever PAID for that M80 assembler -- it was not public domain after all, but many people just stole copies. If I remember correctly it cost well over $100 back in the days when a dollar was worth a lot more than it is today. As I said in my earlier message, I don't think that $50 (maybe $25 in M80-era dollars?) for a super assembler is much to expect someone to spend to gain access to the fruits of our work. Though I, too, do computing as a hobby, I certainly would not dream of wasting my limited hobby time using, today, an assembler like M80, when I can have a good one for between $50 and $100. If someone really cannot afford that amount, then let them contribute the time to convert the code. So long as the source code is there, I don't see how anyone can justify a claim that things are being ruined for hobbyists. 8-Jun-87 16:08:46-MDT,1841;000000000000 Return-Path: Received: from LL.ARPA by SIMTEL20.ARPA with TCP; Mon, 8 Jun 87 16:06:40 MDT Date: Mon 08 Jun 1987 16:14:37 EDT From: Subject: 'Commercial Users' vs 'Hobbyists' To: info-cpm@simtel20.arpa Message-ID: The following message that just went over the network is a perfect example of what I was talking about in my earlier message (no, I did not put this out as a plant). >> I use M80, mostly. Not sure what version, but it's old. Can't afford to >> spend a lot on a hobby. All these commercial users are ruining it for us >> hobbyists, I think sometimes:-). This user apparently thinks that he has a right to expect all of US to put in lots of extra time so that HE does not have to do any work to make it possible for him to use his antiquated assembler to take free advantage of our code. If we don't, then we 'commercial users' are ruining things for 'us hobbyists.' Just as an aside, I wonder if he ever PAID for that M80 assembler -- it was not public domain after all, but many people just stole copies. If I remember correctly it cost well over $100 back in the days when a dollar was worth a lot more than it is today. As I said in my earlier message, I don't think that $50 (maybe $25 in M80-era dollars?) for a super assembler is much to expect someone to spend to gain access to the fruits of our work. Though I, too, do computing as a hobby, I certainly would not dream of wasting my limited hobby time using, today, an assembler like M80, when I can have a good one for between $50 and $100. If someone really cannot afford that amount, then let them contribute the time to convert the code. So long as the source code is there, I don't see how anyone can justify a claim that things are being ruined for hobbyists. 8-Jun-87 18:46:31-MDT,1546;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Mon, 8 Jun 87 18:46:01 MDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA21584; Mon, 8 Jun 87 13:21:58 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Jun 87 17:25:45 GMT From: gollum.dec.com!opalka@decwrl.dec.com (BILL OPALKA DTN 381-1224) Organization: Digital Equipment Corporation Subject: Re: Conix vs. ZCPR3 Message-Id: <10295@decwrl.DEC.COM> Sender: info-cpm-request@simtel20.arpa To: info-cpm@simtel20.arpa Funny, I was about to ask a similar question. This past week I received Z-COM from Echelon and found that it just doesn't work correctly with my Zenith Z-89 with the Magnolia version of CPM so I have to return it to Echelon. Anyway for about the past 3 months I've played on and off with the shareware version of Conix and found it does just about everything I would buy Z-COM for except aliases and named directories. I've notice from CHI's ad that their programming system or library adds some of this capability. Has anyone used it and if so how well does it work? BTW, I'd love to know whether anyone has bought CONIX and what do they think. Is it worth buying? As far as speed, it depends on what level of memory management you have. I suggest you give the shareware version a try to see whether it meets your needs. /bill 8-Jun-87 23:08:50-MDT,1519;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Mon, 8 Jun 87 23:08:35 MDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA00554; Mon, 8 Jun 87 21:39:32 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 8 Jun 87 20:10:03 GMT From: tikal!sigma!bill@beaver.cs.washington.edu (WIlliam Swan) Organization: Summation Inc, Kirkland WA Subject: Re: Public domain BDOS replacements Message-Id: <1244@sigma.UUCP> References: Sender: info-cpm-request@simtel20.arpa To: info-cpm@simtel20.arpa In article <> W8SDZ@SIMTEL20.ARPA (Keith Petersen) writes: >There are several public domain BDOS replacements available: >DOSP25.LBR.1 BINARY 105344 CC77H (really DOS+25) >P2DOS21.ARK.1 BINARY 74624 A8C6H >SUPRBDOS.ARK.1 BINARY 61696 8386H An earlier poster mentioned that SUPRBDOS is a (later?) version of P2DOS. Can anyone comment on this? Is anyone using any of these BDOS replacements? Has anyone actually installed any of them? I would like to hear any comments about them. I've had a copy of P2DOS for a little while now, but it's been low on my list of priorities, so I haven't dealt with it yet (especially because of the sketchy documentation that came with it). -- William Swan {ihnp4,decvax,allegra,...}!uw-beaver!tikal!sigma!bill 9-Jun-87 06:39:42-MDT,2343;000000000000 Return-Path: <@wiscvm.wisc.edu:U448020@HNYKUN11.BITNET> Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Tue, 9 Jun 87 06:38:53 MDT Received: from HNYKUN11.BITNET by wiscvm.wisc.edu ; Tue, 09 Jun 87 07:16:55 CDT Date: Tue, 09 Jun 87 14:14:12 MET To: INFO-CPM@SIMTEL20.ARPA From: U448020%HNYKUN11.BITNET@wiscvm.wisc.edu Subject: another try for GSX-80 information > >Does anyone know of the existence of GSX-80 device drivers?????? > >I own a -self build- CP/M 3.0 computer, built after the CT-80 design of the >German magazine C'T (COMPUTER TECHNIK). The computer is used in combination >with a graphic terminal emulating Tektronics 4010 with a resolution of >768*560 pixels. The terminal is built after the GRIP design from the same >magazine. >As I have experienced it is quite a hard job to develop a complete GSX >device-driver. Until now I haven't got any further than drawing simple >solid lines with my self-written driver. >So my questions are: > > - Are sources available of any 'SKELETAL GIOS' (as they are named by > Digital Research) for GSX-80 screen drivers, preferably for > vector-devices like the Tektronics 4010. I have found out that on > SIMTEL20 something alike is available for GSX-86. > >or even better: > - are there any 'ready to use' device-drivers available for > Tektronics-type devices (possibly with source, for adapting some > of the differences with the real Tektronics) > >Until now the only information i have found are the files concerning >GSX-86 on SIMTEL20 and disassembly of drivers from Amstrad/Schneider >computers. > > Who can give me some help ?????? > -0-0-0-0-0-0-0-0-0-0- > >In addition of questions I have asked earlier this day about availability >of GSX-80 device-drivers. > > - Does any GSX-metafile driver exist for GSX-80 ????? > (this could enable us to exchange graphic data with Atari-ST users > and ms-dos GEM user and maybe others) > > Waling Tiersma > U448020 at HNYKUN11 on BITNET > > -0-0-0-0-0-0-0-0-0-0- PS. Has Digital Research ever published the GSX-80 manuals? (like we know of CP/M - programmers guide - system guide and above all --> - implementation guide) 9-Jun-87 09:17:17-MDT,479;000000000000 Return-Path: Received: from LL.ARPA by SIMTEL20.ARPA with TCP; Tue, 9 Jun 87 09:16:56 MDT Date: Tue 09 Jun 1987 11:16:15 EDT From: Subject: Time to Get Off the Soap Box To: info-cpm@simtel20.arpa Message-ID: I want to thank Bob Mesenbrink for enlightening me on the meaning of the smiley-face symbol ":-)". I was unaware of that convention and took the message seriously. Time to relax a bit, I guess! 9-Jun-87 18:47:06-MDT,6802;000000000000 Mail-From: KPETERSEN created at 9-Jun-87 18:46:57 Date: Tue, 9 Jun 1987 18:46 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@SIMTEL20.ARPA Subject: Special notes on UNARC16.ARK (must read) UNARCK16.ARK is a self-extracting archive. It must be renamed to UNARC16.COM and executed to extract the files within. Below is a message from Bob Freed, the author. --Keith File: UNARC.MSG Subject: Release Message for UNARC Program Version: 1.6 Date: March 27, 1987 ------------------------------------------------------------------------------ Version 1.6 of the CP/M UNARC utility: * Corrects a bug in version 1.5, which caused generation of an 'incorrect CRC' warning message (during extraction of files to disk) in certain cases where such an error condition did not actually exist. Version 1.5 of UNARC included the following changes from the previous version 1.4 release: * Provides self-unpacking archive support (see below). * Corrects a serious bug in the non-Z80 version (UNARCA.COM), which caused failure to output the last 1-255 bytes of an extracted file in certain situations. (In particular, ALL files less than 256 bytes in length could not be extracted from archives.) * Supports the new "squashed" compression method generated by the MS-DOS program PKARC (version 2.0 or later). * Provides a new command line option (P) for direct printing of files on the CP/M list device. * Provides a new command line option (C) for checking the validity of archive files. * Displays a checksum total of CRC values (useful for comparing separate copies of an archive file). * Alters the mechanism used to avoid a problem with the LUX library/archive utility program, to provide independence of UNARC from recent multiple releases of new LUX versions by different authors. (See USELUX definition in UNARCOVL.ASM overlay file.) * Minor enhancements to tab expansion and CTRL-S/CTRL-C processing during file typeout. * Expands on-line help display examples. Complete details of all of the above changes (and past history of prior UNARC releases) are provided in the version 1.5 source program file (UNARC.Z80). * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * UNARC is now distributed exclusively as a "self-unpacking" archive file, UNARC16.ARK. This allows automatic extraction of the distributed files, without requiring access to a separate copy of UNARC.COM or UNARCA.COM. To utilize this capability, simply copy or rename UNARC16.ARK to a program file, UNARC16.COM, on the current disk drive. (The exact file name UNARC16.COM is required.) Then, run this program, with a single optional command line parameter specifying the disk drive to which all distribution files will be extracted (defaults to current disk). For example, assuming UNARC16.ARK is on drive B:, and the files are to be extracted to drive C:, the following CP/M commands may be used: A>B: ; Set current drive for UNARC16.ARK B>REN UNARC16.COM=UNARC16.ARK ; Rename it to UNARC16.COM B>UNARC16 C: ; Run it to extract all files to drive C: Note that this self-unpacking capability is provided only by the distributed archive file, and it will not work if that file is altered or reconstructed. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * The following files are distributed with this release: Filename.Typ Size Recs CRC Description ------------ ---- ---- ---- ----------- 1 UNARC .MSG 7k 50 Release message (this file) 2 UNARC .COM 5k 37 17B5 Program (Z80 version) 3 UNARCA .COM 6k 45 913C Program (8080/8085 version) 4 UNARC .DOC 31k 244 A8B1 User documentation 5 UNARC .FOR 1k 4 23B4 Brief "what's it for?" abstract 6 UNARCOVL.ASM 14k 111 EEC3 Overlay source for program options 7 UNARC16 .DIF 2k 14 8E8C Version 1.6 source code differences 8 UNARC .Z80 122k 969 406F Version 1.5 source code (UNARC15S.ARK) (The CRC values shown above are those displayed by UNARC itself, and these should be used for verification purposes. These are not compatible with the values produced by other CP/M programs, such as CRCK and CHEK.) Items 1-7 are included in the self-unpacking UNARC16.ARK file. Item 5 may be used to supply a requested program description after uploading UNARC16.ARK to a remote system. Item 6 supports all user-configurable program options. Item 8 is distributed in a separate archive file, UNARC15S.ARK, and it is not required for UNARC program operation or configuration. (Due to the relatively insubstantial nature of the version 1.6 update, the new source code file is not being distributed. However, item 7 may be used, in conjunction with the SSED utility (version 2.0, by Chuck Forsberg), to generate an updated source code file from the distributed file for version 1.5.) NOTE 8080/8085 USERS: The file UNARCA.COM is an alternate version of the program which will run on your systems. However, it is larger and substantially slower than the standard (Z80-only) version, UNARC.COM. (UNARCA.COM will run on ALL CP/M systems, but it is specifically NOT recommended for users with Z80's!) RCP/M SYSOPS: The assembly language overlay file UNARCOVL.ASM is provided primarily for your use in generating a secure version of UNARC for use by remote callers. Note that several of the UNARC 1.6 changes had been distributed to RCP/M Sysops in an earlier Beta-test release (UNARC 1.42). That version was also distributed with several recent releases of the LUX utility program (by different authors), and it should now be replaced by UNARC 1.6. (If you use LUX, be sure to define USELUX = YES in the overlay file.) Due to the self-unpacking feature of UNARC16.ARK, it is no longer necessary to provide separate copies of UNARC.COM and UNARCA.COM for downloading by first-time users. (Even if you prefer the use of .LBR files on your system, you are encouraged to maintain at least this one file, UNARC16.ARK, in its distributed form!) The UNARC.DOC file provides a complete program description and user operating instructions. Refer to the notice in that file regarding rights of use and distribution of this program and its associated documentation files. Copyright (C) 1987 by Robert A. Freed All Rights Reserved ------------------------------------------------------------------------------ 9-Jun-87 21:42:41-MDT,4792;000000000000 Mail-From: KPETERSEN created at 9-Jun-87 21:42:31 Date: Tue, 9 Jun 1987 21:42 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@SIMTEL20.ARPA Subject: The ZEDUX Z280 Accelerator Forwarded from my RCP/M...I am NOT the author. --Keith Petersen Arpa: W8SDZ@SIMTEL20.ARPA Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz GEnie: W8SDZ RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST) --cut-here--ZEDUX280.DOC--cut-here-- The ZEDUX Z280 Accelerator by Rick Charnes, 7 June 1987, San Francisco What's going on here? A generic Z280 add-on card for CP/M computers? An operating system, assembler and linker already available for it? I have in front of me a copy of a document dated January 17, 1987 produced by a company by the name of Zedux, Inc. at 14402 Hamlin Ave. #C, Van Nuys, CA 91401, phone 818/787-0113 about the above. It was given to me by a gentleman at our BAMDUA general meeting last night at which Peter Mireau of MicroPro spoke. I am reading and I am amazed by what I see. This company has apparently produced a generic Z280 board called the Accel 280 and has developed not only a genuinely multitasking OS to go along with it, but an assembler and linker as well. This is the first I have heard of this. Can this be for real? The OS, called RP for Remote Partition, sounds like it culls from the best of Z- System: multiple command lines, aliases, pathing, named directories, memory-resident flow control (including REPEAT/UNTIL, WHILE/ENDWHILE, BREAK, GOTO/LABEL). There are string/shell variables and expression analysis operating on both numbers and strings. The document describes RP as being able to run any number of CP/M 2.2 "partitions" simultaneously. Each program "sees" a standard CP/M 2.2 environment, with full BDOS and BIOS access. Programs can use almost the entire 64k space without having to share this with the operating system. There is a task console handler that allows the user to control and monitor the operation of multiple tasks. Multiple terminals can be connected to the same computer and a different task run on each, with privileges given to each task. The way the multi-tasking is done is interesting. If you wish each command on your multiple command line to run subsequently one after another as we are used to, separate your commands with the familiar semicolon. If you want them to run concurrently, separate them with a "&". Multitasking has two modes. One is referred to in the document as "Unix style," in which each task's output mixes in to the console display. In the other mode, apparently when a task other than the one being worked on finishes an output line, it is made to scroll upwards. You can swap tasks with a "rotate" key which flips through the tasks currently executing. The doc also describes the Z280 single-pass assembler, AS, and linker, LN. What is going on here? Has this been happening beneath our noses with none of us knowing about it? The product is apparently available at this time for $350, with 256k DRAM. I am unsure as to why it is being supplied with only 256k RAM since we were all expecting a full meg. I assume this will be expandable at some point. A full package can be had for $600 which includes the basic hardware card, an "RP-CP/M compatible" software monitor program to talk to the chip (separately $200; I guess only necessary for development work), a extension cable if you lack sufficient space inside your computer for the board, and the assembler and linker (separately $150). A PC-Pursuit-accessible BBS line to Zedux is said to be available at (818) 787-0458 24 hours a day, 7 days a week, but I just tried it (Sunday afternoon 6/7/87) and there was no answer. From everything I can gather after having scanned the article with a cynical eye it seems like this product is up and running, ready to roll. It does not sound like vaporware: a sentence from the document reads, "The Zedux Accel 280 is available at this time." The person who gave me the document says Zilog referred him to the company. As far as I know Zedux has not contacted Echelon, user groups, or any of the traditional CP/M/Z-System institutions or sources. I have no idea if they are coordinating work with High Tech Research with the latter's UltraBoard or Echelon with their planned ZOS. I am aware of no advertising. Are they simply too busy to advertise? Is anyone using it? Does anyone know anything about this product? 10-Jun-87 06:48:48-MDT,991;000000000000 Mail-From: KPETERSEN created at 10-Jun-87 06:48:35 Date: Wed, 10 Jun 1987 06:48 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@SIMTEL20.ARPA Subject: ZCPR 3.3 Application and Programming notes available The following ZCPR 3.3 Application and Programming notes are now available from SIMTEL20: Filename Type Bytes CRC Directory PD: Z33ANOTE.0Z1.1 BINARY 1152 EA1EH Z33ANOTE.0Z2.1 BINARY 6016 70C3H Z33FIX.0Z1.1 BINARY 2304 269CH Z33PNOTE.0Z1.1 BINARY 2688 92F1H Z33PNOTE.0Z2.1 BINARY 2944 A64FH Z33PNOTE.0Z3.1 BINARY 5120 B053H These files are also available on my RCP/M and GEnie's CP/M RoundTable. --Keith Petersen Arpa: W8SDZ@SIMTEL20.ARPA Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz GEnie: W8SDZ RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST) 10-Jun-87 10:34:10-MDT,3863;000000000000 Return-Path: Received: from LL.ARPA by SIMTEL20.ARPA with TCP; Wed, 10 Jun 87 10:33:48 MDT Date: Wed 10 Jun 1987 12:33:47 EDT From: Subject: ZCPR on Tandy Model 4 To: info-cpm@simtel20.arpa Message-ID: Reply to Rob Healey -- posted to the net for general interest June 9, 1987 I do not personally know of anyone running ZCPR on the Tandy 4, but that does not mean it has not been done. Is my recollection right that the Tandy versions of CP/M are peculiar in that they use a base address of 4000H instead of 100H? If that is the case, it is much trickier to get the code right. I can try to leave a message on Z-Node Central and see if any user responds. Unfortunately, I will be leaving shortly on a month's trip, so I may not be around to receive the answer. I would expect ZCPR1 to work on just about any system with a Z80 processor, since it is a direct code replacement. No other changes to the system are required. ZCPR3 is another story completely. The BIOS has to be moved down to make room for the buffer modules, and the coldboot code has to be modified to initialize them. If Montezuma CP/M makes it DIFFICULT to drop in a new command processor, it probably makes it IMPOSSIBLE to change the BIOS. June 10, 1987 We had our Boston Computer Society meeting last night, and one of the area Tandy experts was in attendance. From what he told me, Montezuma CP/M is a standard implementation that runs programs at 100H. It was the earlier Tandy machines that had the peculiar loading address I described above. In the ZCPR33 Users Guide I describe a technique for installing ZCPR33 without using SYSGEN but using a disk utility program instead. The technique in the exact form I described there won't work in your case, but it can be adapted. The basic idea is to create a file with an image of the operating system component you want to install (for example, ZCPR.COM, ZCPR33.COM, or ZRDOS.BIN). You then go in with a late-model disk utility program that supports a queue. You go to the file containing the image and suck it up into the queue. Then you go to the sector on the system track where that operating system component is stored and flush the queue out on top of it. You should be able to use that technique to get ZCPR1 running on your system. The only time it will fail, I think, is when the system tracks and data tracks on the disk use a different format (that is the case on my BigBoard I with double-density upgrade -- the first system track is always single density). Getting ZCPR3 running still requires moving the system down to make room for the buffers. Unfortunately, the person I got my information from could not remember whether there was a full MOVCPM program included with the Montezuma CP/M. One's hopes are often falsely raised by seeing MOVCPM.COM on the disk. The manufacturer is supposed to install a relocatable version of HIS BIOS into that utility, but many manufacturers ship the utility as it comes from Digital Research -- with the Intel MDS-800 BIOS in it!!!! If you are lucky and have a real MOVCPM, you should be able to get Z3 working without inordinate effort. The change to the coldboot code can be handled by patching. If you get that far, I would be glad to provide further instructions at that time. Also, even if the BIOS cannot be moved, things are not hopeless. There are tricks that can overcome even that, but they are even more elaborate (I had to do that with my Wave-Mate Bullet -- they provided neither MOVCPM nor BIOS source). Again, if you are up to it, I would be happy to provide more detailed information. -- Jay 10-Jun-87 11:07:43-MDT,986;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Wed, 10 Jun 87 11:06:27 MDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA02147; Wed, 10 Jun 87 09:22:45 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 7 Jun 87 20:20:33 GMT From: hpcea!hpfcdc!hpldola!hp-lsd!hplsdla!ritchie@hplabs.hp.com (Dave Ritchie) Organization: Hewlett-Packard, Colorado Springs Subject: Re: Re: Floating Point Routines Message-Id: <3530003@hplsdla.HP.COM> References: <8706041708.AA19640@lll-es-s05.ARPA> Sender: info-cpm-request@simtel20.arpa To: info-cpm@simtel20.arpa Another source for the LLL Basic is one of the early CP/M UG user disks (I don't have my disk list with me, but for some reason a volume # <20 comes to mind). Dave Ritchie ..!hplabs!hp-lsd!ritchie 10-Jun-87 12:09:03-MDT,1708;000000000000 Return-Path: Received: from ucbvax.Berkeley.EDU by SIMTEL20.ARPA with TCP; Wed, 10 Jun 87 12:08:14 MDT Received: by ucbvax.Berkeley.EDU (5.57/1.25) id AA03940; Wed, 10 Jun 87 10:41:15 PDT Received: from USENET by ucbvax.Berkeley.EDU with netnews for info-cpm-ddn@simtel20.arpa (info-cpm@simtel20.arpa) (contact usenet@ucbvax.Berkeley.EDU if you have questions) Date: 9 Jun 87 17:38:27 GMT From: pwa-b!mmintl!jeffm@gr.utah.edu (Jeffrey Miller) Organization: Multimate International, E. Hartford, CT. Subject: Book listing bulletin boards wanted Message-Id: <2177@mmintl.UUCP> Sender: info-cpm-request@simtel20.arpa To: info-cpm@simtel20.arpa It seems a few months ago I heard about or read about a book containing a list of most or many bulletin boards available these days to the public for dial in. Could anyone give me a lead on this book or any kind of source listing bulletin boards available to the public. Please mail to me since I often don't read all the newsgroups I've posted this to. TIA, Jeff * Jeff Miller * * Multimate International, an Ashton-Tate Co. * * 52 Oakland Avenue, East Hartford, CT 06108-9911 * * (203) 522-2116 x257 UUCP: ...!seismo!utah-cs!utah-gr!pwa-b!mmintl!jeffm * -- * Jeff Miller * * Multimate International, an Ashton-Tate Co. * * 52 Oakland Avenue, East Hartford, CT 06108-9911 * * (203) 522-2116 x257 UUCP: ...!seismo!utah-cs!utah-gr!pwa-b!mmintl!jeffm * 10-Jun-87 22:09:17-MDT,849;000000000000 Mail-From: RCONN created at 10-Jun-87 22:09:02 Date: Wed, 10 Jun 87 22:09:01 MDT From: Rick Conn Subject: Z4 Notes To: info-cpm@SIMTEL20.ARPA Message-ID: <12309541139.11.RCONN@SIMTEL20.ARPA> In response to a couple of requests for information on ZCPR4, I have placed the files Z4.NOT and Z4.TXT in PD:. Thanks for your interest. Rick Conn PD:Z4.NOT The file Z4.TXT in PD: is a copy of some of the transparencies from my presentation on ZCPR4 at the Trenton Computer Festival. Parts of the presentation, particularly those on Ada and my current computing environment (which includes a SUN 3/260 with 8M bytes of RAM, 237M bytes of disk, running 4.3 BSD UNIX with SYSTEM V extensions with SUNTOOLS), are not included in Z4.TXT. Richard Conn, 10 June 87 ------- 10-Jun-87 22:50:32-MDT,1681;000000000000 Mail-From: KPETERSEN created at 10-Jun-87 22:48:45 Date: Wednesday, 10 June 1987 15:45-MDT Message-ID: Sender: Dick From: Dick To: w8sdz@SIMTEL20.ARPA Subject: Zedux.. ReSent-From: KPETERSEN@SIMTEL20.ARPA ReSent-To: Info-Cpm ReSent-Date: Wed 10 Jun 1987 22:48-MDT Just chatted with one of the folks at Zedux. The BBS is expected to be up by this weekend. He is still preparing docs for callers, the usual housekeeping stuff. The BBS will use the Z280 in an old Cromemco S-100 Z80 system. The Z280 is a "co-processor" not too unlike the way the various ad-on clock cards do, with the Z280 plugging into the Z80 socket, and the Z80 plugging back into the Zedux card. All parts are soldered in, no sockets. The design will accept 1 megabit Drams when available, however. Cost was a factor. He says they did talk to Echelon, but the software provided is their own, no plans to work with Echelon. The Z280 will have a 20mHz clock (10 mHz system clock) and talks to the Z80 via an 8 bit port, the Z80 beibg an I/O controller in this application. He did talk to Ampro, too, but Ampro will supposedly come out with their own single board Z280 card, and Zedux says they will be doing likewise. I am having some literature mailed to see what else he may have in print. No sources for the system software are offered, not unlike CP/M CCP/BDOS. It uses host BIOS...Multiple programs see 64k, minus 512 bytes for system vectors (page 0, Bdos/bios). That's about all I got...If you call the service, the Zedux folks will apparently call back... Dick 10-Jun-87 23:30:32-MDT,509;000000000000 Mail-From: RCONN created at 10-Jun-87 23:30:10 Date: Wed, 10 Jun 87 23:30:07 MDT From: Rick Conn Subject: PD: updated To: info-cpm@SIMTEL20.ARPA Message-ID: <12309555903.11.RCONN@SIMTEL20.ARPA> I have updated PD: with the files in PD: (which is now empty). By morning you should find the following files: PD:ZSYS.DOC PD:DIRLIST.DOC PD:ZSYS.CRCLST PD:ZSYS.USAGE PD:ZSYS.SNP (snapshot) Rick ------- 11-Jun-87 07:02:56-MDT,696;000000000000 Return-Path: Received: from E.ISI.EDU by SIMTEL20.ARPA with TCP; Thu, 11 Jun 87 07:02:50 MDT Date: 11 Jun 1987 08:02-CDT Sender: SAC.HQSAC-DOCT@E.ISI.EDU Subject: CP/M-86 From: John Wright (hqsac-doct) To: info-cpm@SIMTEL20.ARPA Message-ID: <[E.ISI.EDU]11-Jun-87 08:02:16.SAC.HQSAC-DOCT> Can anyone tell me where I can find CP/M-86 software. I have a CBM-700 that will soon be able to run CP/M-86. I am new to CP/M and this bboard so I can use your help. Also would like to know if there are any CP/M Kermit programs available. I am the moderator for a "mini-Kermit" directory and would like to have some CP/M included if it exists. Thanks John 11-Jun-87 22:47:01-MDT,4488;000000000000 Mail-From: KPETERSEN created at 11-Jun-87 22:46:34 Date: Thu, 11 Jun 1987 22:46 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Modems@SIMTEL20.ARPA Cc: Info-Micro@BRL.ARPA, Info-Cpm@SIMTEL20.ARPA, INFO-HZ100@RADC-TOPS20.ARPA, INFO-IBMPC@C.ISI.EDU Subject: FCC proposal again threatens modem users Here we go again!! From the Wall Street Journal, June 11, 1987... PHONE-ACCESS FEE IS PROPOSED FOR COMPUTERS: FCC WOULD MAKE FIRMS PAY TO LINK NETWORKS TO LOCAL PHONE LOOPS By Bob Davis, Staff Reporter of the WSJ WASHINGTON - The Federal Communications Commission proposed a fee that would steeply increase telecommunications charges for many business and residential computer users. Under the FCC proposal, companies such as US Sprint Communications Co.'s Telenet subsidiary and McDonnell Douglas Corp.'s Tymnet unit would be charged as much as $5 per hour per user to hook up their communication networks to local telephone loops. Currently, computer networks are exempt from these so- called access charges. The charges would almost certainly be passed on to consumers and business customers. US Sprint is a joint venture of GTE Corp. of Stamford, Conn. and United Telecommunications Inc., Kansas City, Mo. Price increases would be a big blow for millions of personal- computer hobbyists who depend on computer networks to communicate cheaply with one another and to call up such information services as H&R Block Inc.'s Compuserve Inc. Currently, most customers pay only a few dollars an hour in telephone costs. The proposal also would be a major setback for Telenet and Tymnet, which have attracted consumers and business customers with discount computer telecommunications rates. These companies rent private telephone lines, which previously haven't been subject to access charges, and spread the costs among thousands of computer users. Rate increases "will dry up the marketplace for new and innovative computer services" said Joseph Markowski, counsel for Adapso, a trade association of computer service companies. "Prices will go through the roof." He added that the proposal would improperly discriminate between computer-network companies and other companies that maintain their own data networks. The latter companies apparently wouldn't be charged access fees under the FCC proposal. Clark Woodford, a Compuserve executive vice president, said any access charges "will cause us to reassess our pricing structure." The FCC voted 4-0 to seek comment on a plan to end the access- charge exemption by Jan 1, 1988. The commissioners said the exemption amounted to a subsidy for the computer-network companies that was being paid by business and residential telephone users. "We don't want the (telecommunications) network to evolve in response to various subsidies and anomalities [sic]," said FCC Chairman Dennis Patrick. Agency staffers and others said the Jan 1 date wasn't firm. Page Montgomery, vice president of Economics and Technology, Inc. a Boston telecommunications company, urged the agency to delay the decision for perhaps a year until the local phone companies change their networks to give competitors equal connections. Otherwise, the regional Bell companies, which are trying to enter the computerized-communications field, would have a big advantage. That's because the computer-service companies would be burdened with price increases and also wouldn't be able to offer hook-ups to the local telephone network that are as good as those offered by the phone companies. "It would be a serious policy mistake" to end the exemption Jan. 1, 1988, Mr. Montgomery said. The FCC said that access charges should decline over the next few years, by about a dollar per hour, as the agency increases residential charges for connecting to the telephone network. Much of the revenue from these assessments is used to reduce the access charges paid by telecommunications companies. The FCC proposal came as a surprise. In March, the agency decided that computer-network companies should remain deregulated, which industry observers interpreted to mean that rates wouldn't increase. But now the FCC said that only purely private networks, operated by some big companies for their internal communications, would remain free of access charges. 11-Jun-87 23:12:42-MDT,4486;000000000000 Return-Path: Date: Thu, 11 Jun 1987 22:46 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Modems@SIMTEL20.ARPA Cc: Info-Micro@BRL.ARPA, Info-Cpm@SIMTEL20.ARPA, INFO-HZ100@RADC-TOPS20.ARPA, INFO-IBMPC@C.ISI.EDU Subject: FCC proposal again threatens modem users Here we go again!! From the Wall Street Journal, June 11, 1987... PHONE-ACCESS FEE IS PROPOSED FOR COMPUTERS: FCC WOULD MAKE FIRMS PAY TO LINK NETWORKS TO LOCAL PHONE LOOPS By Bob Davis, Staff Reporter of the WSJ WASHINGTON - The Federal Communications Commission proposed a fee that would steeply increase telecommunications charges for many business and residential computer users. Under the FCC proposal, companies such as US Sprint Communications Co.'s Telenet subsidiary and McDonnell Douglas Corp.'s Tymnet unit would be charged as much as $5 per hour per user to hook up their communication networks to local telephone loops. Currently, computer networks are exempt from these so- called access charges. The charges would almost certainly be passed on to consumers and business customers. US Sprint is a joint venture of GTE Corp. of Stamford, Conn. and United Telecommunications Inc., Kansas City, Mo. Price increases would be a big blow for millions of personal- computer hobbyists who depend on computer networks to communicate cheaply with one another and to call up such information services as H&R Block Inc.'s Compuserve Inc. Currently, most customers pay only a few dollars an hour in telephone costs. The proposal also would be a major setback for Telenet and Tymnet, which have attracted consumers and business customers with discount computer telecommunications rates. These companies rent private telephone lines, which previously haven't been subject to access charges, and spread the costs among thousands of computer users. Rate increases "will dry up the marketplace for new and innovative computer services" said Joseph Markowski, counsel for Adapso, a trade association of computer service companies. "Prices will go through the roof." He added that the proposal would improperly discriminate between computer-network companies and other companies that maintain their own data networks. The latter companies apparently wouldn't be charged access fees under the FCC proposal. Clark Woodford, a Compuserve executive vice president, said any access charges "will cause us to reassess our pricing structure." The FCC voted 4-0 to seek comment on a plan to end the access- charge exemption by Jan 1, 1988. The commissioners said the exemption amounted to a subsidy for the computer-network companies that was being paid by business and residential telephone users. "We don't want the (telecommunications) network to evolve in response to various subsidies and anomalities [sic]," said FCC Chairman Dennis Patrick. Agency staffers and others said the Jan 1 date wasn't firm. Page Montgomery, vice president of Economics and Technology, Inc. a Boston telecommunications company, urged the agency to delay the decision for perhaps a year until the local phone companies change their networks to give competitors equal connections. Otherwise, the regional Bell companies, which are trying to enter the computerized-communications field, would have a big advantage. That's because the computer-service companies would be burdened with price increases and also wouldn't be able to offer hook-ups to the local telephone network that are as good as those offered by the phone companies. "It would be a serious policy mistake" to end the exemption Jan. 1, 1988, Mr. Montgomery said. The FCC said that access charges should decline over the next few years, by about a dollar per hour, as the agency increases residential charges for connecting to the telephone network. Much of the revenue from these assessments is used to reduce the access charges paid by telecommunications companies. The FCC proposal came as a surprise. In March, the agency decided that computer-network companies should remain deregulated, which industry observers interpreted to mean that rates wouldn't increase. But now the FCC said that only purely private networks, operated by some big companies for their internal communications, would remain free of access charges. 12-Jun-87 07:30:06-MDT,1976;000000000000 Return-Path: Received: from STL-HOST1.ARPA by SIMTEL20.ARPA with TCP; Fri, 12 Jun 87 07:29:18 MDT Date: 12 Jun 1987 08:28-CDT Sender: SNELSON@STL-HOST1.ARPA Subject: Re: FCC proposal again threatens modem users From: SNELSON@STL-HOST1.ARPA To: W8SDZ@SIMTEL20.ARPA Cc: Info-Modems@SIMTEL20.ARPA, Info-Micro@BRL.ARPA Cc: Info-Cpm@SIMTEL20.ARPA, INFO-HZ100@RADC-TOPS20.ARPA Cc: INFO-IBMPC@C.ISI.EDU, asj-po-ic@ZAMA-EMH.ARPA Cc: hjaus@ZAMA-EMH.ARPA, jstarr@ANAD.ARPA Cc: tc-lists@ALMSA-1.ARPA, usarcco@SIMTEL20.ARPA Cc: lpotter@SIMTEL20.ARPA, ahogan@STL-HOST2.ARPA Cc: jfeldman@AMC-HQ.ARPA, dimattia@STL-HOST2.ARPA Cc: redman@OPTIMIS-PENT.ARPA Message-ID: <[STL-HOST1.ARPA]Fri, 12 Jun 87 08:28:24 CDT.SNELSON> In-Reply-To: In Missouri Southwestern Bell has had a 175% of the cost of a flat rate business line surcharge in effect for 10 years for dial up lines terminating in a computer. We (the Army) challenged this in 1977 through the legal troops. What had really frosted us was that we had 24 dial-up lines terminating in 3 muxes riding an AT&T 209A modem and link to the Wright-Patterson TIP. We paid! It seems the very simple way the tariff was written made anything in Missouri that is directly connected/attached to a computer port gets charged. We have 52 dial in modems and the cost per month isn't cheap. What isn't clear is whether both ends of connection are billed $5 per hour per session or $5 an hour per line regardless of use? How will they differentiate between data and voice as a lot of companies use them alternatively for voice during the day and for data during the low rate periods at night. Take a major programming change for the ESSs to track incoming calls not to mention the billing programs. Some of the older switches are pretty dumb and couldn't even do that. I wonder if the pork barrellers (congress) has EMAIL? Regards Steve 12-Jun-87 08:22:37-MDT,1987;000000000000 Return-Path: Received: from STL-HOST1.ARPA by SIMTEL20.ARPA with TCP; Fri, 12 Jun 87 07:29:18 MDT Date: 12 Jun 1987 08:28-CDT Sender: SNELSON@STL-HOST1.ARPA Subject: Re: FCC proposal again threatens modem users From: SNELSON@STL-HOST1.ARPA To: W8SDZ@SIMTEL20.ARPA Cc: Info-Modems@SIMTEL20.ARPA, Info-Micro@BRL.ARPA Cc: Info-Cpm@SIMTEL20.ARPA, INFO-HZ100@RADC-TOPS20.ARPA Cc: INFO-IBMPC@C.ISI.EDU, asj-po-ic@ZAMA-EMH.ARPA Cc: hjaus@ZAMA-EMH.ARPA, jstarr@ANAD.ARPA Cc: tc-lists@ALMSA-1.ARPA, usarcco@SIMTEL20.ARPA Cc: lpotter@SIMTEL20.ARPA, ahogan@STL-HOST2.ARPA Cc: jfeldman@AMC-HQ.ARPA, dimattia@STL-HOST2.ARPA Cc: redman@OPTIMIS-PENT.ARPA Message-ID: <[STL-HOST1.ARPA]Fri, 12 Jun 87 08:28:24 CDT.SNELSON> In-Reply-To: In Missouri Southwestern Bell has had a 175% of the cost of a flat rate business line surcharge in effect for 10 years for dial up lines terminating in a computer. We (the Army) challenged this in 1977 through the legal troops. What had really frosted us was that we had 24 dial-up lines terminating in 3 muxes riding an AT&T 209A modem and link to the Wright-Patterson TIP. We paid! It seems the very simple way the tariff was written made anything in Missouri that is directly connected/attached to a computer port gets charged. We have 52 dial in modems and the cost per month isn't cheap. What isn't clear is whether both ends of connection are billed $5 per hour per session or $5 an hour per line regardless of use? How will they differentiate between data and voice as a lot of companies use them alternatively for voice during the day and for data during the low rate periods at night. Take a major programming change for the ESSs to track incoming calls not to mention the billing programs. Some of the older switches are pretty dumb and couldn't even do that. I wonder if the pork barrellers (congress) has EMAIL? Regards Steve 12-Jun-87 11:14:05-MDT,979;000000000000 Return-Path: <@wiscvm.wisc.edu:MSRS003@ECNCDC.BITNET> Received: from wiscvm.wisc.edu by SIMTEL20.ARPA with TCP; Fri, 12 Jun 87 11:13:43 MDT Received: from ECNCDC.BITNET by wiscvm.wisc.edu ; Fri, 12 Jun 87 12:11:39 CDT Date: Fri 12 Jun 1987 12:11 CDT From: Scott McBurney Subject: An old question... To: Back to a question I posed a few months ago, does anyone out there know how I can get to comp.sys.tandy on USENET. From what I have heard, it might be near impossible from Bitnet. Thanks, Scott McBurney - Western Illinois University Bitnet: MSRS003@ECNCDC Internet: MSRS003%ECNCDC.BITNET@WISCVM.WISC.EDU GEnie: S.MCBURNEY --------------------------------------------------------------- "Earthquake? That explains why the floor was moving 4 inches." --------------------------------------------------------------- 12-Jun-87 11:25:39-MDT,4004;000000000000 Return-Path: Received: from LL.ARPA by SIMTEL20.ARPA with TCP; Fri, 12 Jun 87 11:25:02 MDT Date: Fri 12 Jun 1987 13:24:47 EDT From: Subject: Myths about ZCPR3 To: info-cpm@simtel20.arpa Message-ID: I am always sorry to see certain myths perpetrated about ZCPR3, especially the ones that say ZCPR3 is good only on hard-disk systems and that it uses up too much TPA. Different people have different personal styles in computing, and some will like the way ZCPR works and what it offers while others will not. But the choice should be made on sound facts and sound reasoning. It is only in the last year that I have had any personal 8-bit computer system with a hard disk (I still do most of my work on a BigBoard I and SB180 with only floppy drives), and I have always used ZCPR (1, 2, and 3) to what I felt was great advantage. It is certainly true that ZCPR3 runs much better on the hard-disk and RAM-disk systems, but what doesn't? ZCPR3, because of its various forms of extended processing (path searching, extended command processing, and error handling) does tend to be more disk intensive. In one of my columns in The Computer Journal I described techniques that can be used to significantly speed up these features with floppy systems to the point that they approach hard-disk performance levels. As for the reduction of TPA, it is quite true that a full-blown ZCPR3 implementation uses up a lot of TPA -- between 4K and 6K. In the kind of work I do (wordprocessing, assembly language programming, and operation of a remote access computer system), TPA is not a problem, and I have even opted to use larger than standard RCP, FCP, and NDR modules for the conveniences they offer. I understand that people who use C compilers often have problems getting enough TPA space (sounds as though someone should write a good virtual-memory C compiler like the SLR Systems virtual assemblers). Although a full-blown ZCPR3 system uses lots of memory, it is not a fair comparison to contrast CP/M -- with virtually none of the features -- only with ZCPR3 in its largest configuration. One can make a ZCPR3 system that costs only 0.75K bytes of TPA that offers: automatic command search path (dynamically changeable) multiple commands on a line (200+ characters) aliases (infinitely nestable and recursive with extensive parameter expansion capability) extended command processing (highly efficient and powerful ARUNZ alias generation) nested shells (including command line history with recall, searching, and editing) error handling (with command line editing) terminal-independent operation (UNIX-like TCAP) Thus, as with so many things in this world, more than 80% of the features come with less than 20% of the cost. The components in ZCPR3 that cost big memory are the ones that can most easily be omitted: the named directory register (NDR, 0.25K per 14 names), the flow command package (FCP, typically 0.5K), the resident command package (RCP, typically 2K), and the input/output package (IOP, typically 1.5K). I have had little use for an IOP and do not have it in use on any of my systems (though many people like the I/O redirection and keyboard macro IOPs that are available from Echelon). With my larger-than-usual NDR (35 names), FCP (0.625K), and RCP (2.25K), I sacrifice a total of 4.25K of TPA. When I use my database manager, the only program I use that does make heavy demands on TPA, I will just boot up the small ZCPR system. I can afford the cost of 0.75K. In ZCPR version 3.3, by the way, the NDR, FCP, and RCP modules can be configured dynamically, making it even easier to change the system configuration. I hope that some people will look more carefully before they dismiss ZCPR3 as too big or too slow or too hard to use. It might not be the thing for you, but then again it might. 12-Jun-87 11:28:32-MDT,13334;000000000000 Return-Path: Received: from LL.ARPA by SIMTEL20.ARPA with TCP; Fri, 12 Jun 87 11:26:14 MDT Date: Fri 12 Jun 1987 13:24:29 EDT From: Subject: Example of Aliases under ZCPR33 To: info-cpm@simtel20.arpa Message-ID: I have attached a copy of my ZCPR33 application note on the use of the ARUNZ extended command processor to illustrate what a ZCPR33 system, even one that uses only 0.75K of TPA, can do. The examples in it apply to remote access system applications, but there are a great many uses for aliases on a personal system as well. For my assembly language work, for example, I have alias scripts like the following (they do make use of FCP flow commands): LINK=LNK slrnk+ /v,$1/n,$1/m,/a:100,/j,$1,a:z33slr/s,a:vslr/s, a:z3slr/s,a:sysslr/s,/e AL slr180+ $1.z80/gr,,nul;if ~error;/lnk $1;fi EAL edit $1.z80;if input assemble and link?;/al $1;fi WORK xif;/eal;if input continue?;work $1;fi If I want to link PROGRAM.REL with the standard Z-System libraries, all I have to enter is "LNK PROGRAM". The AL script first assembles the specified program ($1) and then links it using a nested alias invocation. Flow control is used to perform the linkage only if the assembly was successful. EAL, which adds editing to the alias, involves doubly nested aliases and a further use for flow control. Finally, WORK is recursive. "WORK PROGRAM" takes one through any number of edit-assemble-link cycles until one answers the prompt to continue with a negative response. There is actually a much more elegant and rigorous way to implement recursive aliasing, but it is too involved to describe here. Once the proper aliases are included in ALIAS.CMD, it is as easy as "RECURSE EAL PROGNAME" to invoke. It is described in my most recent column in The Computer Journal. - - - - - - - - - - - - - - - - ZCPR33 APPLICATION NOTES Note Number: 002 Author: Jay Sage Date: June 8, 1987 Making Effective Use of ARUNZ as an Extended Command Processor (Especially on a Remote Access System) From my recent experience using several ZCPR33 remote access systems, most sysops are not aware of the way ARUNZ can be used as an extended command processor to make the operation of their system much, much easier for their users. Because a single 4K ALIAS.CMD file can contain hundreds of aliases, the cost in disk space to provide a highly error- tolerant environment to the user is very small. These techniques can also be used to great advantage on a personal system to make the sytem highly tolerant of errors. The kinds of aliases can be grouped loosely into three categories, each of which I will cover below. At the end I will describe a method for making these aliases execute at top speed. Alternate Command Forms ----------------------- The most obvious use of aliases is to provide alternative names for commands. We will use an example to illustrate the principle. Consider the task of finding out if a certain file is somewhere on the system and where. Some systems use FINDF, the original ZCPR3 program for this purpose; others use one of the standard CP/M programs (WIS or WHEREIS); and others have begun to use the new, enhanced ZSIG program called FF. This can be very confusing to new users or to users who call many different systems. The solution is to provide aliases for all the alternatives. Suppose FF is the real program in use. Then the following line in ALIAS.CMD will allow all the forms to be used equally: FINDF=WIS=WHEREIS ff $* (I am following a convention of writing the alias names in upper case and the script in lower case. This is only for ease in reading; ARUNZ is not case sensitive.) In fact, while I am at it, I usually throw in a few other forms that someone might try and that are sufficiently unambiguous that one can guess with some confidence that this is the function the user intended: FIND.FILE=FILE.FIND=WIS=WHERE.IS ff $* Since (for ARUNZ version 0.9D and later) the characters after a period are optional-match characters (they must match only if characters are present), the first name will match FIND, FINDF, and FINDFILE (and others). The last form will match both WHERE and WHEREIS (and others). Note that this single alias, which occupies 40 bytes in ALIAS.CMD (including the CRLF), responds to 8 commonly used commands for finding files on a system. Thus the cost is a mere 5 bytes per command!! ZCPR33 introduced the ability to bypass path searching and go straight to the extended command processor by prefixing a command with a space or slash. As users begin to avail themselves of this feature to speed up command processing, it may happen that someone will enter the command as "/FF" or " FF", thinking that "FF" is an alias for the real command. With the script above this will fail. Therefore, I am now recommending including the real command as an alias for itself to cover this situation. The final form for our file-finding alias (with an extra change thrown in to allow the short form "WH") is thus: FIND.FILE=FILE.FIND=WIS=WH.EREIS=FF ff $* I have extended the use of command aliasing even to include the results of common typing mistakes. Richard Jacobson (Mr. Lillipute), who calls my system quite often, either has a Wyse keyboard with very bad bounce (as he claims) or is a lousy typist (and refuses to admit it). When he wants to display a directory, his command is more likely to come out DDIR or DIRR than it is to come out correctly as DIR. So I added those two forms to my alias, so it now reads: XD.IR=DDIR=DIR.R dir $* Is seven extra bytes too much to sacrifice for a friend! Alternate Directory Changing References --------------------------------------- It is obviously very hard for users to remember the DU forms for directories on a remote system, and that is why named directories are provided. But even names are not always easy to remember precisely. Aliases can help by providing alternative names for logging into directories, provided ZCPR33 has been assembled with the BADDUECP option enabled so that invalid directory-change references are passed on to the extended command processor. My system has a directory called Z3SHELLS (I think). Since even I have trouble remembering that it is not Z3SHELL or SHELLS or SHELL, I would have a line in ALIAS.CMD that reads: Z3SHELL:=SHELL:=SHELLS: z3shells: A further problem is that users often (and I occasionally) forget to type the colon on the end. It is very easy for ARUNZ to pick this up as well and add the colon for you. Just include the following alias: Z3SHELL=Z3SHELLS=SHELL=SHELLS z3shells: All of these aliases can be combined into the single script: Z3SHELL.:=Z3SHELL.S:=SHELL.:=SHELL.S: z3shells: All seven forms are covered by an entry of 49 bytes, a cost of 7 bytes each. On my system I provide a complete set of aliases for all possible directories so that any legal directory can be entered with or without colons and using either the DIR or the DU form. Thus, if Z3SHELLS is B4, the script above would be: Z3SHELL.:=Z3SHELL.S:=SHELL.:=SHELL.S:=B4.: z3shells: Before ZCPR33 came along and provided this service itself, I would allow callers to use the DU form to log into directories beyond the max- drive/max-user limits by including aliases of the above form. If the maximum user area were 3 in the above example, the commands "B4:" and "B4" would still have worked (even under ZCPR30) because ARUNZ mapped them into a DIR form of reference. Although this is no longer necessary, a complete alias line like the one above covers all bases. The user can even enter any of the commands with a leading space or slash and they will still work. Finally, I usually provide a catch-all directory change alias to pick up directory change commands that don't even come close to something legal. At the end of ALIAS.CMD (i.e., after all the other directory-change aliases described above, so that they get first shot) I include the line" ?:=??:=???:=????:=?????:=??????:=???????:=????????: echo d%>irectory %<$0%> is not an allowed directory. %he^m^j valid directories are:;pwd Thus when the user enters the command "BADDIR:", he get the PWD display of the system's directories prefixed by the message Directory BADDIR: is not an allowed directory. The valid directories are: Note the use of Z33RCP's advanced ECHO command with case shifting ('%< to switch to upper case and '%>' to switch to lower case) and control character inclusion (caret followed by the character). Abbreviated Commands -------------------- This category is closely releated to the first category described above. Consider transferring files. One commonly enters a command like KMD SK FN.FT Of course, some systems still use XMODEM, so it is handy to have an alias (according to the first category above) that reads: XMODEM=KMD kmd $* But why require the user to type KMD or XMODEM at a