2-Jul-84 00:48:39-MDT,1680;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 00:48:32-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 2 Jul 84 2:20 EDT Received: From dca-eur.arpa.ARPA by BRL-AOS via smtp; 2 Jul 84 2:18 EDT Date: 2 July 1984 06:17 GMT From: bower@Dca-Eur.ARPA Subject: MOVCPM generalities To: abn.iscams@Usc-Isid.ARPA CC: info-cpm@Brl-Aos.ARPA Date: 2 Jul 1984 05:59:10 Z Text: Reference your query on MOVCPM. Can't help you specifically, but a general description might help. The program contains general prompt routines, a routine to compare the imbedded serial number against the serial number in the operating BDOS, and a relocation module. Binary versions of the CCP and BDOS are in the upper portion of MOVCPM 'orged' to a starting location of 0000H. When the size of the new system is selected, (assuming the serial numbers match), the relocation program starts scanning the "dummy" CCP/BDOS/BIOS and adding an offset byte to all jumps, calls and references to addresses. The identification of those bytes is from a table of "bit maps". If you are familiar with the Digital Research Page Relocatable Files, (file type .PRL) this will all be familiar. If not, trust me, it works. The new locations for the "moved" system is as stated in the system documentation. I suffered through an episode similar to yours when I integrated ZCPR2 into my MOVCPM to make installation easier, and wound up writing my own linker for relocatable files (.REL), since I use Microsoft's Macro-80 assembler which does not produce .PRL files. Hope this helps. Hal Bower 2-Jul-84 07:00:40-MDT,1267;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 07:00:34-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 2 Jul 84 8:32 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 2 Jul 84 8:23 EDT Date: 2 Jul 1984 06:23 MDT (Mon) Message-ID: From: Richard Conn To: info-cpm@Brl-Aos.ARPA Subject: ZCPR3 Phase 1 Release ongoing The Phase 1 release of ZCPR3 is definitely taking place. I received a call from the San Diego Computer Society (Dick Mason) last night, and they have received the disks and plan to begin distributing on Monday (today). Also, in a phone call with Frank Gaude of Echelon, I found out that ZCPR3 is now on several large (multi-meg) BBSs in Silicon Valley and at lease one large on in Los Angeles. As of a few days ago, SIG/M had not received theirs, but since the others are, I suspect it is just a matter of time before SIG/M does (hopefully days). Will let you know about things as I find out myself. One other thing -- SIMTEL20 does not yet have ZCPR3 on line, but we suspect that the package is somewhere in the mail system at White Sands. In the words of JEP -- Real Soon Now. Rick 2-Jul-84 07:39:08-MDT,4307;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 07:38:54-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 2 Jul 84 8:56 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 2 Jul 84 8:47 EDT Date: 2 Jul 1984 06:47 MDT (Mon) Message-ID: From: Richard Conn To: info-cpm@Brl-Aos.ARPA Subject: ZCPR3 Phase 2 ... is coming along quite nicely. The new DU3 is finished, complete with its online documentation (which is rather extensive) and its new screen-oriented editor. The editor ties in as an optional command-line interface. You can select it in place of the simple DU3 prompt, and it displays the block you are currently positioned to, a small menu of commands, and a cursor which points to a byte in that block. You can move the cursor around to select any particular byte, and then you can enter a string of chars or a list of hex values to place into the block starting at the cursor. You can then write the block to disk, advance to the next block, backup to the previous, etc, as well as issue any value DU3 command string, including macros, to go through a more complex command sequence and then return to the editor automatically at the last block you were positioned at. DU3, by the way, stands for Disk Utility version 3. There now exists the prototype of MU3, a screen-oriented Memory Utility, which resembles the DU3 screen-oriented editor but works on memory only. Great for looking at ZCPR3 itself, testing RCPs and FCPs, etc. I am concurrently creating the DEBUG Resident Command Package which is a scaled-down version of MU3, but it can be invoked without impacting the TPA at all. Finally, the new VFILER for ZCPR3 is almost done. Just a few hours work on it to go. I was in the middle of VFILER when Hal Carter came up with the idea of having an MU3 utility after he saw DU3 run, and so the break to create MU3 occurred. I need to play with MU3 a little to decide what features it really needs before it will be finished. Once DU3, MU3, and VFILER are done, the last major utility, VMENU, will be on the agenda. VMENU is a combination of VFILER and MENU which I think will be a neat tool by itself. I have some concerns about how fast it will be, creating new directory displays every time it is invoked, and I think these concerns will be resolved only after VMENU is running and I have used it a few times. A few little utilities will also be included in the ZCPR3 Phase 2 release, but they are minor in terms of effort. The book is now outlined, with Hal Carter providing many useful ideas on what its structure and nature should be (thanks, Hal). I think it will be vastly superior to the ZCPR2 documentation, having a nice table of contents, index, appendices summarizing commands available with the various utilities and subsystems, etc. A lot of the book can be put together from the online documentation, so that should go quickly, but there are still major portions which I need to write. I hope to have the outline and online documentation fill complete and sent to the publisher by the end of this week, so this part can be edited while I proceed with the newer, detailed sections. The second book, on the ZCPR3 libraries, will also be started soon, but I'm not sure when. In the meantime, the installation manual and user's perspective document are being printed by Echelon now, and Echelon plans to distribute it with the $39 basic set of disks. You can also get these books independently from Echelon for a small price ($9 was the last figure I heard). Contact Echelon for details. You, of course, have several options in acquiring hardcopy of this documentation -- it is on disk and can be printed, but the whole thing is on the order of 160 pages. Your local computer club may decide to make a print run on it also. Note that I have been talking about the Phase 1 manuals (on the Phase 1 disks) so far. The books are a different matter and will not be available on disk (who would want to print something THAT BIG anyway?). Finally, there may be a ZCPR3 newsletter in the works. More details later if this becomes reality. Rick 2-Jul-84 11:52:38-MDT,697;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 11:52:29-MDT Received: From xerox.arpa.ARPA by AMSAA via smtp; 2 Jul 84 10:57 EDT Received: from CheninBlanc.ms by ArpaGateway.ms ; 02 JUL 84 07:55:50 PDT Date: Mon, 2 Jul 84 07:53 PDT From: Eldridge.es@XEROX.ARPA Subject: Help on Enchanter needed To: Info-CPM@AMSAA.ARPA cc: Eldridge.es@XEROX.ARPA Reply-To: Eldridge.es@XEROX.ARPA I am playing the CP/M version of Infocom's ENCHANTER, but am currently stuck at 285 points. I would like to hear from anyone who has gotten further. George PS: Let me know if there is a better distribution list for type of request. 2-Jul-84 15:03:20-MDT,1356;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 15:03:11-MDT Date: Mon, 2 Jul 84 16:15:16 EDT From: Dave Towson (info-cpm) To: info-cpm@Amsaa.ARPA Subject: [Roz: Touch Typing Teaching Request] This message was addressed to info-cpm-request. I don't have any information about the subject. Can anyone else help? ----- Forwarded message # 1: Received: From radc-multics.arpa.ARPA by AMSAA via smtp; 2 Jul 84 13:19 EDT Date: Mon, 2 Jul 84 12:26 EDT From: " Roz " Subject: Touch Typing Teaching Request To: info-cpm-request@AMSAA.ARPA cc: RTaylor@RADC-MULTICS.ARPA Message-ID: <840702162655.689169@RADC-MULTICS.ARPA> My husband wants to learn to touch type. (Due to spending approx 1.5 hrs typing a 7 line letter via hunt-and-peck, last week.) I have an S-100 Z-80 based CP/M system with 8" disk drives. Pointers, comments, recommendations (both for and against) on software ("games" which teach are acceptable) are welcome. Please use E-mail, and if there are any replies, I will consolidate to the BB (assuming the info isn't already there). Thanks a bunch! Roz ----- End of forwarded messages Dave Towson info-cpm-request@amsaa.arpa 2-Jul-84 15:30:24-MDT,689;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 15:30:17-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 2 Jul 84 16:49 EDT Received: From apg-1.arpa.ARPA by BRL-AOS via smtp; 2 Jul 84 16:43 EDT Date: 2 Jul 1984 16:28:36 EDT (Monday) From: William Skidmore DRSTE-TOF 5323 Subject: Dan Jones To: info-cpm@BRL.ARPA Cc: wskidmo@Apg-1.ARPA I have modem 7xx overlays for md-2, md-3 and md-11 computers which I will gladly share with you. My work phone number is AVN 283-5517. Bill Skidmore 2-Jul-84 17:37:49-MDT,698;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 17:37:42-MDT Received: From su-score.arpa.ARPA by AMSAA via smtp; 2 Jul 84 18:54 EDT Date: Mon 2 Jul 84 15:43:26-PDT From: Sam Hahn Subject: Re: [Roz: Touch Typing Teaching Request] To: cpmlist@AMSAA.ARPA cc: info-cpm@AMSAA.ARPA, RTaylor@RADC-MULTICS.ARPA In-Reply-To: Message from "Dave Towson (info-cpm) " of Mon 2 Jul 84 14:06:05-PDT I find that HyperTyper is a good piece of software. Simple, and easy to use. Works on about a dozen different areas, eg. asdf/jkl; etc. It will time you for speed, if that's of interest. ------- 2-Jul-84 18:39:57-MDT,504;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 18:39:48-MDT Received: From utexas-20.arpa.ARPA by AMSAA via smtp; 2 Jul 84 20:06 EDT Date: Mon 2 Jul 84 19:07:23-CDT From: Douglas Good Subject: BBSes for CP/M To: info-cpm@AMSAA.ARPA I am trying to open up a BBS but currently have no BBS software. Are there any other BBS's for CP/M other than RBBS? --Doug Good ------- 2-Jul-84 21:30:11-MDT,2262;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 21:30:01-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 2 Jul 84 22:56 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 2 Jul 84 22:45 EDT Received: from Usenet.uucp by sri-unix.uucp with rs232; 2 Jul 84 18:41-PDT Date: 27 Jun 84 8:44:49-PDT (Wed) To: info-cpm@Brl.arpa From: decvax!decwrl!flairvax!kissell@Ucb-Vax.arpa Subject: Re: Zilog SIO as a network controller Article-I.D.: flairvax.599 In-Reply-To: Article <1283@sri-arpa.UUCP> (Get thee behind me!) First, an appology for posting this netwide, but we are not an ARPANET site. Besides, it might be generally amusing. Z80 SIO's as network controllers are pretty common. Sytek's Localnet broadband LAN uses SIO's running at 128Kbits. I believe that Corvus' Omninet uses them also (corrections, folks?), and I know of others more obscure ("Bestnet", for instance). At usefully high speeds, one needs to run in a synchronous mode, because in asynchronous modes the SIO requires a 16*bitrate clock for character framing, whereas in synch modes it uses a 1*bitrate clock, so for a given quality of clock circuit one can run 16 times faster in synch mode. Forget the bisync mode, as it requires more processor intervention than HDLC mode. At speeds in excess of 500Kbits, you will probably need some kind of DMA circuitry to move the data for you. The SIO has only one DMA request line per channel (it is a 2 channel device), so If you want to run full duplex (and you might, depending on your access method), you will have to send on one channel and recieve on the other. No big deal, but it makes some of the software a little bizzare. I'm not going to dump a monologue on possible access methods on the net, except to say that chapter 7 of Tannenbaum's "Computer Networks" is a good place to start, but by no means an exhaustive look at the problem. Kevin D. Kissell Fairchild Research Center Advanced Processor Development uucp: {ihnp4 decvax}!decwrl!\ >flairvax!kissell {ucbvax sdcrdcf}!hplabs!/ "Any closing epigram, regardless of truth or wit, grows galling after a number of repetitions" 2-Jul-84 23:32:49-MDT,1117;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 23:32:44-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 3 Jul 84 0:42 EDT Received: From apg-1.arpa.ARPA by BRL-AOS via smtp; 3 Jul 84 0:30 EDT Date: 2 Jul 1984 21:06:30 EDT (Monday) From: Robert Bloom DRSTE-TOI 3775 Subject: Touch Type Tutor To: rtaylor@Radc-Multics.ARPA Cc: info-cpm@Brl-Aos.ARPA I have a public domain typing tutor for cp/m. It was written by (i fergit - i think it's a Canadian though) and runs under mbasic. It supposed to be compilabile, but not having a compiler, I don't know for sure. I've adapted it for nearly vanilla CP/M - it needs only a cursor position sequence and hi/low lighting if you have it. I'm willing to upload it but think it's already somewhere in the sig/m or cpmug catalogs - maybe someone else knows. {Ah-hah ... found it! Sig/m vol 83. Lessons are TTYPEX?.DAT, main program ttype.bas, help files tthelp?.dat, and doc file ttype.doc. And it's from Australia, not Canada (only 180 degrees wrong!). -bob bloom 3-Jul-84 01:27:10-MDT,662;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 01:27:06-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 3 Jul 84 2:51 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 3 Jul 84 2:43 EDT Date: Tue 3 Jul 84 00:43:09-MDT From: Ron Fowler Subject: MEXNEWS.004 now available To: info-cpm@BRL.ARPA The new MEXNEWS (on SIMTEL20 as MICRO:MEXNEWS.004> provides an important bug fix for batch-transfer users, some information on stubborn MDM7 overlays, and the previously missing documentation for ALDS features provided by MEX. --Ron Fowler ------- 3-Jul-84 02:22:29-MDT,2298;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 02:22:06-MDT Received: From mit-mc.arpa.ARPA by AMSAA via smtp; 3 Jul 84 3:54 EDT Date: 3 July 1984 03:55-EDT From: Jerry E. Pournelle Subject: Magazine Articles To: ABN.ISCAMS@Usc-Isid.ARPA cc: info-cpm@Amsaa.ARPA In-reply-to: Msg of 29 Jun 1984 17:00-EDT from ABN.ISCAMS at USC-ISID.ARPA As a general case, software in magazines is copyrighted; the ownership of the rights involved depends on the contract between author and magazine. Most magazines buy "all rights" and give back most to the authors; some professional authors however never sell anything but "first serial" or some such. Thus articles in magazines and programs in magazines have about the same status: you'd not take a short story from Analog Science Fiction and put it on the net for all to use without the author's consent, would you? Some authors will give their blessing. Some authors would but they don't own the rights and the magazines won't. Eventually there will be on line versions of those programs and download fees (reasonable) which will take care of your problem. Meanwhile, if you type in a program from a magazine and run it, you are on safe ground; this is clearly "fair use" and indeed how could you enjoy the magazine which you bought if you could not? If you give a copy to a friend, you are in technical violation of someone's -- probably the author's -- rights, but no one is likely to complain. If you type it in and sell it you are clearly in violation of both ethics and the law. Putting it on a bulletin board is, therefore, clearly illegal; in the past, before there was any way for authors and publishers to exploit their rights, no one much cared, and indeed many BYTE programs went the user group and club rounds with blessing; but now, when it is getting possible to put the programs on line and charge, I think the authors are entitled to some consultation. Many will of course give their programs away. Some cannot afford to do that. I could not afford to give my stories and novels away; I have no other source of income. I expect that some programmers must feel the same way about their programs. JEP 3-Jul-84 03:50:50-MDT,1166;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 03:50:44-MDT Received: From xerox.arpa.ARPA by AMSAA via smtp; 3 Jul 84 5:17 EDT Received: from GreeneKing.ms by ArpaGateway.ms ; 03 JUL 84 02:16:32 PDT Date: 3 Jul 84 10:16:39+0100 (Tuesday) From: Hirst.rx@XEROX.ARPA Subject: Re: BBS's for CP/M In-reply-to: CMP.DOUG's message of Mon, 2 Jul 84 19:07:23 CDT To: Douglas Good cc: info-cpm@AMSAA.ARPA Doug, After phoning around, I chose CBBS by Ward Christensen and Randy Suess (spelling?) and have installed CBBS to my Xerox 820. It's written in 8080 code and has many features. As well as being straight forward to use, it runs fast in a small amount of code and has nice features for unwanted or frivolous guests. It does cost $50 payable to Randy in Chicago. If you want to use a high level language you could look into the new one written in 'C' which has "rooms", can't remember the name offhand, I'd be interested to hear if anyone has used PL/I for this sort of thing, I'd heard its the most portable language across the 8 & 16 bit world. Ken 3-Jul-84 10:10:24-MDT,1556;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 10:10:16-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 3 Jul 84 11:31 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 3 Jul 84 9:37 EDT Date: 3 Jul 1984 07:37 MDT (Tue) Message-ID: From: Richard Conn To: info-cpm@Brl-Aos.ARPA Subject: To Zemon (bad ret adr) The following was addressed to felix!zemon@berkeley, but the mailer keeps trapping it. Sorry for the additional traffic on INFO-CPM. From: MAILER-DAEMON at Berkeley (Mail Delivery Subsystem) To: Re: Returned mail: Host unknown ----- Transcript of session follows ----- bad system name: felix 550 ... Host unknown ----- Unsent message follows ----- Date: 2 Jul 1984 23:00 MDT (Mon) From: Richard Conn To: Art Zemon Subject: Some Metrics on the ZCPR3 Release In-Reply-To: Msg of 2 Jul 1984 10:31-MDT from Art Zemon One other thing -- if a COMPANY wants to include ZCPR3 with their product, it is here where I hope to make the money. Echelon grants licenses for this, and the company can feel that they are not "ripping off" the author. If a company goes ahead without the license, the resulting bad PR could hurt it. I really don't like the idea of someone making an outright profit off of the PD, and I am trying to make a statement here. 3-Jul-84 10:32:23-MDT,967;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 10:32:18-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 3 Jul 84 11:30 EDT Received: From apg-1.arpa.ARPA by BRL-AOS via smtp; 3 Jul 84 9:02 EDT Date: 3 Jul 1984 8:50:27 EDT (Tuesday) From: Norman Pentz DRSTE-ADA 5279 Subject: Olivetti Printer To: info-cpm@Brl.ARPA Cc: npentz@Apg-1.ARPA To anyone having experience or knowledge about the following, please send your recommendation/advice--------- I am in the market for a printer. DAK is offering the Olivetti PR-2300 "Dry Ink Jet" printer at 60% off list price. Is this really a good printer or are there problems with it or the dry ink technology? Any information or opinions will be greatly appreciated. Please respond directly. If useful information is generated, I will summarize for the net. Thank you! Norm Pentz npentz@apg-1 3-Jul-84 11:06:35-MDT,1418;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 11:06:27-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 3 Jul 84 12:22 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 3 Jul 84 12:17 EDT Date: 2 Jul 1984 22:55 MDT (Mon) Message-ID: From: Richard Conn To: Art Zemon Cc: rconn@Brl-Mis.ARPA, info-cpm@Brl-Aos.ARPA Subject: Some Metrics on the ZCPR3 Release In-reply-to: Msg of 2 Jul 1984 10:31-MDT from Art Zemon ZCPR3 is not in the public domain. However, I have no intentions of making any money on it (altho I may make some thru Echelon, but that is just gravy), and distribution is taking place via the conventional "public domain" channels. ZCPR3 is being released to the User Community, whatever that is. You see, the whole issue of PD software has turned into such a mess ... if I "call" it PD software, I lose all rights to it. In the manner it is going out, the PD community can freely access it without any loss of rights on my part. There are conveniences in acquiring it thru Echelon, such as hardcopy of the documentation and support, but Echelon is just an alternative you have (as opposed to SIG/M, BBSes, etc). Feel free to access it in any manner convenient to yourself. Rick 3-Jul-84 12:28:09-MDT,861;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 12:28:01-MDT Received: From hi-multics.arpa.ARPA by AMSAA via smtp; 3 Jul 84 13:23 EDT Date: Tue, 3 Jul 84 12:18 CDT From: "David S. Cargo" Subject: ? OMNIET i/f for S-100 To: info-cpm@AMSAA.ARPA Message-ID: <840703171841.340342@HI-MULTICS.ARPA> Does anybody know if anybody makes/distributes/supports an OMNINET interface for S-100 computers (ideally with software that runs with CP/M-80)? I'm interested in interfacing my IMSAI 8080 to something like the Corvus Bank, Corvus hard disk servers, and other machines on OMNINET. I thought I saw mention of a CompuPro interface in the latest BYTE. Any pointers, experiences, war stories, or horror stories appreciated. David S. Cargo (Cargo at HI-Multics) 3-Jul-84 20:19:00-MDT,1181;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 20:18:51-MDT Date: Tue, 3 Jul 84 21:29:26 EDT From: Dave Towson (info-cpm) To: info-cpm@Amsaa.ARPA Subject: [Douglas Good: Pascal] I have answered Doug's question regarding BDS-C. Can anyone help with the other question? ----- Forwarded message # 1: Received: From utexas-20.arpa.ARPA by AMSAA via smtp; 2 Jul 84 20:09 EDT Date: Mon 2 Jul 84 19:10:16-CDT From: Douglas Good Subject: Pascal To: info-cpm-request@AMSAA.ARPA I'm having trouble starting up Pascal on my system (UCSD) and am not finding the documentation very much help. I have a 64k system and am pretty sure I have the standard 512byte BIOS. But I can't figure out from reading the only helpful documentation I could find, BOOTER.DOC, how to set it up. I'm also looking for BDS-C in the downloads and can't figure out if it's public domain or not. If so can you tell me where it is? All help appreciated, Doug Good ------- ----- End of forwarded messages Dave Towson info-cpm-request@amsaa.arpa 4-Jul-84 09:42:57-MDT,7008;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 4 Jul 84 09:42:39-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 4 Jul 84 10:54 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 4 Jul 84 10:51 EDT Date: 4 Jul 1984 08:51 MDT (Wed) Message-ID: From: Richard Conn To: APratt.PA@XEROX.ARPA MMDF-Warning: Parse error in preceeding line at BRL-AOS.ARPA Cc: info-cpm@Brl-Aos.ARPA Subject: Some Metrics on the ZCPR3 Release In-reply-to: Msg of 4 Jul 1984 00:00-MDT from The following is my reply to a query I have been hearing recently -- if I know how to modify a BIOS to install ZCPR3, do I really want to or would ZCPR1 or ZCPR2 do the job? I felt the community in general may be interested in the reply. Yes, it sounds like you *could* install ZCPR3 if you wanted to. Make sure you get the source to your BIOS ... all you need to modify is the BIOS cold boot routine. ZCPR3 is small in general, depending, of course, upon the features you select. My "standard" ZCPR3 system which I use on the AMPRO in slave mode only interjects about 60K of overhead on disk, but the AMPRO acts only as a slave in this mode, providing screen display recording and (in the future) printer spooling. If used as a primary system will all of the bells and whistles of ZCPR3 enabled, around 200K of disk space on the system disk will be taken up by the tools. Whether you want ZCPR3 for a small system or not depends upon what you want to do with that system. ZCPR1 provided a minimum of features to make any CP/M system more livable. All (in most cases) COM files could be placed on disk A and B could be left blank for data and applications. ZCPR1 would search along a simple path each time a command was issued. ZCPR2 will also do this, as will ZCPR3. ZCPR1 offered a simple, fixed command-search path, ZCPR2 offered a more complex command-search path which could be dynamically changed by the user as he desires (the user could select search from $$ [current disk/user] to A$ [disk A/current user] to A0, etc), and ZCPR3 offers what ZCPR2 offered plus flow command packages (IF/ELSE/FI(Endif)), resident command packages, error handlers, and shells which can all be dynamically changed by the user at any time. With these additional features of ZCPR3 comes additional cost, with the worst cost being around 10K of additional disk overhead and 2 1/2K less TPA. The bottom line is that if your needs are simple (ie, "all I want to do is run dBASE II"), then ZCPR1 could be all you need. If your needs are or could grow into something more complex (ie, "I want command files which can do looping and IF-THEN-ELSE tests, MENU-driven front ends for applications environments, the ability to replace the command processor dynamically with another command processor (shell), and scripts which can expand into complex command streams from a simple command I issue"), then ZCPR2 is an intermediate step (with MENUs) and ZCPR3 is a more advanced step (with all the features mentioned above). ZCPR2, while it offered a lot of interesting features and capabilities, did so at some cost. A lot of the operating system overhead existed in the utilities themselves. ZCPR3 has utilities on the order of 1/2 to 1/3 the size of their ZCPR2 counterparts because almost all of the opsys overhead in the ZCPR2 utilities is now gone. In the phase 1 distribution, the largest utilities were 8K in size while most of them fell into the 4K or under range. This makes ZCPR3 more attractive than ZCPR2 for almost all types of systems. The smallest system I have seen ZCPR3 run on so far is the AMPRO Bookshelf. It has two 400K floppies, and the system overhead on the A drive, which includes my editors, communications software, and ZCPR3 tools (not all of them) still leaves about 200K free on the A drive and all 400K free on the B drive. With the new AMPRO Bookshelf coming out with two 800K floppies, I don't see a need to increase the system overhead at all. So, I hope this answers most of your questions. Your interest in I/O redirection is answered in the I/O packages of ZCPR3. These are packages which can be reloaded dynamically by the system and provide hosts of I/O drivers beyond what the CP/M I/O byte supports. In my main system, my prime I/O package supports 8 consoles (which are combinations of devices, like CRT and modem in parallel and CRT input with CRT and remote computer output for display recording), 6 printers, and two each of the readers and punches. It is NOT like UNIX I/O redirection (using < and > on the command line), but it can support similar functions. The standard question which is probably on your mind is if redirection to a disk file is possible. The answer is yes, but I am not happy with any of the solutions I have found except one, and I don't plan to give that one away. The heart of the problem is that the BDOS is not reentrant -- a routine which calls the BDOS, which in turn calls the BIOS, which in turn calls the BDOS for disk output will not work since the data from the first BDOS call will be lost. I am using a reentrant BDOS (still in testing) which will allow this, and, with this, disk I/O redirection can be done (especially with an I/O package doing the work). If this BDOS is released, however, a complete competator to CP/M will be out, and it would be tantamount to stabbing DR in the back, which I would hate to see happen, especially considering that without them, we wouldn't be in the world we are with CP/M and its clones, like MS-DOS. Note that all of the ZCPRs do not compete directly with DR since you still need the CP/M 2.2 BDOS to run them. The ZCPRs do cause competition with CP/M 3.0, but I don't feel that this is a problem since it is all in the family (one DR product vs another). Besides, we may someday see a CP/M 3.0-based ZCPR, and that would be that. Finally, a Z80 is required for ZCPR1 and ZCPR2 (altho Charlie Strom created ZC8080 from ZCPR2 which runs on 8080's). ZCPR3 runs best with a Z80, but a simple flag makes it run with 8080's as well. As a bottom line, from my perspective having the needs to use MENUs, shells, and aliases (scripts) with shell variables, I have moved over to ZCPR3 completely. My I/O redirection needs are met by the I/O packages (note that even with disk I/O redirection, I prefer using a slave machine [the AMPRO] to direct disk I/O because of some added flexibility I am discovering with this approach). And my applications needs with dBASE II, Word Star et al, MultiPlan, etc, are also met. Even when I have applications which need large amounts of TPA (the 48K TPA [out of 62K possible] I have under a full ZCPR3 is not enough), I have applications-oriented disks which I use which give the needed larger TPA. Rick 4-Jul-84 22:17:12-MDT,983;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 4 Jul 84 22:17:07-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 4 Jul 84 23:17 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 4 Jul 84 23:08 EDT Date: 4 July 1984 23:09-EDT From: Robert L. Plouffe Subject: MDM730 bug fix To: INFO-CPM@Mit-Mc.ARPA, INFO-MODEM7@Mit-Mc.ARPA PAT730 V8ASM is in AR101:FJW; at MIT-MC. The last patch in this file fixes a serious bug found by Ron Fowler that has been in the MDM series but not in previous versions of MODEM7. The bug is a file pointer error that can cause the 'next' directory entry to be erased instead of the desired on when overwriting files in batch mode. It is highly probable that this bug is also in MDM740, but I have not searched through the object code to find it, -nor will I. This again points out the necessity to keep the source code for public domain programs 'open'.. 4-Jul-84 22:31:07-MDT,15323;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 4 Jul 84 22:30:14-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 4 Jul 84 23:29 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 4 Jul 84 23:23 EDT Date: 4 July 1984 23:23-EDT From: Robert L. Plouffe Subject: pat730 v8asm To: INFO-MODEM7@Mit-Mc.ARPA cc: INFO-CPM@Mit-Mc.ARPA Here is the PAT730 V8ASM file for those that can't FTP: ; PAT730V8.ASM --Bob Plouffe 7/4/1984 ; THE CONDITIONAL ASSEMBLY EQUATES ARE DEFAULTED TO ; GIVE A PLAIN VANILLA MDM730 AS DISTRIBUTED, EXCEPT ; FOR CERTAIN CHANGES WHICH ARE CONSIDERED AS BUG FIXES. ; THESE ARE LISTED UNDER THE 'FIXED' EQUATE WHICH IS NOW ; ALWAYS TRUE. THE REMAINDER OF THESE PATCHES ARE OPTIONS. ; SET THEM AS YOU WISH FOR THE OPTIONS ALLOWED BELOW. ; V8 Fixed a bug found by Ron Fowler that causes the wrong ; file to be erased in the directory when overwriting existing ; files in batch mode. This bug has been in all the MDM series ; but not prior versions of generic MODEM7 -Bob Plouffe ; V7 Added Hoff fix for alternate long distance dialling ; and his fix for "DISK-FULL" when in ASCII capture mode. ; Removed code at CKSMLP that caused endless loop in batch ; mode with filenames that have checksum of 1AH, 0DH or 0AH. ; -Bob Plouffe ; V6 Added FIXFNK option to patch logon send routine to work right ; in 'half-duplex' (L) terminal mode ; Added LOCSTRT option to start terminal mode in 'half-duplex' ; (L) mode when connection made. This modification ; overrides the ONERING and NORING mods. It rings ; once, then jumps to local mode. -Ross Alford ;*********************************************************************** ;IMPORTANT: if FIXFNK is used, SAVE 74 rather than 73 after ; overlaying the patches ;*********************************************************************** ; V5 Added UNDO-J as an option. ; Corrected bug in SENDFN routine. ; Corrected bug in Irv's NORING option. - Bob Plouffe ;This patch overlay file will retain the capability to get ;progress reports at a remote-end that answers under BYE and ;when the "Q" switch is not used on the command line. ;Also changes the max-wait times at several locations ;including inside the receive-sector loop. This SUBSTANTIALLY ;improves performance on networks with packet delays. ;Suggest 16 seconds but not less than 5. ;Just assemble this file as an ASM file and overlay the HEX file ;on MDM730.COM with DDT and SAVE 73 MDM730.COM. If you have ;the source code, you should be able to locate the changes at ;the labels shown below. It is NOT INTENDED to change the ;revision number of MDM730 at this time. Treat this patch file ;as a customization just like when you use one of the patch ;overlays for a specific hardware configuration. ;This file also includes the Hoff patches for BELL and RUB ;and can be conditionally assembled for the way you want it. TRUE EQU 0FFH FALSE EQU 0 ;Setting LOCSTRT to true will make two modifications to MDM730: ; -it will perform the equivalent of the ONERING modification ; that appears elsewhere in this file ; -MDM730 will go into L terminal mode (local echo) rather ; than T terminal mode when a connection is made by an autodial ; modem. LOCSTRT EQU FALSE ;Set both of these bytes FALSE if you wish to have console bell ;continuously beep until a keyboard character is hit after doing ;a dial retry and a connection occurs. Set ONERING to TRUE if ;you want only one beep to occur and NORING to TRUE if you don't ;want any beeps at all. DON'T set both of these bytes to TRUE. ONERING EQU FALSE NORING EQU FALSE ; ; RUB2BKSP EQU TRUE ;want to convert RUB key to BKSPC? ; ;*********************************************************** ; ;To get rubout character to go to console set RUBCON to TRUE ;and IGNORCTL to FALSE. If you wish to have control chars ;filtered, then RUB will be filtered also. You can also set ;both of these to FALSE. TRUE/TRUE will filter control chars ;but will not feed RUB to console. RUBCON EQU FALSE ;want rubout to go to console? IGNORCTL EQU TRUE ;TRUE sets control character filter ; FIXED EQU TRUE ;Fix to directory pointer problem ;Fix to alt long distance dialling. ;Fix "DISK-FULL" problem in capture mode. ;(ALWAYS TRUE) ;Fix to remove endless loop with some ;filenames in batch mode. ;Fix to SENDFN routine so that if remote ;end is under BYE and 'Q' switch not set ;on command line, and if a file name begins ;with a 'C', the next file name is not ;aborted. Also provides a slight format ;improvement for the "Bad sector # in header" ;message. This is no longer a conditional ;equate and is always true. UNDO$J EQU FALSE ;Set to TRUE to restore the 'T' option and ;so that remote end doesn't automatically ;come up in terminal mode. (Unless remote is ;using MDM730 with this option set FALSE). MAXWAIT EQU 5 ;suggested value is 16 for packet networks ;which may exhibit excessive packet delays. FIXFNK EQU FALSE ;patch LOGLP logon transmit routine to echo ;to console in L mode, and not to wait so ;long between characters in L mode ;***NOTE that if you use this modification the ;size of MDM730.com must be increased to 74 pages ;when you save it*** BELL EQU 07H LF EQU 0AH CR EQU 0DH RUB EQU 7FH TERM EQU 1618H RETURN EQU 197EH EXITTEST EQU 1E79H SENDRDY EQU 1E41H WAITNLP EQU 2958H SENDACK EQU 18A4H GETACK EQU 2581H STAT EQU 2B88H TYPE EQU 2B9DH DIALAD2 EQU 0803H DIALEXIT EQU 0799H WREXIT EQU 2126H CLOS3 EQU 476CH WRERR0 EQU 0DC5H LOGLP EQU 1E5DH ;send logon message or fnk key LOGLP1 EQU 1E6DH ;get echo if T mode LOCFLG EQU 499BH ;set if L mode MFNAME6 EQU 4A9BH ;this +12 is start of stack area SPEED2 EQU 1A57H ;delay routine ;************************************************************* ; ;This restores the feature that allows the RUBOUT character to ;go to the console if you desire it. Code was added in MDM730 ;that prevented rubout being sent to console in terminal mode. ; ;In the routine TERML ORG 1F0FH IF RUBCON DB 0,0,0,0,0 ;deletes rubout filter ENDIF IF NOT RUBCON CPI RUB JZ TERM ENDIF ;At the IGNORCTL byte storage location ; IF IGNORCTL ORG 011DH DB 0FFH ;sets control character filter ENDIF IF NOT IGNORCTL ORG 011DH DB 0 ENDIF ; ;*********************************************************** ;In routine SENDC2 ORG 1782H MVI E,120 ;In routine SENDFN ORG 1BB2H DB 0,0 ; CALL GETACK CC SENDACK ;In routine ACKLP ORG 1BF3H MVI B,MAXWAIT ;In routine CKSMLP ORG 1C0CH MVI B,MAXWAIT ;In routine SCKSER ORG 1C56H MVI E,120 ;In routine NMLP1: ORG 1D03H MVI B,MAXWAIT ;In routine HSNAK ORG 1D51H MVI E,180 ; ;In routine HSNAK1 ORG 1D5FH MVI B,1 ;Yes, a 1 ORG 1E4AH ;Suggested by Irv Hoff to improve the ability to catch extra ;function key characters. SENDNOW CALL EXITTEST ;see if ready to quit now CALL SENDRDY ;ready to send a character? JNZ SENDNOW ;if not ready,wait some more RET ;exit if ready ;In routine RCVSOH ORG 240AH MVI B,MAXWAIT ; ORG 2413H MVI B,MAXWAIT ;At label RCVBSE ; ORG 242AH ;These 2 bytes replace CR,LF DB 80H,80H ;slight format improvement here for: ;'++ Bad record # in header ' ;In routine RCVCHR ORG 245EH MVI B,MAXWAIT ; ORG 2477H MVI B,MAXWAIT ;In routine RCVCRC2 ORG 2496H MVI B,MAXWAIT ;In routine WAITNLP ORG 2988H MVI B,1 ;yes, a 1 ; ;*********************************************************** ;THIS ONE CONTRIBUTED ANONYMOUSLY AS undo-j.asm AND INCLUDED ;HERE AS AN ADDITIONAL OPTION. ;To undo the 'J' option and restore the 'T' option as it has ;always been. Set UNDO$J to TRUE to enjoy this option. ORG 2AFBH IF UNDO$J DB 0C2H ENDIF ; IF NOT UNDO$J DB 0CAH ENDIF ORG 4952H IF UNDO$J DB 'T' ENDIF ; IF NOT UNDO$J DB 'J' ENDIF ORG 495FH IF UNDO$J DB 'T' ENDIF ; IF NOT UNDO$J DB 'J' ENDIF ;******************************************************************* ;The LOCSTRT patch ;(Starts in L mode after successful dial of phone) ;Overrides the ONERING and NORING patches below: ; result is equivalent to ONERING ; ORG 06EAH ;Same place as the ONERING mod ; IF LOCSTRT PUSH PSW ;save A reg MVI A,0FFH ;load FF into A to STA LOCFLG ;set LOCFLG for L mode POP PSW ;restore A JMP RETURN ;continue as in ONERING ENDIF ;LOCSTRT ; IF NOT LOCSTRT ;Restores original CALL STAT JZ 06F7H ;? CALL 2B93H ;? XRA A ENDIF ;NOT LOCSTRT ;********************************************************************* ;This patch removes code at CKSMLP which was intended to provide ;compatibility with older versions of MODEM7 only when used in batch ;mode and only when a remote is under 'BYE' and the 'Q' switch not set. ;Unfortunately, the incompatibility can't be resolved and the only ;penalty is that the 'Q' switch MUST be set at remote-under-BYE in ;batch mode if that end is an older version of MODEM7. The code ;that is herewith removed caused a problem when (in batch mode) filenames ;had a checksum of 1AH, 0DH or 0AH. It was possible to go into an ;endless loop. This patch cures that disease. ORG 1C11H DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 ;27 of them. ;Removes lines in CKSMLP routine beginning with ;CPI EOFCHR and ending with MVI A,LF inclusively. ;************************************************************************** ;The following patches are inserted into the LOGLP routine that ;sends the LOGON message and programmable function keys. A call is altered ;to point to the patch, which is located at the bottom of the stack area. ;This should be a fairly safe location in MDM730, which seems to have lots ;of stack space ; ORG LOGLP+9 IF FIXFNK ; CALL LPATCH ;replaces CALL LOGLP1 ; ORG MFNAME6+12 ;put the patch at start of stack LPATCH: MOV B,A ;save A in B LDA LOCFLG ;flag for L mode ORA A ;check if set JZ LOGLP1 ;not set-do normal stuff MOV A,B ;reclaim A CALL TYPE ;character -> console MVI C,01H ;delay a short while JMP SPEED2 ;and return ENDIF ;FIXFNK ; IF NOT FIXFNK CALL LOGLP1 ENDIF ;Not FIXFNK ;********************************************************************* ; ;Options below are by Irv Hoff modified for inclusion in this ;patch overlay file by Bob Plouffe: ; Some people have mentioned they are annoyed with the bell ringing ;constantly after a connect when auto-dialing with MDM730. The following ;two small changes will stop that: ; ;1) WILL ONLY RING ONE TIME then go to terminal mode after announcing it ; has connected: ;At CONMADE2 ORG 06EAH IF ONERING AND (NOT LOCSTRT) JMP RETURN ENDIF ; IF NOT (ONERING OR LOCSTRT) CALL STAT ENDIF ; ;2) WILL NOT RING AT ALL, but go right to terminal mode after announcing ; it has connected. ;In routine at CONMADE1 ORG 06E3H IF NORING AND (NOT LOCSTRT) DB 00 JMP RETURN ENDIF ; IF NOT NORING DB BELL,0 MVI B,5 ENDIF ; ; Several people were having trouble getting normal backspace with ;their rub (delete) key. MDM730 offers the option of changing rub to ;backspace. ; 1) Can preset the default option so rub comes up as backspace ; (or preset the default so it comes up as normal rub) ; 2) At any time use the menu option to change it temporarily ; to the opposite configuration. ; Some mainframes will not accept a normal backspace and require a ;rub (delete) character to provide a type of "forward backspace". If ;you need this feature and your terminal does not have a rub (delete) ;key, or if inconvenient to use, then set RUB2BKSP to TRUE ;In the routine TERM: IF RUB2BKSP ORG 1629H CPI 7FH ;RUB ; .... ORG 1635H MVI B,08H ;BCKSPC ENDIF IF NOT RUB2BKSP ORG 1629H CPI 08H ; .... ORG 1635H MVI B,7FH ENDIF ; (The menu will still indicate you are changing rub to backspace, ;ignore this statment and realize just the opposite is happening with ;this change.) - Irv Hoff ;----------------------------------------------------------------------- ; There are two obscure bugs in the MDM730 program. The first in- ; volves the alternate long distance dialing system - occasionally ; the last digit of the billing code would be entered twice, messing ; up the correct dialing. The second involves a problem existing ; since the early MODEM7 days which has never been corrected. When ; copying to disk in the terminal mode, if the disk fills, the pro- ; gram says it is saving as much of the copy as it can. It then ; closes the file - only it was closing the file normally used for ; file transfers. The following patch corrects both problems. As ; they only recently came to my attention, it is obvious the typical ; user (including me) has never run into either problem. ; -- Irv Hoff ; THIS IS THE ALTERNATE LONG DISTANCE DIALING CHANGE ; FOR 'SPRINT', 'MCI', ETC. USERS. ;in the routine at DIALAD2 ORG 806H JZ DIALAD3 ;same but DIALAD3 has a new address ORG 0DC0H BRIDGE: CALL TYPE ;patch added at this empty location POP H RET ;in DIALAD2 ORG 819H JNZ DIALAD2 POP H JMP DIALEXIT ; DIALAD3:MVI A,' ' MOV B,A JMP BRIDGE ;out of space here ; THIS IS THE CHANGE FOR "DISK-FULL WHEN IN ASCII ; CAPTURE MODE. EVERYBODY NEEDS THIS ONE. ORG 0DC5H WRERR0: CALL CLOS3 JMP WREXIT ;WREXIT label is at the call to ERXIT ;in the routine WRERR ;in the routine at WRTDSK2 ORG 210CH JNZ WRERR0 ;instead of JNZ WRERR ;in the routine at NOWRITE ORG 214EH CALL CLOS3 ;instead of CALL CLOSFIL. ;CLOS3 label is at the line LXI D,FCB3 ;in the WRTFIL1 routine ;This patch fixes a bug found by Ron Fowler that causes the wrong ;file to be erased in the directory when overwriting existing files ;in batch mode. ;in the routine at CKCPM2 ORG 2238H NOP ;These 2 bytes replace 'CPI 0FFH' INR A ;the END 5-Jul-84 06:58:12-MDT,617;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 5 Jul 84 06:58:07-MDT Received: From brl-vgr.arpa.ARPA by AMSAA via smtp; 5 Jul 84 8:31 EDT Received: from simtel20.arpa by BRL-VGR.ARPA id a004496; 5 Jul 84 8:25 EDT Date: Thu 5 Jul 84 06:21:17-MDT From: Jim Forrest Subject: BYE AND ANCHOR MARK XII To: INFO-CPM@BRL-VGR.ARPA cc: JFORREST@SIMTEL20.ARPA Has anyone been able to successfully run any version of BYE with a Signalman Anchor Mark XII ? I have been trying on a Kaypro 10 with no luck (refusal to answer). Jim ------- 5-Jul-84 07:52:00-MDT,974;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 5 Jul 84 07:51:53-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 5 Jul 84 9:21 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 5 Jul 84 9:18 EDT Received: from Usenet.uucp by sri-unix.uucp with rs232; 5 Jul 84 6:07-PDT Date: 2 Jul 84 7:07:11-PDT (Mon) To: info-cpm@Brl.arpa From: ihnp4!inuxc!inuxd!wolenty@Ucb-Vax.arpa Subject: 5.25 Disk Formats Article-I.D.: inuxd.570 I am trying to customize a CPM BIOS for an homebrew Z80 based system. I would like to know if anyone has suggestions as to what 5.25" SSDD disk format to use so that I might be able to order CPM sotware in a format familiar to distributors. Any suggestions would be welcome especially if detailed information such as number of sectors/track and number of bytes/sector is available. Ron Wolenty (ATT Consumer Products) Indianapolis, IN inuxd!wolenty 6-Jul-84 05:58:18-MDT,661;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 6 Jul 84 05:58:15-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 6 Jul 84 7:37 EDT Received: From ucla-locus.arpa.ARPA by BRL-AOS via smtp; 5 Jul 84 23:52 EDT Date: Thu, 5 Jul 84 20:06:28 PDT From: Jody Paul To: info-cpm@brl.arpa Subject: XLISP on SIMTEL20? (REQUEST) I thought I saw a message just a little while ago that said that XLISP was on SIMTEL20. If that's so, what directory is it in? If not, where can I locate the source? Thanks, Jody Paul jody@ucla-locus 6-Jul-84 06:47:07-MDT,2028;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 6 Jul 84 06:46:59-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 6 Jul 84 7:42 EDT Date: 5 Jul 1984 20:31 MDT (Thu) Message-ID: From: "Frank J. Wancho" To: INFO-CPM@Amsaa.ARPA Subject: CUG Software Tools Available Courtesy of Bernie Eiben, the CUG Software Tools collection is now available in MICRO: as a set of 12 .LBR files and a 13th SQueezed file containing the LDIR output of the 12. The current space crunch and the pending upload of several new SIG/M and PC-BLUE volumes prevent me from running DE-LBR on these files. Here's an extract of Bernie's original announcement: Based on RATFOR programs published in Software Tools by Brian Kerrighan and P.J. Plauger, published by Addison-Wesley in 1976. Updated and maintained by the Software Tools Users Group [CUG] - distributed on the "basic tape" or 12 floppies. Here they are in LBR-form and squeezed. SOFTTDIR.QQQ is a squeezed directory of all 12 of them - have fun [buy some floppies before You start..]. -------------------- Note that these files are BINARY, and thus do not have the ITS header. Filename Type Bytes Sectors CRC Directory MICRO: SOFTT-1.LBR.1 BINARY 118528 926 = 39EH 57BBH SOFTT-10.LBR.1 BINARY 106112 829 = 33DH 9B85H SOFTT-11.LBR.1 BINARY 133888 1046 = 416H 8830H SOFTT-12.LBR.1 BINARY 100480 785 = 311H 3875H SOFTT-2.LBR.1 BINARY 107904 843 = 34BH 9D40H SOFTT-3.LBR.1 BINARY 92160 720 = 2D0H A353H SOFTT-4.LBR.1 BINARY 102528 801 = 321H EC05H SOFTT-5.LBR.1 BINARY 86400 675 = 2A3H 2C10H SOFTT-6.LBR.1 BINARY 93824 733 = 2DDH 6194H SOFTT-7.LBR.1 BINARY 140544 1098 = 44AH A36FH SOFTT-8.LBR.1 BINARY 114432 894 = 37EH B4D0H SOFTT-9.LBR.1 BINARY 119936 937 = 3A9H 300EH SOFTTDIR.QQQ.1 BINARY 4608 36 = 24H 6291H --Frank 6-Jul-84 07:56:14-MDT,855;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 6 Jul 84 07:56:10-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 6 Jul 84 9:30 EDT Received: From xerox.arpa.ARPA by BRL-AOS via smtp; 6 Jul 84 9:24 EDT Received: from GreeneKing.ms by ArpaGateway.ms ; 06 JUL 84 06:23:52 PDT Date: 6 Jul 84 14:19:04+0100 (Friday) From: Hirst.rx@XEROX.ARPA Subject: Re: 5.25 Disk Formats In-reply-to: ihnp4!inuxc!inuxd!wolenty's message of 2 Jul 84 7:07:11 PDT (Mon) To: ihnp4!inuxc!inuxd!wolenty@UCB-VAX.ARPA cc: info-cpm@BRL.ARPA The format that I would suggest if you are using 40 tracks is; 256 bytes per sector 17 sectors per track 3 reserved tracks 155K bytes disk capacity The data architecture could be to an IBM system 34 format or modified as per Xerox Hope this helps//Ken 6-Jul-84 14:31:55-MDT,632;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 6 Jul 84 14:31:45-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 6 Jul 84 16:04 EDT Received: From crdc.arpa.ARPA by BRL-AOS via smtp; 6 Jul 84 15:53 EDT Date: Fri, 6 Jul 84 15:37:23 EDT From: George R. Famini To: info-vax-request@Sri-Kl.ARPA, info-micro-request@Brl-Aos.ARPA, info-cpm@Brl-Aos.ARPA Subject: userid change Our Vax seems to be functioning now... please change my userid in the mailing lists from famini@amsaa to grfamini@crdc. Thanks.... George Famini 7-Jul-84 11:50:27-MDT,536;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 7 Jul 84 11:50:23-MDT Received: From mit-mc.arpa.ARPA by AMSAA via smtp; 7 Jul 84 13:30 EDT Date: 7 July 1984 04:47-EDT From: Jerry E. Pournelle Subject: ? OMNIET i/f for S-100 To: Cargo@Hi-Multics.ARPA cc: info-cpm@Amsaa.ARPA In-reply-to: Msg of Tue 3 Jul 84 12:18 CDT from David S. Cargo yes. Corvus has an S-100 imninet as well as for PC apple and their own corvus concept 7-Jul-84 13:17:01-MDT,1873;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 7 Jul 84 13:16:53-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 7 Jul 84 14:54 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 7 Jul 84 14:43 EDT Date: 7 Jul 1984 12:43 MDT (Sat) Message-ID: From: Richard Conn To: info-cpm@Brl-Aos.ARPA Subject: ZCPR3 Phase 1 Being Received I received a phone call from Steve Leon at SIG/M this morning, and SIG/M has now received ZCPR3 Phase 1. It will be released starting at Volume 184. All CRCs of all files check out. Frank Wancho at White Sands has also received the Phase 1 distribution, and Frank plans to upload it to SIMTEL20 soon. Will let you know when it is available. I have been receiving several reports from Silicon Valley on ZCPR3 progress, and all have been favorable. People are getting the system up without too much difficulty (especially if they have ZCPR2 knowledge already), and absolutely no bugs have been reported. The beta testing seems to have been quite successful. The ZCPR3 Phase 2 effort is coming along quite nicely, with everything coming up. DU3, with its new screen-oriented editor, and VFILER are complete now. I am working on VMENU, which is a cross between VFILER and MENU, allowing the user to point to a file in the file display and invoke a menu command on that file. All of these utilities are screen-oriented, using highlighting, clear screen, cursor addressing, etc, and they port very easily between ZCPR3 systems, with a simple installation via the Z3INS routine being all that is necessary to do the port. To say the least, with ZCPR3 now we have the CP/M transportability concept extended to include screen-oriented utilities. Will keep you posted. Rick 8-Jul-84 00:50:11-MDT,1471;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 8 Jul 84 00:50:05-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 8 Jul 84 2:29 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 8 Jul 84 2:26 EDT Date: 8 July 1984 02:25-EDT From: Paul L. Kelley Subject: movcpm synchronization errors To: abn.iscams@Usc-Isid.ARPA cc: INFO-CPM@Mit-Mc.ARPA BDOS jump checking in MOVCPM. LXI B,STORAGE ;MOVCPM has already read the presumed address ;of the running BDOS from 0006 and stored it ;away LDAX B ;get least significant byte of running BDOS ;address CPI 6 ;is it really BDOS or perhaps DDT? MVI A,0 ;get ready to put the address of the running ;serial number in STORAGE JNZ SYNCERR ;give synchronization error if not the correct ;BDOS address modulo a page STAX B ;STORAGE now has address of start of running ;serial number Serial number checking in MOVCPM. LXI D,MOVCPM$SERNO ;location of serial number in MOVCPM's ;relocatable version of BDOS. This is at ;the start of the relocatable BDOS. LHLD STORAGE ;get the address of the running serial number MVI C,6 ;length of serial number LOOP: LDAX D ;compare MOVCPM's serial number with CMP M ;running BDOS's serial number JNZ SYNCERR ;give synchronization error if CMP fails INX H ;check INX D ; all DCR C ; six JNZ LOOP ; bytes 8-Jul-84 02:43:12-MDT,1421;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 8 Jul 84 02:43:07-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 8 Jul 84 4:11 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 8 Jul 84 4:02 EDT Received: from Usenet.uucp by sri-unix.uucp with rs232; 7 Jul 84 1:14-PDT Date: 5 Jul 84 13:24:19-PDT (Thu) To: info-cpm@Brl.arpa From: hplabs!sdcrdcf!sdcsvax!sdccs6!ix255@Ucb-Vax.arpa Subject: Big Board II - Take 2 Article-I.D.: sdccs6.1588 I am looking into the purchase of a Big Board II from CalTex computers of San Jose. { (408) 942 1424 } The price of an A&T board just dropped to $550. The board supports 5.25" and 8" drives, single/double density, has a terminal chip which emulates a Lear Seagler ADM 31, four par. ports, two serial ports, two CTCs and 64k of RAM (60k available to user) Considering I could get the board, and CP/M 2.2 for $700. It seems to be a very good deal. Anyone have any good or bad experiences with it? Where can I get decent drives, power supplies, and keyboards to go with it. Caltex mentioned a place called Halted in San Jose. Anyone ever dealt with this company. Thanks again. John Antypas U.C. San Diego UUCP: ...!sdcsvax!sdccs6!ix255 arpanet: sdcsvax!sdccs6!ix255@Berkeley 8-Jul-84 02:43:34-MDT,771;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 8 Jul 84 02:43:30-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 8 Jul 84 4:11 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 8 Jul 84 4:03 EDT Received: from Usenet.uucp by sri-unix.uucp with rs232; 7 Jul 84 1:25-PDT Date: 5 Jul 84 5:15:56-PDT (Thu) To: info-cpm@Brl.arpa From: hplabs!sdcrdcf!sdcsvax!akgua!rnm@Ucb-Vax.arpa Subject: Dobbs Screen Editor Documentation Article-I.D.: akgua.867 Now that I have a copy of the Dobbs screen editor, it sure would be nice to get a little direction on how to use it. I suppose it would be best to post lengthy stuff to net.sources. Thanks in Advance <-<-<-<-<-<-< 8-Jul-84 02:44:18-MDT,2292;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 8 Jul 84 02:44:12-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 8 Jul 84 4:12 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 8 Jul 84 4:06 EDT Received: from Usenet.uucp by sri-unix.uucp with rs232; 7 Jul 84 3:21-PDT Date: 5 Jul 84 6:10:40-PDT (Thu) To: info-cpm@Brl.arpa From: ihnp4!mgnetp!burl!pmh@Ucb-Vax.arpa Subject: National 8250 initialization routine needed Article-I.D.: burl.490 -- Well, I've gotten the terminal emulator to work on my h-89, but I'm still having problems with my downloading routine. Is there anyone out there who can verify that I'm setting my I/O up correctly? I have my modem on a port that I have initialized for 8 bits no parity at 300 baud. I am not using an interrupt driven routine so the interrupt enable register is zeroed out. To determine if data is present I test the DATA READY bit in the line status register. I guess what I really need (assuming all the previously mentioned parameters are correct) is for someone to explain the Christiansen Protocol. I am able to retrieve 1 record of data from an RCPM, but subsequent records get trashed. HELP!! What I need to know is: 1. What is the actual length of each transfer (including checksum, etc)? 2. What handshaking signals are necessary and when? 3. Any other pertinent info. Presently, to start the transfer, I send a NAK and after each 128 byte record received, I send an ACK. I've set up the software to return the RCPM's EOT with one of it's own. If anyone has a working modem program on a Heath H-89, please let me know. I'll mail you a disk if you can copy it for me. I'd like to get my program running, but that's not the foremost consideration if I can procure an already operating one. My dilemma is that I'm still using hard-sectored disks. I've had people offer me stuff in the past, but alas, my machine can't read it because they only use sft sectored disks. Again HELP! Thanks in advance. -- >From the non-linear mind of a non-anonymous hacker!! Pete Hermsen ihnp4! \ PO Box 2304 akgua! \burl!pmh Burlington, NC 27216 cornell! / (919) 228-4215 (w) ulysses!/ "Not all roads lead to Hollywood..." 8-Jul-84 15:38:21-MDT,847;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 8 Jul 84 15:38:17-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 8 Jul 84 17:13 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 8 Jul 84 17:11 EDT Received: from Usenet.uucp by sri-unix.uucp with rs232; 7 Jul 84 7:05-PDT Date: 6 Jul 84 7:23:16-PDT (Fri) To: info-cpm@Brl.arpa From: hplabs!sdcrdcf!sdcsvax!akgua!psuvax1!burdvax!droms@Ucb-Vax.arpa Subject: Xerox 820-I clearinghouse/mailing list/bulletin board system Article-I.D.: burdvax.1591 Does anyone know of any information clearinghouses dedicated to the Xerox 820-I system? If not, and there is sufficient interest, I'm willing to start a mailing list. Please reply by mail if you'd be interested in exchanging 820-specific information. - Ralph Droms 9-Jul-84 00:21:46-MDT,1498;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 9 Jul 84 00:21:40-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 9 Jul 84 1:52 EDT Date: 8 Jul 1984 23:53 MDT (Sun) Message-ID: From: "Frank J. Wancho" To: INFO-CPM@Amsaa.ARPA Subject: MICRO: Reloaded The files in the subject directory have been reloaded due to problems with the original uploaded files. My thanks to those who discovered the problems and reported the situation. If problems are discovered with any files in MICRO:, , , or , let me know. Note: as many of you who are able to use FTP to SIMTEL20 have discovered, the use of CWD (Change Working Directory) does NOT work with the ANONYMOUS FTP Login. Please don't bother to try it until you see an announcement from me that something has been worked out. After going through three disk controllers and associated software, I have (finally!) been able to transfer Rick's 10 ZCPR3 and 4 SYSLIB3 8" disks to N* format, and all CRCs match! The disks are now ready to be uploaded and should be available before the weekend. Look for another announcement. (Anybody have a *working* CCS2422 Rev B driver for TurboDOS 1.22 or 1.3 that doesn't generate memory parity errors, or know why a DJDMA Rev 3B decides it can only read double density disks under CP/M 2.2, contact me.) --Frank 9-Jul-84 10:03:57-MDT,1205;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 9 Jul 84 10:03:47-MDT Received: From ucb-vax.arpa.ARPA by AMSAA via smtp; 9 Jul 84 11:28 EDT Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA09487; Mon, 9 Jul 84 08:29:12 pdt Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by ucbjade.CC.Berkeley.ARPA (4.14/4.20) id AA06771; Mon, 9 Jul 84 08:28:55 pdt Received: by ucbpopuli.CC.Berkeley.ARPA (4.14.3/4.20) id AA14724; Mon, 9 Jul 84 08:28:46 pdt Message-Id: <8407091528.AA14724@ucbpopuli.CC.Berkeley.ARPA> Mailed-From: Bitnet-site Boston University (IBM 3081-D VM/SP(MP)) Return-Path: Date: 9-Jul-84 From: John Sutter Subject: Superbrain... To: info-cpm@Amsaa.ARPA ------ I have a Superbrain and an ATR8000. My secretary uses the Superbrain for Wordstar. What I would like to do is use some small utility so that I could hack over what she did on the Superbrain with Wordstar on my ATR8000... If anyone has any ideas, or utilities!!!, I would really appreciate it... ---- John ------ 9-Jul-84 12:01:33-MDT,11516;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 9 Jul 84 12:01:00-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 9 Jul 84 13:07 EDT Received: From amsaa.arpa.ARPA by BRL-AOS via smtp; 9 Jul 84 12:59 EDT Date: Mon, 9 Jul 84 12:53:31 EDT From: David Towson (CSD) To: Jody Paul cc: info-cpm@brl.arpa Subject: Re: XLISP on SIMTEL20? (REQUEST) Jody - Here is a collection of messages pertaining to XLISP. Please let me know if you successfully obtain a copy, and how. Dave towson@amsaa.arpa Received: From Brl-Bmd.ARPA by AMSAA via smtp; 1 Jan 84 22:57 EST Date: Sun, 1 Jan 84 22:43:51 EST From: Paul Broome To: BRINT cc: steve@brl-bmd, broome@brl-bmd, howard@brl-bmd, towson@amsaa Subject: Re: XLISP Here's a message on XLISP I had filed away long ago. It sounds very interesting; it's theme is object oriented programming in LISP. Since he referred to the book LISP by Winston and Horn in building it, it'll look like MACLISP. Can you pick up a copy to run under UNIX also? -p -------------  Date: 18 Mar 83 17:48:51-PST (Fri) To: info-micro@brl.arpa From: David Betz Subject: New XLISP release Article-I.D.: decvax.441 Received: from Usenet.uucp by SRI-Unix.uucp with rs232; 19 Mar 83 0:03-PST Received: From Sri-Unix.ARPA via smtptcp; 19 Mar 83 3:10 EST Received: From Brl.ARPA via smtptcp; 19 Mar 83 10:33 EST Received: From Brl-Bmd.ARPA via smtptcp; 19 Mar 83 10:42 EST Received: From Brl.ARPA via smtptcp; 19 Mar 83 10:48 EST XLISP: An Experimental Object Oriented Language Page 1 XLISP is an experimental programming language combining some of the features of LISP with an object oriented extension capability. It was implemented to allow experimentation with object oriented programming on small computers. There are currently implementations running on the PDP-11 under RSX, RT-11, and UNIX-V7, on the VAX-11 under VAX/VMS and Berkeley VAX/UNIX and on the Z-80 running CP/M-80 (the CP/M version was compiled using the AZTEC C compiler). It is completely written in the programming language 'C' and is believed to be easily extended with user written builtin functions and classes. It is available in source form free of charge and is in the public domain. Many traditional LISP functions are built into XLISP. In addition, XLISP defines the object classes 'Object', 'Class', and 'Keymap' as primitives. 'Object' is the only class that has no superclass and hence is the root of the class heirarchy. 'Class' is the class of which all classes are instances (it is the only object that is an instance of itself). 'Keymap' is a class whose instances are mappings from input key sequences to messages. This version of XLISP is much improved over the version that I submitted to net.sources a while ago. The code has been cleaned up to allow it to compile without errors under Berkley UNIX (actually there is still one warning message generated having something to do with a zero length structure member, but it can be ignored). The functions with names that parallel LISP function names actually work the same as their counterparts in LISP (my source for information on 'real' LISP was the book 'LISP', by Patrick Henry Winston and Berthold Klaus Paul Horn, published by Addison Wesley). The keymap functions have gone away in favor of a 'Keymap' class that implements the same functionality. The internal representation of objects has changed such that objects now take about half the space that they took before. I have introduced an 'Object' class that is at the top of the class heirarchy and provides some useful default messages like 'isnew' so that you don't have to provide an 'isnew' message for a class whose instances don't need initialization. I hope to resubmit XLISP to net.sources sometime in the next few weeks. If anyone is interested in a version of XLISP to run on Z-80s under CP/M-80, contact me directly as there were some changes to the sources necessary to get it to compile under the AZTEC C compiler (by the way, I have had very good luck with the AZTEC C compiler. It is sold by MANX software systems in Shrewsbury, NJ) XLISP is available from: David Betz 114 Davenport Ave. Manchester, NH 03103 XLISP: An Experimental Object Oriented Language Page 2 home: (603) 625-4691 work: (603) 881-2188 usenet: decvax!betz XLISP: An Experimental Object Oriented Language Page 3 Classes and Messages: Object isnew default initialization message print default print message show default show message class return the class of an object sendsuper send an object's superclass a message Class new create a new instance isnew initialize a new class ivars define the instance variables cvars define the class variables answer define a method for a message Keymap isnew initialize a new keymap instance key define a key mapping process process input using the keymap The LISP functions included with XLISP are: List functions: car cdr cons cond atom eq list append null listp equal read reverse length nth print princ set setq eval quote defun I/O functions: fopen fclose getc putc fgets fputs String functions: strcat strlen substr ascii chr atoi itoa Arithmetic functions: + - * / % & | ~ min max abs Boolean functions: && || ! Relational functions: < <= == != >= > Control functions: if while foreach exit Utility functions: load mem gc alloc expand  Received: From Brl-Bmd.ARPA by AMSAA via smtp; 5 Jan 84 12:35 EST Date: Thu, 5 Jan 84 12:31:19 EST From: BRINT To: towson@amsaa Subject: [betz: Re: XLISP] Dave, What is SIG/M? Can we easily get software from them? Brint ----- Forwarded message # 1: Received: From Ucb-Vax.ARPA by BRL-BMD via smtp; 5 Jan 84 11:59 EST Received: by UCB-VAX.ARPA (4.22/4.18) id AA01905; Thu, 5 Jan 84 08:59:28 pst Received: by decvax.UUCP (4.12/4.13) id AA16492; Thu, 5 Jan 84 10:33:22 est Date: Thu, 5 Jan 84 10:33:22 est From: decvax!betz@Berkeley (David Betz) Message-Id: <8401051533.AA16492@decvax.UUCP> To: decvax!betz@Berkeley, abc@brl-bmd.ARPA Subject: Re: XLISP You can now order XLISP from SIG/M. I'm not sure what the volume number is for it. You can also get it from DECUS. It comes in CP/M format from SIG/M and RT-11 format from DECUS. I have recompiled the same source code for VMS, UNIX V7 and Berkeley UNIX as well as CP/M-80. You also might be interested to know that I have a new LISP interpreter called OBLISP. It fixes some of the problems that XLISP had as well as being somewhat more compatible with 'real' LISP. It still supports object oriented programming. It also has a builtin function called 'prove' that is a simple prolog style theorm prover. Actually it is just a C implementation of a program called PIL that was distributed over the NET a while ago. I will be submitting this new version of LISP to Dr. Dobbs Journal soon. I will also be sending it to SIG/M. I am sorry to say that I am no longer accepting floppy disks sent directly to me. I had too much trouble with people sending the wrong kind of floppies or not enough return postage, etc. I was thinking of making the software available for a small fee (like $25) with the understanding that once you ordered a copy, you could make as many copies as you wanted and give them to your friends. The software really is in the public domain. I just don't know of a good way of distributing it. David Betz P.S. What are you planning on doing with XLISP/OBLISP? ----- End of forwarded messages Received: From Brl-Bmd.ARPA by AMSAA via smtp; 27 Dec 83 19:59 EST Date: Tue, 27 Dec 83 19:49:36 EST From: BRINT To: steve@brl-bmd, broome@brl-bmd, howard@brl-bmd cc: towson@amsaa Subject: XLISP Do any of you know anything about XLISP (se following)? Is this public domain? Is it anything like Pure Lisp, Franx, or MAC? I suppose the floppy is to be an 8" variety. Brint ? Date: 28 Apr 83 10:52:46-PDT (Thu) To: info-micro@brl.arpa From: David Betz Subject: New distribution policy for XLISP Article-I.D.: decvax.524 Received: from Usenet.uucp by SRI-Unix.uucp with rs232; 29 Apr 83 1:34-PDT I have received a large number of requests from people who have not received parts of the last XLISP distribution. For a while I was honoring requests to send individuals the files that they were missing. Then, when that became unreasonable due to the number of requests, I reposted several of the original files. Even then I got requests from people who hadn't gotten either the original version or the redistributed version. Because of all of this I have decided that net.sources isn't a reliable way of distributing a program as large as XLISP. Rather than replying to each of the people who sent me mail, I am sending this news article to explain my next plan for distributing XLISP. Would anyone who wants a copy of XLISP please send me a stamped, self addressed SSSD floppy at the following address: David Betz Digital Equipment Corporation 110 Spit Brook Rd. Nashua, NH 03062 Please specify whether you want the disk in CP/M format, RT-11 format, VMS format, or UNIX (tar) format. I'm sorry about this being a less than convienient form of distribution, but I don't think that its fair to the rest of the users of the network to continue sending the large XLISP distribution files over and over again just so that the few people who didn't receive them correctly the first time can have another chance. David Betz decvax!betz Received: From Brl-Vgr.ARPA by AMSAA via smtp; 3 Feb 84 14:12 EST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 3 Feb 84 14:08 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 3 Feb 84 14:03 EST Received: from ISL by SUMEX-AIM with Pup; Fri 3 Feb 84 11:03:05-PST Date: Friday, 3 Feb 1984 11:02-PST To: info-micro@brl Subject: xlisp Reply-to: kevinw@su-dsn From: kevinw@su-dsn Sender: kevinw%isl@BRL.ARPA has anyone had any success with xlisp from simtel-20? i downloaded it and the checksums verified but i can't get it to run under unix after recompiling and the canned version has bombed two different machines running cpm (z80 and 8085). it sounds like a great program but if it doesn't work... thanks for any assistance, -- Kevin kevinw@su-dsn 9-Jul-84 13:59:25-MDT,668;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 9 Jul 84 13:59:20-MDT Date: Mon, 9 Jul 84 15:25:11 EDT From: David Towson (CSD) To: Paul L. Kelley cc: info-cpm@Amsaa.ARPA Subject: Re: movcpm synchronization errors Paul - Thanks for posting the nice disassembly of the serial number checker portion of MOVCPM. That should help those who get into some of the more unusual hacks, such as David Kirschbaum did. My Omikron CP/M for the TRS-80 was legally bought and paid for, but came without MOVCPM. I don't know why. Dave towson@amsaa.arpa 9-Jul-84 15:06:53-MDT,687;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 9 Jul 84 15:06:47-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 9 Jul 84 16:33 EDT Received: From darcom-hq.arpa.ARPA by BRL-AOS via smtp; 9 Jul 84 16:23 EDT Date: Mon, 9 Jul 84 16:24:54 EDT From: Rturner@darcom-hq.arpa To: info-cpm%brl.arpa@darcom-hq.arpa Subject: KAYPRO Terminal Emulators?? Has anyone run into a public domain emulator for the VT-100 terminal that runs on the Kaypro II or 4? In a pinch, I could go for a commercial version if the price is not outrageous. Please respond to me to keep from over-burdening this list. thanks, rick 9-Jul-84 20:16:33-MDT,756;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 9 Jul 84 20:16:25-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 9 Jul 84 21:54 EDT Received: From xerox.arpa.ARPA by BRL-AOS via smtp; 9 Jul 84 21:50 EDT Received: from CheninBlanc.ms by ArpaGateway.ms ; 09 JUL 84 18:46:40 PDT Date: Mon, 9 Jul 84 18:46 PDT From: LShilkoff.ES@XEROX.ARPA Subject: Re: Xerox 820-I clearinghouse/mailing list/bulletin board system In-reply-to: "hplabs!sdcrdcf!sdcsvax!akgua!psuvax1!burdvax!droms@UCB-VAX.ARPA's message of 6 Jul 84 7:23:16 PDT (Fri)" To: hplabs!sdcrdcf!sdcsvax!akgua!psuvax1!burdvax!droms@UCB-VAX.ARPA cc: info-cpm@BRL.ARPA Here's one vote for your 820 mailing list. Larry Shilkoff 10-Jul-84 05:53:26-MDT,5275;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 10 Jul 84 05:53:12-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 10 Jul 84 6:59 EDT Date: 10 Jul 1984 05:00 MDT (Tue) Message-ID: Sender: KPETERSEN@Simtel20.ARPA From: Keith Petersen To: Info-Cpm@Amsaa.ARPA Subject: Cold boot initialization for Kaypro-10 Relayed from RCPM Royal Oak: ----- J. Steele 7-6-84 COLD BOOT INITIALIZATION K10 CPM 2.2 F Purpose: KAYPRO, in it's corporate wisdom decided to go for the most common IO configuration which is 300 baud on the serial ports and using the parallel printer. Those who don't do this, and especially those who use a variety of customized CP/M's have to use CONFIG or a special boot-up routine to overcome the Kaypro scheme. The following technique avoids this problem once and for all plus you learn a few added things about the "inner" secrets of the Kaypro BIOS. (It might be easier on Kaypro to release the BIOS and let the hackers have at it. No telling what good things might be done.) ---------------------------------------------------------------------------- On the COLD BOOT the IO byte and the baud ports are initialized from high memory locations which means we can get to them for our own needs. o The initial IO byte is loaded from EA33h o The initial Printer Baud is loaded from EA48h o " " Modem " " " " EA47h -------------------------------------------------------------------------- These locations are on either side of the cursor-keypad table which makes them very easy to find and change with EDFILE to eliminate continual use of the (barf) CONFIG program. +-> This is the IO byte +----> Modem Bd | +>cursor <+ +--> keypad table here <---------------+ | +-> Printer Bd | | keys | | | | | 81 00 0B 0A 08 0C 30 31 32 33 34 35 36 37 38 39 2D 2C 0D 2E 05 05 ^ v <- ->| 0 1 2 3 4 5 6 7 8 9 - , EN .| up dn lf rt| keypad face values for above bytes | -------------------------------------------------------------------------- Changing the values with the EDFILE disk editor (any will do that can find a string in the file) >EDFILE PUTSYS.COM (whatever putsys you are using) S \123456\ (search for the string "123456" This will put you in the sector and you can edit the appropriate bytes as you desire. Consult the KAYPRO manual for baud rates and any good CPM text for a discussion of the IO byte. -------------------------------------------------------------------------- The IO byte is comes stock set to 81h which enables the Parallel Printer and can be set for the serial printer by changing it to 01h. Don't make any other changes as the PUNCH and READER don't care and if you set the CONSOLE to 0 it will bring the system up looking to the PRINTER port for keyboard-screen. Nice, though if you use the K10 with a "real" terminal. Both the MODEM and PRINTER baud come in set at 300 baud which is 05h. I set the printer to 07h as I use a 1200 baud serial printer. (an OKI that has a parallel port but is two feet too far from the box and I can make a long RS232 cable a heck of a lot cheaper than a Centronics) Note that at the same time, you can alter the initial values of the cursor keys and the keypad. The keypad keys can be changed directly to a single byte value or by changing the desired key to 00h you may then make up to a 4 byte value in the table which follows this stuff. Best to do what you want with config first, use DDT to look at the area and then make the final edit with EDFILE or another disk file editor. (I am assuming this isn't compu-garbage talk to you, but if it is, then you need the experience of learning a bit more before you hack up the main software of the machine) When you have made your changes, just run the PUTSYS (or whatever) and reboot from a RESET. If the computer chokes, try again. I suggest you work on RENamed copies of PUTSYS.COM to avoid junking your on disk backup. These bytes only affect the COLD boot from power-up or reset so any later finagling you do with Config, Stat, or Whatzit.com will be on your head. The only r-e-a-l bad thing you can do playing around with the BIOS would be to accidentally call on the ROM monitor to junk up a disk area. This doesn't even go close. (Ask me about the time a WS went bonkers and dumped a file on the directory tracks - Real soon after, KAYPRO gave me a brand new main board, HD controller and a new Hdisk that worked right. That was before the bean counters started adding up the cost of in-the-field fixes on THEIR engineering errors. They've stopped being so nice now, but Lord help you with the first versions of the Western Digital board. The big expensive chips roast out and KAYPRO only stocks assemblies, not replacement chips. $210 in exchange cost to the dealer. Ask me how I know!!) THAT'S ALL FOLKS !!!!! PS: Works just fine with ZCPR2 for the K-10. Enjoy! 10-Jul-84 18:46:23-MDT,1079;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 10 Jul 84 18:46:16-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 10 Jul 84 20:23 EDT Date: 10 Jul 1984 18:23 MDT (Tue) Message-ID: Sender: KPETERSEN@Simtel20.ARPA From: Keith Petersen To: David Towson (CSD) Cc: Info-Cpm@Amsaa.ARPA Subject: [towson: Cold boot initialization for Kaypro-10] Date: Tuesday, 10 July 1984 06:44-MDT From: David Towson (CSD) To: Keith Petersen Re: Cold boot initialization for Kaypro-10 Keith - This message has some really good stuff for those with an interest (which doesn't, at this moment, include me). Have you any plans for stashing this goodie in the archives? I know it will be in the info-cpm message archive, but one would have to know it was there to go looking for it. Yes, I put it in MICRO:KP-CBOOT.DOC on SIMTEL20. --Keith 10-Jul-84 23:06:20-MDT,847;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 10 Jul 84 23:06:14-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 11 Jul 84 0:40 EDT Received: From xerox.arpa.ARPA by BRL-AOS via smtp; 11 Jul 84 0:34 EDT Received: from Muscat.ms by ArpaGateway.ms ; 10 JUL 84 05:36:11 PDT Date: 10 Jul 84 08:34:32 EDT (Tuesday) Subject: Re: Xerox 820-I clearinghouse/mailing list/bulletin board system In-reply-to: hplabs!sdcrdcf!sdcsvax!akgua!psuvax1!burdvax!droms' message of 6 Jul 84 7:23:16 PDT (Fri) To: hplabs!sdcrdcf!sdcsvax!akgua!psuvax1!burdvax!droms@UCB-VAX.ARPA cc: info-cpm@BRL.ARPA From: Jeff I beleive that there is probably a fairly large community of people within Xerox that would be interested in participating. I'd like to see it setup. Jeff 11-Jul-84 03:30:30-MDT,1258;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 11 Jul 84 03:30:21-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 11 Jul 84 5:09 EDT Received: From xerox.arpa.ARPA by BRL-AOS via smtp; 11 Jul 84 5:08 EDT Received: from GreeneKing.ms by ArpaGateway.ms ; 11 JUL 84 02:06:24 PDT Date: 11 Jul 84 10:01:10+0100 (Wednesday) From: Hirst.rx@XEROX.ARPA Subject: CBBS for CP/M To: pencin.dlos@XEROX.ARPA, Jim Forrest cc: info-cpm@BRL.ARPA, Hirst.rx@XEROX.ARPA Russ & Jim, The full address is Randy Suess 5219 West Warwick Chicago Illinios 60641 You can obtain this software (2 or 3 S/S S/D 8" disks) from any SYSOP using CBBS, but payment should still be made to Randy ($50). You can of course dial into this first CBBS at (312) 543-8086 For those of you who are not aware, CBBS is written in 8080 code, is assembled with the Public domain LINKASM (~25K), has significant help files, supports messages and binary transfer and contains flags for a variety of applications. My version even supports private messages. CBBS was originally written by Ward C & Randy. //Ken ---------------------------------------------------------------- 11-Jul-84 06:46:57-MDT,919;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 11 Jul 84 06:46:50-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 11 Jul 84 8:16 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 11 Jul 84 8:08 EDT Date: 11 Jul 1984 06:08 MDT (Wed) Message-ID: From: Richard Conn To: info-cpm@Brl-Aos.ARPA Cc: rconn@Simtel20.ARPA Subject: ZCPR3 and SYSLIB3 on SIMTEL20 Thanks to the efforts of Frank Wancho at White Sands, all ten ZCPR3 disks and four SYSLIB3 disks are now on SIMTEL20. All files have been verified. They are located in MICRO: and MICRO:, and they are stored in ITS binary format. The anonymous login convention can be used to access these files. Thanks again, Frank, for the effort you expended in putting the files on the system. Rick 11-Jul-84 07:38:18-MDT,4700;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 11 Jul 84 07:38:04-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 11 Jul 84 9:09 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 11 Jul 84 9:01 EDT Date: 11 Jul 1984 07:00 MDT (Wed) Message-ID: From: Richard Conn To: info-cpm@Brl-Aos.ARPA Subject: ZCPR3 Phase 1 complete All recipients of ZCPR3 Phase 1 are now distributing the software. SIG/M remote distribution sites (sites away from the main SIG/M organization in NJ) could still be waiting for receipt of the disks from SIG/M HQ, but that is the only further delay I can see now. For those of you who want to acquire ZCPR3, your alternatives are many: 1. you can order disks thru SIG/M 2. you can transfer files from your local BBS if it has them (I've been told that several large BBSs in CA have it online now [perhaps sans all the source files]) 3. you can transfer files from SIMTEL20 if you are on the DDN 4. the San Diego Computer Society has a full set 5. the disks are available within XEROX and will soon be available within DEC 6. Echelon is distributing the disks in a variety of formats (8", Kaypro, Osborne) [all formats are uninstalled at this time] and Echelon includes hardcopy of the installation manual and user's perspective 7. ZCPR3 is included in sales of the Ampro Little Board and Ampro Bookshelf computers In a discussion with Frank Gaude of Echelon last night, Frank mentioned that over 700 disks have gone out so far in various combinations (basic ZCPR3 core, SYSLIB3, full set of 14 disks, etc). I have been getting reports back from the field thru Echelon, and people seem to be happy, bringing the system up, and no bugs have been reported yet. ---- What's Next? ---- 1. ZCPR3 Phase 2 is moving along quite smoothly. DU3, VFILER, and VMENU are now done, and they all run very efficiently in the ZCPR3 environment. I will be completing documentation on VMENU tonight and probably putting the final touches on MU3 as well. Once MU3 is done, it will be the last of the major Phase 2 utilities. All Phase 2 utilities will then go out for beta testing. I plan to review the system overall, fill in what minor functions I feel are necessary which I may have missed, complete the documentation on Z3LIB (VLIB is already done), get the beta test results and correct bugs reported, and then release [DO NOT ask me when -- I'll let you know]. 2. With the utilities done [or at least very nearly so], I can complete the ZCPR3 book and then the SYSLIB3/Z3LIB/VLIB book. I hope to send drafts out to various editors in a few days. My contract with the publisher [NY Zoetrope] calls for delivery of the first full draft by 1 Aug, and I think that not only will this deadline be met, but the draft they will see will be very close to the final draft. Once they start going, they claim the book will be out within a month! This we will have to see. 3. Echelon has been addressing the problem of ZCPR3 installation for some time now, and they now have working, unrefined prototypes of an automatically-installing ZCPR3 system. The concept is simple: too many people do not have source to their BIOS [political commentary -- boo, hiss, on the manufacturers] and even if they did, many would find the effort to bring up ZCPR3 to be extreme. For these reasons, Echelon is working on a version of ZCPR3 that installs itself with a simple command that can be issued at cold boot. I feel that the best possible ZCPR3 installation is done with BIOS modification, but this should be the next best thing to it. I don't know for sure if the project will succeed in terms of a generic CP/M [Echelon may have to provide specific versions for the Kaypro, Osborne, etc], but it does look hopeful at this time. Of course, Echelon does intend to sell this, but the cost should be minor. I'll let you know when this project is complete [which should be Real Soon Now (where have I heard THAT before???)]. 4. More and more interest is developing in ZCPR3 [political commentary -- no, most of the 1.5M CP/M 2.2 users are NOT out on a limb now -- new things are coming out for them], and I've been interviewed for three articles by various people so far. Also, if you want to hear some words about the Ampro and ZCPR3 from someone other than me, the latest issue of User's Guide contains a review of the Ampro which includes some coverage of ZCPR3. Several articles (and the book) should be coming out in the months to come. Rick 11-Jul-84 10:10:36-MDT,749;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 11 Jul 84 10:10:31-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 11 Jul 84 11:45 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 11 Jul 84 11:42 EDT Date: Wed, 11 Jul 84 9:08:29 EDT From: Manny Crivello Subject: ALS GSX-80 GRAPHICS + CPM-PLUS UPGRADE FOR APPLE To: info-cpm@mit-mc.arpa ALS has finlly came out with GSX-80 graphic package for there CPM-PLUS , plus they upgraded there CPM-PLUS to 3.01B2. I also heard that they also upgraded there toolkit. I recived my GSX-80 + CPM-PLUS UPGRADE kit yeserday, so I haven't played with to much yet,but, it does seem to much nicer. M.D.Crivello 12-Jul-84 05:19:16-MDT,3363;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 12 Jul 84 05:19:06-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 12 Jul 84 6:48 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 12 Jul 84 6:38 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 12 Jul 84 3:34-PDT Date: 9 Jul 84 7:05:51-PDT (Mon) To: info-cpm@Brl.arpa From: ihnp4!ihuxq!covert@Ucb-Vax.arpa Subject: Irv Hoff's side of the MDM7xx story Article-I.D.: ihuxq.1053 <> A while ago I posted a query on how Irv Hoff could sell the mdm740 program after it has been in the public domain for so long. Most people seem to agree that legally Irv can sell it as he has made his own original alterations to it. After this message was posted I conacted Ward Christensen (the original author of the mdm7xx programs) and asked for his opinion. The following message is Ward Christensen's ideas (and do not reflect mine): __________________________ Msg 23035 is 20 line(s) on 07/03/84 from WARD CHRISTENSEN to RICHARD COVERT re: IRV HOFF/COPYRIGHT/MDM7XX Irv has no intention of selling MDM7xx. This whole thing is blown out of proportion. Like so many rumors ABOUT someone - no one thought to go back to the "source" (Irv himself). I have now had "many K-char" of dialog w/Irv on CompuServe, and all pleasnat and understanding. Like me copyrighting CBBS and Resource (the latter more relevant because its "in the public domain" - (an admitted inconsistency)) Irv worked VERY HARD to make MDM7xxx available for a WIDE variety of machines. Inevitably, with his VAST erperience customizing MODEM (much more than mine) he got frustrated like I did with people who tack on inconsistent or worse yet, "buggy" bells and whistles, that aren't in the general interest with his ideas. Thus, just as I don't distribute the source for RESOURCE, he stopped distributing MDMxxx source - so he'd not have to fight the "someone else puts something in, he takes it back out" battle. This would allow him to concentrate on getting new overlay files out for more modems, more systems, and stop "fighting brush fires" of people "hacking" the code. I see nothing wrong with what he has done; he plans to eventually re-release source; PS: He thinks MEX came to be as another way to release, could be (I have nothing bas and have heard much good about MEX, too). ___________________________________ My own feelings about not releasing source to a program being distributing to the hobbyist market is that if the author doesn't provide the source then he OWNS it to the community to provide support for his program. For example, I wrote a 8080-z80 translator for which I distributed only the object file (copyrighted by myself) for use by CP/Mers. I promptly fixed any bugs in my program and released it. It has worked fine for me as I am up to release 4.1 now. It does appear that Irv has provided support for mdm7xx in the form of bug fixes. What he has not done is to implement changes as suggested by others.. I feel that it is hard to corrdinate such a program amongst many different programmers. Oh well, I hope that this helps clear up any misunderstandings about Irv's intentions with MDM7xx.. -- Richard Covert AT&T Bell Laboratories ...ihnp4!ihuxq!covert (312) 979-7488 12-Jul-84 08:17:02-MDT,1127;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 12 Jul 84 08:16:57-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 12 Jul 84 9:42 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 12 Jul 84 9:41 EDT Date: 12 Jul 1984 07:41 MDT (Thu) Message-ID: From: Richard Conn To: rturner@Darcom-Hq.ARPA Cc: info-cpm@Brl-Aos.ARPA, info-unix@Brl-Aos.ARPA Subject: ITS-to-Normal and Normal-to-ITS File Conversion Rick, In response to your message, I created a pair of tools to use under UNIX (the design is so simple that I believe they will port to virtually any UNIX - they all have putchar and getchar, right?). The tools are in MICRO: and they are: itstonorm.c convert ITS format files to normal format normtoits.c convert normal format files to ITS itstonorm.man doc (rename to itstonorm.1 under UNIX) normtoits.man doc (rename to normtoits.1 under UNIX) I tested them on an ITS binary file from the MICRO: archive, and they ran nicely. Enjoy! Rick 12-Jul-84 08:17:26-MDT,3100;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 12 Jul 84 08:17:17-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 12 Jul 84 9:41 EDT Date: 12 Jul 1984 07:41 MDT (Thu) Message-ID: Sender: KPETERSEN@Simtel20.ARPA From: Keith Petersen To: Info-Cpm@Amsaa.ARPA Subject: MEX review - MEX-RVW.TXT Relayed from RCPM Royal Oak... THIS FILE IS A BRIEF REVIEW OF MEX10, AND CONTAINS A FEW HINTS DERIVED FROM TRIAL AND ERROR EXPERIMENTATION...... MEX10 is yet another modem program....and for those using MDM7, there arises the question "What does MEX offer that MDM7 doesn't already have, or that you don't need anyway?" There is a great deal of truth there, but as a dedicated MDM7 user, I offer the following comments after just a few days of using MEX. First, I'm already convinced that MEX is the most powerful modem program I've come across. MDM7 is excellent, but doesn't begin to offer the power and flexibility that MEX offers. Probably the most exciting area is the dynamic ability to change program paramaters very easily in real time, and command line processing with simple command files. As an example (very simple), the following one line file (much like a submit file) will with a single command entry (get FILE.QQQ), do the following: MEX] A0>>GET FILE.QQQ ;entered command MEX] A0>>SENDOUT XMODEM S FILE.QQQ ;MEX sends out request (WAITS FOR REPLY) ;remote system responds (XMODEM...etc) MEX] A0>>R FILE.QQQ ;MEX sets up receive (TRANSFERS FILE) B0> ;back to remote system!!! Here is the one line file that does all this (GET.MEX): SENDOUT "XMODEM S {1}";R {1} Those who have used submit files will appreciate the parameters {n}. A file for transfering library member files is just slightly more complicated. MEX] A0>>GETL NAME.LBR NAME.MBR ;Single command (the name GETL is ;arbitrary..and is filename that ;contains the following text) SENDOUT "XMODEM L {1} {2}";*R {2} ;MEX command file These command files can be used for many purposes, and can change operating parameters for particular systems called (even such things as parity, stop bits, etc for particular systems). All this flexibility is not without its price, however! As is always the case, increased power and flexibility also leads to increased complexity. Thats a polite way of saying that MEX is not for the beginner. The array of commands and variables under the control of the operator in real time is more than a little overwhelming at first. Also, there are many people who will never need all the power and flexibility offered, and will find the much simpler to use MDM7 satisfies all their needs. MEX is of most value to those who need its greatly increased power for non-typical uses (main-frame com., etc) or those who will enjoy the use of a "sports car" and the programming challenge it offers. Just one man's opinion..... Norman Beeler Sunnyvale, Ca 12-Jul-84 08:41:43-MDT,8261;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 12 Jul 84 08:41:21-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 12 Jul 84 9:43 EDT Date: 12 Jul 1984 07:44 MDT (Thu) Message-ID: Sender: KPETERSEN@Simtel20.ARPA From: Keith Petersen To: Info-Cpm@Amsaa.ARPA Subject: MEX files - MEXFILES.INF Relayed from RCPM Royal Oak... SOME NOTES ON MEX FILES by Irv Block Richard Holmes has suggested that a listing of my MEX files with an explanation of how they work might be useful to others picking their way through Ron Fowler's marvelously programmable communications package, MEX. So here goes... What is so extraordinary about MEX is its ability to edit and tailor itself to the user's particular needs. One of the features that demonstrate this capacity is the way MEX uses ***.mex files. MEX will read any FILENAME.MEX as a "SUBMIT" file and execute the lines as commands; and it can do this either at your manual direction or automatically. You can tell MEX to read a FILENAME.MEX file by typing on the MEX command prompt A0>>READ FILENAME (you can eliminate the .ext, since the program assumes the .ext to be .MEX) Or, even better, you can eliminate the "READ" instruction and have MEX assume that any name it doesn't recognize as a built-in command is the name of a .MEX file and should be read and performed. Thus, simply typing A0>>FILENAME will dispatch MEX on its obedient course. This makes for very fast and fluid performance of a lot of tasks to make communications easier and quicker. The way you program MEX to do its "automatic read" number is with a STAT command: A0>>STAT EXTEND ON A0>>CLONE NEWMEX.COM (or any other name, even the same) The clone is now ready to do your bidding, and the following description of my .MEX files (probably crude to some of you) will give some idea of what this program can do. They can all be extended and improved. ----------------- INI.MEX INI.MEX is the .MEX file MEX automatically looks for on starting up, whether you tell it to or not. You can disable this feature with "STAT INITFILE OFF" but you'd be making a mistake. Use it. My INI.MEX, written with a text editor (I keep the economical TED.COM on the same disk to facilitate instant writing and editing of .MEX files) goes like this: LOAD KEYS.KEY LOAD PHONE.PHN B:^M TYPE A:T.NOT [NOTE: YOU CAN ALSO WRITE THESE COMMANDS ON A SINGLE LINE, SEPARATED BY SEMICOLONS. BUT GIVING EACH COMMAND ITS OWN LINE, I THINK, MAKES IT EASIER EDIT THE FILE LATER] On automatically reading this file, then, MEX will perform the following tasks before getting itself ready to receive your further commands: 1) It will load KEYS.KEY, the file that contains my keystrings (First Name, Last Name, Passwords, Logoff, etc.) These keystrings, of course, can be written into the file either with a text editor or with MEX itself. Type HELP KEY for full instructions. By using MEX's "SAVE KEYS.KEY" command you can write your keystrings and updates to a file. You can "CLONE" the keystrings, too, but that occupies space in MEX and makes it necessary for you to redo the process each time you make a new clone. By having your strings in a KEYS.KEY file and having MEX automatically load it, you can maintain and edit your set of keystrings independently. 2) Mex will then load your PHONE.PHN, your library of phone numbers that you 'SAVE'ed. (SEE HELP PHONE). All the points made above with reference to keystrings apply equally to this file. 3) On reading the third line, MEX will log you onto Drive B, where I assume your uploading disk will be. My A drive, containing the disk with MEX and assorted associated goodies for editing and managing uploaded and download material, is pretty full. Forgetting where I'm logged and trying to upload a long file on Drive A by error can be a disgusting experience. 4) Finally, reading the last line, MEX will type out my file T.NOT. That file reads like this: ***************************************** IRV, REMEMBER TO SET UP A 'CAPTURE' FILE! ***************************************** And that is what pops up on my screen (all in the space of a second or two -- MEX is fast) after bringing up MEX. For me, it's a good reminder. I have a habit of remembering to set up a capture file only after what I want to copy has already scrolled by on its way north. --------------- GET.MEX GET.MEX reads like this: WRT SENDOUT "XMODEM S {1} RT {1} If I type "GET ANYFILE" on the MEX command line, MEX will first WRT the capture file, if there is one, to the disk. (If you don't WRT the capture file before R or S, you'll lose it) It will then send "XMODEM S ANYFILE" to the host, wait for a reply and then go into MEX's command mode to give the order "RT ANYFILE" When the transfer it completed I'll be left in the Terminal mode, which in this case is where I want to be. ALL THIS UNATTENDED, WHILE YOU FILE YOUR NAILS OR GO FOR COFFEE. MAIN ADVANTAGE IS ACCURACY, THOUGH, AND SPEED IN TRANSFERING. --------------- GETBYE.MEX My GETBYE.MEX goes like this: WRT SENDOUT "XMODEM S {1} R {1} SENDOUT "BYE ^M" Invoked by "GETBYE ANYFILE.TYP" this will do the same as GET.MEX but go to the command mode after the transfer in order to send the "BYE" command (you can't send sendout commands in anything but the command mode--it took me some frustrating hours to realize this). In other words, it automatically logs off. --------------- GETLIB.MEX This one reads as follows: WRT SENDOUT "XMODEM L {1} {2} RT {2} Invoked by GETLIB ANYFILE THISFILE.DOC, it will download the member THISFILE.DOC from ANYFILE.LBR. --------------- SEND.MEX SEND.MEX is just like GET.MEX except that the R's and S's are transposed, since the purpose of "SEND ANYFILE.TYP" is to send a file to the host rather than receive one. --------------- Q.MEX is invoked simply by typing "Q" at the command line. It reads like this: STAT REPLY 0 SENDOUT "ATM0^M" STAT REPLY 8 The critical instruction is the second line, which instructs the Smartmodem to shut down its speaker. Nice when lines are busy and you are going into continuous redialing. The first and third lines of this file shut off the echoing and waiting in this process, making it virtually instantaneous and neat -- but restore the normal parameters at completion of the order. --------------- Z.MEX is just like Q.MEX except that the second line reads SENDOUT "ATZ^M" restoring the Smartmodem to its normal chatty mode. --------------- ADDENDUM: Two other STAT adjustments will make all the above operate more smoothly. CLONE these into your version of MEX -- or include them in your INI.MEX file. STAT SEARCH 2 ALT A0 The first of these, STAT SEARCH 2, sets up a search path that orders MEX to look first on the default drive for .MEX files you indicate and then, failing to find them there, to search the "Alternate" drive. The second command sets the alternate drive to be A0, which is right for me, since I am usually logged on B. Depending on your system, ALT could be anything. The combination thus searches both drives, relieving you of the bother of remembering which file is on which drive--a kind of internal ZCPR. I do hope this exercise will turn out to be useful, perhaps instigate an exchange of more imaginative .MEX files. Mex is dynamically programmable and there may be as many different ways of programming it as there are users. - Irv Block Sea Cliff, NY June 7, 1984 12-Jul-84 18:00:49-MDT,1276;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 12 Jul 84 18:00:40-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 12 Jul 84 19:38 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 12 Jul 84 19:30 EDT Received: by UCB-VAX.ARPA (4.28/4.31) id AA16557; Thu, 12 Jul 84 16:26:52 pdt From: ihnp4!lznv!lzpa!rbr@Ucb-Vax.ARPA Date: 12 Jul 84 18:17:16 CDT (Thu) Message-Id: <8407122317.AA08510@ihnp4.ATT.UUCP> Received: by ihnp4.ATT.UUCP; id AA08510; 12 Jul 84 18:17:16 CDT (Thu) Subject: Mailing list Apparently-To: ucbvax!C70:info-cpm Dear fa.info-cpm editor, I am an employee of AT&T Information Systems in Lincroft N.J. and would like to be added to the mailing list for this digest. My vital statistics are: Name: Robert R. Barbato Company: AT&T Information Systems USnail address: 307 Middletown-Lincroft Rd Lincroft, N.J. 07738 E-mail address: ihnp4!lznv!rbr If I have sent this request to the wrong place could you please 1) forward to the guilty, if possible 2) failing that, send me some mail so I know my request has not been ignored. I don't have access to Netnews, so this is my only hope to receive the digest. Thanks. Bob Barbato Cc: rbr 13-Jul-84 02:29:35-MDT,1013;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 13 Jul 84 02:29:29-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 13 Jul 84 3:59 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 13 Jul 84 3:49 EDT Date: 13 July 1984 03:48-EDT From: Jerry E. Pournelle Subject: S1 & NCC To: INFO-CPM@Mit-Mc.ARPA, INFO-MICRO@Mit-Mc.ARPA There was a very large ad for t he "S1" Operating System in teh Conventino Daily at NCC. If S1 was anywhere at NCC or anyone actually spoke about it, I did not see it. The Ad was a two page spread, that was cleverly designed to look as if it were a smaller advertisement surrounded by serious review text (interview with the promoter of S1). Has ANYONE seen S1 on ANY machine whatsoever? I have seen nothng but paper, leaving me with the impression that s1 OS is vaporware; and here and there I get a whiff of something else... ANY EVIDENCE of existence of S1 would be appreciated. 13-Jul-84 07:24:44-MDT,1302;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 13 Jul 84 07:24:37-MDT Received: From mitre.arpa.ARPA by AMSAA via smtp; 13 Jul 84 8:58 EDT Date: 13 Jul 1984 8:41:37 EDT (Friday) From: Jeffrey Edelheit Subject: Re: S1 & NCC In-Reply-to: Your message of 13 July 1984 03:48-EDT To: Jerry E. Pournelle Cc: info-cpm@Amsaa.ARPA Jerry - I don't know if the S1 outfit you are referring to is Multi Solutions Inc. of Lawrenceville, NJ. If it is, I have noticed that they have advertised in Computerworld for over 6 months, running adverts saying "UNIX is a dinosaur, CP/M & MS-DOS are toys......" and "S1 is the only operating system worthy of the title 'the next world standard'". I don't know if S1 is vaproware, but I am pretty sure that I would not want to deal with anyone who would place such arrogant adverts. I would have to wonder how they would treat me as a customer. Furthermore, after watching the trials & tribulations of Dick Pick, I personally have doubts about any OS that doesn't have the support of either a large installed base (e.g., CP/M, MS-DOS) or a developer who has some significant size behind it (e.g. AT&T and UNIX). Jeff Edelheit (edelheit at mitre) 14-Jul-84 03:04:25-MDT,1608;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 14 Jul 84 03:04:18-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 14 Jul 84 4:30 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 14 Jul 84 4:29 EDT Date: 14 Jul 1984 02:27 MDT (Sat) Message-ID: From: Richard Conn To: Dick Cc: info-cpm@Brl-Aos.ARPA Subject: ZCPR3's ZEX.COM In-reply-to: Msg of 14 Jul 1984 00:36-MDT from Dick Dick, ZEX.COM is usable as distributed ONLY if you have the same memory configuration I do -- particularly in terms of the location of ZCPR3 command processor and the Environment Descriptor. This is the memory configuration which is on the distribution header files (Z3BASE.LIB and Z3HDR.LIB). Yes, the documentation shows ZEX building a new ZEX. If you do not have ZEX, EX (by Ron Fowler) can be used instead. Also, RELS.UTL is quite useful in creating ZEX, and that is in MICRO: on SIMTEL20. I'll see if I can put together a LBR file for the Phase 2 distribution which contains a toolset for building ZEX without first having ZEX. In the meantime, if you are in a hurry, remember that ZEX is just a command file processor, so the command sequence shown in ZEX can be typed in manually - that is how I was thinking that users would first bring it up, but I forgot to say that. I hope this clears up the matter. The book will elaborate on such items, of course, but that does not help for now. Rick 14-Jul-84 03:15:12-MDT,1353;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 14 Jul 84 03:15:06-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 14 Jul 84 4:40 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 14 Jul 84 4:32 EDT Date: 14 Jul 1984 02:32 MDT (Sat) Message-ID: From: Richard Conn To: info-cpm@Brl-Aos.ARPA Subject: [DKozinn: ZCPR3 distribution] FYI -- Rick Date: Friday, 13 July 1984 00:17-MDT From: David Kozinn Reply-To: DKozinn%pco at CISL-SERVICE-MULTICS.ARPA To: RCONN at SIMTEL20.ARPA cc: CSTROM at BRL-BMD.ARPA Re: ZCPR3 distribution Hi Rick. I just thought that I'd let you know that we now have most, if not all of the .COM files, the manuals, the .LIB files, and a large number of the .ASM files for ZCPR3 in the CP/M Special Interest Group on CompuServe, CP-MIG in XA 6 (database section 6) for people to download as they please. I thought you might like to mention this the next time you send out one of your status reports. In case you're not familiar, Charlie Strom, Tom Jorgenson and I are the 3 Co-sysops of this special interest group, and there are no fees for downloading any of our software other than the normal CompuServe connect-time charges. 14-Jul-84 13:11:59-MDT,2271;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 14 Jul 84 13:11:51-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 14 Jul 84 14:54 EDT Date: 14 Jul 1984 12:55 MDT (Sat) Message-ID: Sender: KPETERSEN@Simtel20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: [brutlag: KERMIT ON TELENET] This may help MODEM7 users who are accessing hosts via TELENET. --Keith Date: Sunday, 17 June 1984 21:53-MDT From: Doug Brutlag To: Info-Kermit at MIT-MC, cc.fdc at COLUMBIA-20.ARPA, Re: KERMIT ON TELENET Frank, Another way to get KERMIT to transfer files on TELENET is to configure TELENET to transmit the eighth bit. Most TELENET nodes are set up for 7 bit communications only. You can set up eight bit mode, by connecting to your host, then escape back to TELENET (with cr @ cr) and giving the command: SET? 0:33,63:0 The 0:33 parameter allows you to set certain ITI parameters normally not used by TELENET users. The ITI parameter 63 enables the eighth bit when set to 0 (contrary to what is written in the TELENET documentation by the way). I have found this setting useful for both KERMIT file transfers and for using a terminal with a META key for setting the eighth bit for EMACS editing commands. If this fails you should call the TELENET 800 number to find out how to allow eight bit communications for your node. SOme nodes use old TELENET protocols which require setting parameter 57:1 as well. If you have many people using KERMIT via TELENET you can have your TELENET representative change your local node to make the default setting of parameter 63 be 0. By the way I do not encourage people to use KERMIT via TELENET because of the delay in receiving the ACK/NAK. Even with an unloaded network and 1200 baud nodes at either end, the delay in receiving the ACK/NAK effectively lowers the transmission speed from 1200 baud to less than 300 baud. Doug Brutlag [Ed. Note - We will try to work out a "sliding window" option for the Kermit protocol over the summer. This should speed things up a bit, assuming it can be widely implemented.] 14-Jul-84 19:57:00-MDT,640;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 14 Jul 84 19:56:56-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 14 Jul 84 21:30 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 14 Jul 84 21:28 EDT Date: Sat 14 Jul 84 19:28:24-MDT From: Jim Forrest Subject: Can anyone help - info on LD80 ? To: INFO-CPM@BRL-AOS.ARPA cc: JFORREST@SIMTEL20.ARPA I have a program just above the limit of my memory for L80 and someone told me there is an LD80 that does a disk link. Can anyone tell me where it can be obtained, if it exists? Jim ------- 14-Jul-84 23:51:26-MDT,1173;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 14 Jul 84 23:51:20-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 15 Jul 84 1:30 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 15 Jul 84 1:29 EDT Date: 14 Jul 1984 23:29 MDT (Sat) Message-ID: From: Richard Conn To: info-cpm@Brl-Aos.ARPA Subject: Assembling ZEX Dick Mead brought up the problem of using ZEX to assemble ZEX the other day. If your memory configuration is not the same as mine, the ZEX.COM distributed with ZCPR3 will not work. If this is the case, you have two options: to manually enter all of the command lines indicated in the installation manual or to use EX to execute the ZEX.ZEX command file. I just tried it, and EX runs perfectly with it. You have to rename ZEX.ZEX to ZEX.SUB to get EX to use it, and it runs with the simple command: EX ZEX Of course, you still need RELS.UTL to put everything together with SID or ZSID. Both EX.COM (and EX.HEX) and RELS.UTL (and RELS.HEX) are available to the public in MICRO:. Rick 15-Jul-84 00:52:52-MDT,1397;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 00:52:47-MDT Received: From ucb-vax.arpa.ARPA by AMSAA via smtp; 15 Jul 84 2:23 EDT Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA26152; Sat, 14 Jul 84 23:24:50 pdt Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.14/4.22) id AA19637; Sat, 14 Jul 84 23:25:00 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.22) id AA21457; Sat, 14 Jul 84 23:24:42 pdt Date: Sat, 14 Jul 84 23:24:42 pdt From: William C. Wells Message-Id: <8407150624.AA21457@ucbopal.CC.Berkeley.ARPA> To: info-cpm@amsaa.ARPA Subject: CP/M Plus (CP/M 3.0) Software I am trying to identify commercial and public domain software that runs under CP/M Plus. Most lists of software only list programs for CP/M 8080/Z80 as CP/M-80. However, not all CP/M software can handle CP/M Plus disk directories (with time stamps turned on). If you are running CP/M 3.0 or later on a Z80 or Z80A I would like to hear about what software you have found to work. I am also interested in software that takes advantage of the CP/M Plus banked memory. Bill Wells wcwells@Berkeley.ARPA ucbvax!wcwells WCWELLS@UCBJADE.BITNET P.S. I am running a PMC Micromate with CP/M 3.0 and 128K banked memory. 15-Jul-84 01:12:01-MDT,1392;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 01:11:55-MDT Received: From ucb-vax.arpa.ARPA by AMSAA via smtp; 15 Jul 84 2:46 EDT Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA26318; Sat, 14 Jul 84 23:47:44 pdt Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.14/4.22) id AA19701; Sat, 14 Jul 84 23:47:55 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.22) id AA21646; Sat, 14 Jul 84 23:47:36 pdt Date: Sat, 14 Jul 84 23:47:36 pdt From: William C. Wells Message-Id: <8407150647.AA21646@ucbopal.CC.Berkeley.ARPA> To: info-cpm@amsaa.ARPA Subject: PMC Micromate 101 / TRIOS Micro Systems, Inc. The PMC Micromate 101 is now being sold and distributed by TRIOS Micro Systems, Inc. 147 Beacon Street South San Francisco, CA 94080 TRIOS say they will provide user support for the Micromate. Among other things they will have a annual service agreement for their Micromate owners which includes swapping a bad Micromate for a good one. They also plan to offer a RAM disk for the Micromate and to start a newsletter for Micromate users. For more information, contact Kathleen M. Czimber at (415) 583-7733. Bill Wells wcwells@Berkeley.ARPA ucbvax!wcwells WCWELLS@UCBJADE.BITNET 15-Jul-84 09:38:51-MDT,901;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 09:38:46-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 15 Jul 84 11:12 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 15 Jul 84 11:06 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 15 Jul 84 8:00-PDT Date: 13 Jul 84 19:36:33-PDT (Fri) To: info-cpm@Brl.arpa From: hplabs!sdcrdcf!sdcsvax!sdccs6!ir320@Ucb-Vax.arpa Subject: Need a copy of the MODEM7(30/40,etc.) overlay M7AQ-2.ASM Article-I.D.: sdccs6.1618 HELP! I need a copy of the modem7 overlay M7AQ-2.ASM. I have a PCPI card and the Micromodem ][. I know other programs exist, but mine are so old, I am beginning to hate them. Any help would be appreciated. Thanks John Antypas UC San Diego UUCP: ...!sdcsvax!sdccs6!ir320 arpanet: sdcsvax!sdccs6!ir320@Berkeley 15-Jul-84 10:46:58-MDT,1438;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 10:46:51-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 15 Jul 84 12:23 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 15 Jul 84 12:23 EDT Date: 15 Jul 1984 10:23 MDT (Sun) Message-ID: From: Richard Conn To: info-cpm@Brl-Aos.ARPA, info-unix@Brl-Aos.ARPA Subject: GET20 David Towson (towson@amsaa) has contributed an excellent tool called "GET20" -- it is now in the MICRO: directory on SIMTEL20 in the files AUTOFTP.DOC (documentation), GET20. (Bourne shell script), and BEHEAD.C (utility source). For those UNIX systems on the DDN, GET20 provides a very convenient way to transfer masses of files from SIMTEL20 with ease. For instance, the command get20 -a unix unix.crclst transfers (as ASCII) the file UNIX.CRCLST from the MICRO: directory on SIMTEL20 to a file of the same name in your current directory. Likewise, the command get20 -8 cpm.zcpr3 *.com transfers (as 8-bit binary, automatically reformatting all ITS-binary files to their normal format) all *.COM files in MICRO:. David reports that he transferred all 185 files in MICRO: in one command as a batch job when he was not logged in. I've tried it, and I really feel it is an excellent tool. Rick 15-Jul-84 18:18:09-MDT,779;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 18:18:05-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 15 Jul 84 19:47 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 15 Jul 84 19:41 EDT Date: Sun, 15 Jul 84 19:44:00 EDT From: Dave Farber To: Jerry E. Pournelle cc: INFO-CPM@mit-mc.ARPA, INFO-MICRO@mit-mc.ARPA Subject: Re: S1 & NCC I asked the S1 people why there was no system at NCC and they mumbled something about not having a machine they could spare from their development schedule. Sounded weak. I am driving up there soon and will report. Hope they are not as invisible as is Venix and Coherent are on support. 15-Jul-84 20:14:34-MDT,843;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 20:14:28-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 15 Jul 84 21:51 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 15 Jul 84 21:51 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 15 Jul 84 18:42-PDT Date: 6 Jul 84 10:03:40-PDT (Fri) To: info-cpm@Brl.arpa From: hplabs!tektronix!uw-beaver!cornell!vax135!ukc!west44!kbrown@Ucb-Vax.arpa Subject: Red editor posting in net.sources (at last!!) Article-I.D.: west44.256 The dobbs screen editor that I offered a while ago has been posted to net.sources. Have fun, Keith B. -- "Specialist subject, the bleedin' obvious!!" Keith Brown ....!ukc!west44!kbrown ( And other leading Usenet paths ) 15-Jul-84 20:17:50-MDT,1094;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 20:17:36-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 15 Jul 84 21:51 EDT Received: From rand-unix.arpa.ARPA by BRL-AOS via smtp; 15 Jul 84 21:46 EDT Received: from vortex.UUCP by rand-unix.ARPA; Sun, 15 Jul 84 18:26:39 pdt Date: Sun, 15-Jul-84 18:05:47 PDT From: Lauren Weinstein Subject: Coherent, etc. Message-Id: <8407151805.2486.2.VT3.3@vortex.UUCP> To: farber@Udel-Ee.ARPA Cc: info-micro@Brl-Aos.ARPA, info-cpm@Brl-Aos.ARPA I don't know who you've been talking to (I can't vouch for random OEM's and such) but I've been dealing with Mark Williams Co. (who make Coherent) in Chicago for a long time regarding Coherent, and I've seen no evidence of any support problems. In fact, I get frequent reports from people who are impressed at how willing they are to deal with strange situations and non-standard sorts of problems. You can even reach them over the UUCP net; contact me if you want some addresses. --Lauren-- 15-Jul-84 21:32:18-MDT,650;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 21:32:12-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 15 Jul 84 23:11 EDT Date: 15 Jul 1984 21:12 MDT (Sun) Message-ID: From: "Frank J. Wancho" To: INFO-CPM@Amsaa.ARPA Subject: Damaged ZCPR3 file replaced MICRO:HELP.MAC was discovered to be damaged, and replaced this afternoon at about 13:45 MDT. If you grabbed the file prior to that time, please get it again. All ZCPR3 files have been reverified. Sorry for any inconvenience. --Frank 15-Jul-84 22:32:04-MDT,658;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 22:31:59-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 15 Jul 84 23:57 EDT Date: 15 Jul 1984 21:58 MDT (Sun) Message-ID: From: "Frank J. Wancho" To: INFO-CPM@Amsaa.ARPA Subject: More SIG/M Volumes Available MICRO: has been replaced with a new version. SIG/M Volumes 173 to 176 are now available in their respectively named directories here. MICRO:SIGM.CRCLST is now being regenerated and should be ready by the time you read this. --Frank 15-Jul-84 22:56:34-MDT,1395;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 22:56:27-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 16 Jul 84 0:33 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 16 Jul 84 0:26 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 15 Jul 84 21:17-PDT Date: 6 Jul 84 5:40:54-PDT (Fri) To: info-cpm@Brl.arpa From: hplabs!sdcrdcf!sdcsvax!akgua!mcnc!ncsu!uvacs!edison!jwc@Ucb-Vax.arpa Subject: Re: MODEM730 & KAYPRO: can't print to Epson Article-I.D.: edison.290 In-Reply-To: Article <506@noscvax.UUCP> Steve, the trouble you're having is due to a bug in the Kaypro BIOS and ROM. According to the DRI manuals, BIOS call 14 (LISTST) should return a zero in A if the printer is ready, and an FF if it is not. Kaypro sets the zero FLAG, but does not return a zero. Their LIST call checks the flag, so it works fine for them. But MODEM7 et al checks for the contents of A, not the zero flag. There are two fixes: 1) Patch MDM7xx to get rid of the ANA A which sets the flag after the call to the BIOS. or 2) Patch the BIOS. This is about a six-byte patch, replacing the BIOS jump vector with a jump to a free area, which contains: CALL LISTST RNZ XRA A RET. If you have access to Compuserve, there's a complete patch in CP-MIG XA1. I understand it is also on the Detroit TRCM. 16-Jul-84 05:10:20-MDT,1115;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 16 Jul 84 05:10:16-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 16 Jul 84 6:37 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 16 Jul 84 6:28 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 16 Jul 84 2:57-PDT Date: 11 Jul 84 12:34:00-PDT (Wed) To: info-cpm@Brl.arpa From: pur-ee!uiucdcs!ea!mwm@Ucb-Vax.arpa Subject: Re: XLISP on SIMTEL20? (REQUEST) - (nf) Article-I.D.: ea.7800007 In-Reply-To: Article <1636@sri-arpa.UUCP> #R:sri-arpa:-163600:ea:7800007:000:467 ea!mwm Jul 11 14:34:00 1984 Speaking of XLISP: I would like to have a copy to try porting to CP/M-68K (no flames on CP/M-68K, unless you want to donate an HD & a Unix license). My letter & check to SIG/M seems to have fallen into a hole. So, could some kind person who can FTP the thing off of SIMTEL-20 please get in contact with me about helping me get a copy? I use CP/M 8" disks, or the ubiquitous xmodem protocol. I can be reached from ARPA as mtxinu!ea!mwm@BERKELEY.ARPA. Thanx, Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 16 Jul 84 06:18:37-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 16 Jul 84 7:53 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 16 Jul 84 7:50 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 16 Jul 84 4:38-PDT Date: 14 Jul 84 9:01:10-PDT (Sat) To: info-cpm@Brl.arpa From: hplabs!hao!seismo!rlgvax!cvl!umcp-cs!aplvax!cp1!hart@Ucb-Vax.arpa Subject: Re: Xerox 820-I clearinghouse/mailing list/bulletin board Article-I.D.: cp1.721 In-Reply-To: Article <1796@sri-arpa.UUCP> Count me in, especially for packet radio applications. -- ====================================================================== signed: Rod Hart (wa3mez) Chesapeake & Potomac Tel. Co. Bell Atlantic Inc. Silver Spring, Md. gamma!cp1!hart - umcp-cs!cp1!hart - aplvax!cp1!hart ====================================================================== 16-Jul-84 08:10:51-MDT,1753;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 16 Jul 84 08:10:44-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 16 Jul 84 9:38 EDT Date: 16 Jul 1984 07:33 MDT (Mon) Message-ID: Sender: KPETERSEN@Simtel20.ARPA From: Keith Petersen To: Info-Cpm@Amsaa.ARPA Subject: CP/M 2.2 BIOS support on CP/M+ BIOS2RSX for CP/M+ users is now available on SIMTEL20. Here is an excerpt from the source code which explains what this RSX does: BIOS2RSX 18Jan84 By Mike Griswold This RSX will provide CP/M 2.2 compatible BIOS support for CP/M 3.x. Primarily it performs logical sector blocking and deblocking needed for some programs. All actual I/O is done by the CP/M 3.0 BIOS. Typed in from the Dr. Dobb's Journal article in the July 84 issue. mabry Modified 9 July 1984 to run on an 8085 rather than just a Z80 ! Also added trap for BDOS call 12 (version number) and returns the indication that the calling program is running under version 2.2 of CP/M. This is necessary for programs that are written to trap a CP/M Plus environment but not able to handle the physical sector I/O of a CP/M Plus BIOS. mabry This equate is the only hardware dependent value. It should be set to the largest sector size that will be used. max$sector$size: equ 256 The files on SIMTEL20 are: Filename Type Bytes Sectors CRC Directory MICRO: BIOS2RSX.ASM.1 ASCII 11748 92 = 5CH D10BH BIOS2RSX.RSX.1 COM 1536 12 = CH 7218H --Keith 16-Jul-84 11:40:53-MDT,641;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 16 Jul 84 11:40:48-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 16 Jul 84 13:02 EDT Received: From jpl-vlsi.arpa.ARPA by BRL-AOS via smtp; 16 Jul 84 12:59 EDT Date: 15 Jul 1984 1122 PDT From: Peter Lyman Subject: ITS BINNARYCONVERSION VAX/VMS To: INFO-CPM@Brl-Aos.ARPA Reply-To: LYMAN@JPL-VLSI.ARPA Can sonme one send me pointers to how I handle ITS conversions on a VAX/VMS.... tnx peter lyman ------ 16-Jul-84 12:51:03-MDT,4333;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 16 Jul 84 12:50:31-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 16 Jul 84 14:07 EDT Received: From amsaa.arpa.ARPA by BRL-AOS via smtp; 16 Jul 84 14:00 EDT Date: Mon, 16 Jul 84 13:54:10 EDT From: David Towson (CSD) To: Richard Conn cc: info-cpm@brl-aos.arpa, info-unix@brl-aos.arpa Subject: Re: GET20 (~3750 chars) Giving credit where credit is due, I must emphatically state that I was only a clerk (and occasional needler) in the development of the automatic FTP programs for UNIX systems. The mastermind was Ferd Brundick of the Army Ballistic Research Labs. HE wrote the programs that automatically run FTP. All I did was write some shell scripts that use Ferd's programs, and I also wrote the documentation file, part of which is appended below. So since it was Ferd who wrote the programs, I can safely agree wholeheartedly with Rick Conn: These programs are REALLY NEAT! ------------------------------------------------------------------------------- AUTOMATIC FTP PROGRAMS FOR UNIX SYSTEMS These automatic FTP programs for UNIX systems provide a nearly effortless way to transfer files from the public-domain archives on SIMTEL20 using the InterNet File Transfer Protocol, FTP. The principal "worker" in this collection is the program GET20, a Bourne shell script written by Ferd Brundick of the U.S. Army Ballistic Research Laboratory. GET20 accepts inputs from the keyboard, or more conveniently from another shell script, and then calls the FTP program on the user's system and provides all needed inputs. Three file transfer modes are supported, ASCII, binary image, and binary in 8-bit bytes. SIMTEL20 is a 36-bit word-size PDP-20 running the TOPS-20 operating system. Therefore, only the ASCII and 8-bit-byte transfer modes will be useful for obtaining files from the public domain archives, as the data in these files must be unpacked from the 36-bit SIMTEL20 words and repacked for storage in 16 or 32-bit UNIX words. The binary image transfer mode is provided only for special applications. GET20 can be (and has been) easily edited to allow automatic retrieval of files from other machines that honor an anonymous FTP login. Once GET20 has been set in action, all aspects of the FTP process happen automatically. There are currently five archives on SIMTEL20: MICRO: MICRO: MICRO: MICRO: MICRO: All files in are in ASCII. Some files in , , and are in ASCII, while others are in ITS binary. The general file-name format for all archive files is: MICRO:PROGRAM_NAME GET20 has the device-name MICRO: built-in, but the other three parts of the path-name must be supplied by the user. Thus, a typical command-line for GET20 looks like this: get20 -a sigm.vol007 james.bond or alternately, get20 -a sigm.vol007 james.bond new_name The first form will transfer the file keeping the same name (in this case, james.bond), and the second form will give the transferred file a new name on the local system. If you give the command "get20" (with no arguments), GET20 will display a usage statement. The REAL convenience of GET20 comes from driving it with one-liner shell scripts that accept user input in VERY abbreviated form. For example, the one-liner "siga" , which obtains ASCII files from the archive, contains: get20 -a sigm.vol$* To obtain the file of the previous example, a user need only type: siga 007 james.bond If a user wants to do frequent ASCII transfers from the directory, the one-liner "m7a" (or some such name) having the form: get20 -a cpm.modem7 $* can be used. The user will then type only: m7a mdm730.asm The possibilities are endless. NOTE: The above is just a piece of the documentation file. For the full story, FTP the file MICRO:AUTOFTP.DOC from SIMTEL20. ------------------------------------------------------------------------------- Dave towson@amsaa.arpa 16-Jul-84 13:51:31-MDT,1006;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 16 Jul 84 13:51:21-MDT Date: Mon, 16 Jul 84 15:18:40 EDT From: Dave Towson (info-cpm) To: info-cpm@Amsaa.ARPA Subject: [Douglas Good: BIOS] Would somebody please answer this; I'm kind of tied-up right now. Thanks. Dave ----- Forwarded message # 1: Received: From utexas-20.arpa.ARPA by AMSAA via smtp; 15 Jul 84 20:43 EDT Date: Sun 15 Jul 84 19:45:02-CDT From: Douglas Good Subject: BIOS To: info-cpm-request@AMSAA.ARPA I'm trying to implement Pascal on my system and I got together everything I need except for one thing, my BIOS. I know it's relatively easy to extract but I've never done anything like that before. How can I extract my BIOS from CP/M in HEX format? I've already looked for a file called CBIOS.ASM or BIOS.ASM on disk but it's not there. --Doug ------- ----- End of forwarded messages 17-Jul-84 18:46:48-MDT,1404;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 17 Jul 84 18:46:39-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 16 Jul 84 19:36 EDT Received: From udel-ee.arpa.ARPA by BRL-AOS via smtp; 16 Jul 84 19:29 EDT Date: Mon, 16 Jul 84 19:28:32 EDT From: Dave Farber To: Lauren Weinstein cc: farber@UDEL-EE.ARPA, info-micro@BRL-AOS.ARPA, info-cpm@BRL-AOS.ARPA Subject: Re: Coherent, etc. Lauren, I purchased my Coherent from Mark Williams direct. I paid the normal fee (no educational or anything). I got ONE release with a hell of a lot of bugs. When I called them for help I got a run arround. After several months I sent them a MCI letter asking them why I never got updates or anything. I got a phone call that said they would send me something undefined. That was about 5 months ago and still NOTHING. I am persoanlly sick of companies that try to give the look of a real business but act like garage attic hackers. My experiences with SCO on Xenix are exactly the opposite. They are a professional operation that understands that people need to use their systems NOt just pay for them. I wanted Unix on the PC for real honest work and expected real support!!!. I will be happy to expand on this if anyone likes. Sick and tired Dave 17-Jul-84 18:47:22-MDT,2479;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 17 Jul 84 18:47:04-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 16 Jul 84 22:57 EDT Received: From rand-unix.arpa.ARPA by BRL-AOS via smtp; 16 Jul 84 21:30 EDT Received: from vortex.UUCP by rand-unix.ARPA; Mon, 16 Jul 84 18:30:34 pdt Date: Mon, 16-Jul-84 18:02:05 PDT From: Lauren Weinstein Subject: your Coherent problems Message-Id: <8407161802.384.2.VT3.3@vortex.UUCP> To: farber@Udel-Ee.ARPA Cc: INFO-MICRO@Brl-Aos.ARPA, INFO-CPM@Brl-Aos.ARPA Dave, I'm somewhat at a loss to understand the situation you describe, since it runs completely counter to my own experiences and to those of many people I talk to frequently about Coherent and Mark Williams Co. If there was a lag of 5 months I feel safe in assuming that something got lost -- most people I know have commented that they got the requested updates virtually immediately after requesting them. From what you describe, it sounds like you had one of the very early XT versions that had a particular problem due to an undocumented change in the disk drives/controllers that IBM began installing in the PC's. However, this problem was fixed LONG ago -- there have been numerous intermediate releases of Coherent sent out to people on request on a continuous basis. I personally have been encouraging MWC to hold off the next *major* release of the system so that a pile of useful new utilities can be included, such as an EMACS-compatible editor (it uses termcap and the standard Coherent H19/Z19 screen emulation, complete with meta key) ... it's primarily a matter of testing the new version and getting the rather voluminous documentation in order. In any case, intermediate versions of the system have been going out to people who requested them all along, and yours is the first report I've had of "support problems." Since I talk to MWC frequently, I invite you to give me a call and explain your situation, and I'll be happy to make sure that it's cleared up. --Lauren-- P.S. You mentioned MCI mail -- which triggered off one of my pet angers -- I've had reports of about 30% of MCI mail messages never being delivered. I can't prove this directly since I don't use it, but I've had lots of people try to send *me* MCI mail and it almost never arrives! Talk to you later. --LW-- 17-Jul-84 18:47:12-MDT,863;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 17 Jul 84 18:47:06-MDT Date: Tue, 17 Jul 84 13:14:40 EDT From: Dave Towson (info-cpm) To: info-cpm@Amsaa.ARPA, info-micro@Brl.ARPA Subject: [Frank Wancho: SIMTEL20 is down] I'm afraid those wishing to obtain public domain files from SIMTEL20 will have to wait for a while - see below. Dave ----- Forwarded message # 1: Received: From stl-host1.arpa.ARPA by AMSAA via smtp; 17 Jul 84 12:23 EDT Date: Tue 17 Jul 84 11:24:07-CDT From: Frank Wancho Subject: SIMTEL20 is down To: ccp-group@BRL.ARPA cc: INFO-CPM-REQUEST@AMSAA.ARPA The SIMTEL20 is down with hardware problems. We have no estimate of uptime at the moment... --Frank ------- ----- End of forwarded messages 18-Jul-84 02:12:48-MDT,1385;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 18 Jul 84 02:12:43-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 18 Jul 84 3:44 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 18 Jul 84 3:38 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 0:33-PDT Date: 15 Jul 84 10:30:45-PDT (Sun) To: info-cpm@Brl.arpa From: hplabs!sdcrdcf!sdcsvax!sdccs6!ir320@Ucb-Vax.arpa Subject: NEED HELP WITH MDM7! Article-I.D.: sdccs6.1620 HELP! I finally have the needed overlays (m7aq@2/3) to allow my Applicard and micromodem II to work together only to discover the program appears SPECIFICALLY written for MDM729. I had tried MDM740 but it acted very weird. I have to find (please) a copy of MDM730/729 which is already asm. (I don't feel like download what the local boards say is 850 sectors at 300 baud.) Any help or copies would be greatly appeciated. John Antypas UC San Diego UUCP: ...!sdcsvax!sdccs6!ir320 arpanet: sdcsvax!sdccs6!ir320@Berkeley PS: We don't have the capability to ftp files from other machines so don't try sending .com files to this account, unless you have the wonderful utility UNLOAD.com which creates those hex files. I can be reached at (619) 453 2841 evenings. Leave mail so I'll know to expect your call and I'll avoid the BBS's. 18-Jul-84 03:24:34-MDT,1115;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 18 Jul 84 03:24:30-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 18 Jul 84 4:58 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 18 Jul 84 4:50 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 1:30-PDT Date: 11 Jul 84 12:34:00-PDT (Wed) To: info-cpm@Brl.arpa From: pur-ee!uiucdcs!ea!mwm@Ucb-Vax.arpa Subject: Re: XLISP on SIMTEL20? (REQUEST) - (nf) Article-I.D.: ea.7800007 In-Reply-To: Article <1636@sri-arpa.UUCP> #R:sri-arpa:-163600:ea:7800007:000:467 ea!mwm Jul 11 14:34:00 1984 Speaking of XLISP: I would like to have a copy to try porting to CP/M-68K (no flames on CP/M-68K, unless you want to donate an HD & a Unix license). My letter & check to SIG/M seems to have fallen into a hole. So, could some kind person who can FTP the thing off of SIMTEL-20 please get in contact with me about helping me get a copy? I use CP/M 8" disks, or the ubiquitous xmodem protocol. I can be reached from ARPA as mtxinu!ea!mwm@BERKELEY.ARPA. Thanx, Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 18 Jul 84 07:03:20-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 18 Jul 84 8:24 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 18 Jul 84 8:20 EDT Date: 18 Jul 1984 06:20 MDT (Wed) Message-ID: From: Richard Conn To: CSTROM@Simtel20.ARPA Cc: info-cpm@Brl-Aos.ARPA Subject: [CSTROM: ZCPR3] In-reply-to: Msg of 18 Jul 1984 05:48-MDT from CSTROM Hi, Charlie, Thanks for the comments. Re CMDSET, I'll look at it and modify the book to include something about it if it was omitted ... if not, I'll be sure the index references it. Re the path, I haven't encountered any problem with it. Usually the BDOS error comes if the path is not properly terminated (by a binary 0). You might want to check that. I have been receiving several good comments on ZCPR3 personally ... perhaps they are not going out publically. Also, the magazines are picking up on it ... User's Guide has already commented on it in their review of the Ampro, and I know that others are planning feature articles. I guess you will see more in the months to come .. by then the book will be out, and people can really attack it. The phase 2 stuff is coming along very nicely. I think you will be very pleased with it. Most of it consists of screen-oriented utilities like VFILER, VMENU, DU3, MU3, and I am working on an RCP-resident version of MU3 so that an RCP-resident shell which can be used to debug programs as they reside in the TPA will be available. Enjoy! Rick 18-Jul-84 08:29:03-MDT,636;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 18 Jul 84 08:28:57-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 18 Jul 84 9:45 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 18 Jul 84 9:36 EDT Date: Wed 18 Jul 84 07:36:04-MDT From: Jim Forrest Subject: BYE & RBBS35 Info Needed To: info-cpm@BRL-AOS.ARPA cc: JFORREST@SIMTEL20.ARPA When running BYE (MBYE-33) and RBBS35, how can you protect the file with user passwords. Running ZCPR2 in secure mode but users can still access password file. Any help appreciated. Jim ------- 18-Jul-84 11:13:17-MDT,760;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 18 Jul 84 11:13:09-MDT Date: Wed, 18 Jul 84 12:23:13 EDT From: Dave Towson (info-cpm) To: info-cpm@Amsaa.ARPA Subject: [Frank Wancho: SIMTEL20 returns] SIMTEL20 is back - YAY!!! ----- Forwarded message # 1: Received: From stl-host1.arpa.ARPA by AMSAA via smtp; 17 Jul 84 15:55 EDT Date: Tue 17 Jul 84 14:56:54-CDT From: Frank Wancho Subject: SIMTEL20 returns To: ccp-group@BRL.ARPA cc: INFO-CPM-REQUEST@AMSAA.ARPA The file system on the SIMTEL20 is about to be reloaded and the machine should be up sometime this evening. --Frank ------- ----- End of forwarded messages 18-Jul-84 11:30:24-MDT,904;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 18 Jul 84 11:30:19-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 18 Jul 84 12:49 EDT Received: From office-2.arpa.ARPA by BRL-AOS via smtp; 18 Jul 84 12:44 EDT Date: 18-Jul-84 09:40 PDT From: ACB.TYM@OFFICE-2.ARPA Subject: ZCPR3 and Ampro To: info-cpm@brl.arpa Message-ID: <[OFFICE-2.ARPA]TYM-ACB-5287C> As a new owner of the Little board, I must comment about ZCPR3. What is distributed by AMPRO should not be called ZCPR3 because none of the utilities are there. What is there looks like ZCPR with the addition of multicommands per line. I have the ZCPR3 documentation (10 messages on the net) and was excited to try ZCPR3 only to find out that it wasn't there. The BIOS is modified and there is even a MOVCPM with ZCPR3 in it! but there ain't none of the other stuff. 19-Jul-84 01:54:59-MDT,1130;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 01:54:53-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 3:25 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 18 Jul 84 21:31 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 18:26-PDT Date: 16 Jul 84 12:42:32-PDT (Mon) To: info-cpm@Brl.arpa From: hplabs!sdcrdcf!sdcsvax!sdccs6!ir320@Ucb-Vax.arpa Subject: Need a working copy of mdmfnk.com Article-I.D.: sdccs6.1624 Hi. I need a working copy of MDMFNK.COM (though hex or asm is also OK). I just finished installing MDM730 with my PCPI system and everything works great, except I cant seem to set the functions keys with my copy for MDMFNK.COM. It allows me to set one or two and then the other keys either can't be set, or they have garbage. I tried this on another system so I know its not my apple. Any idea? PS: I saved the files with the right length too. John Antypas UC San Diego UUCP: ...!sdcsvax!sdccs6!ir320 arpanet: sdcsvax!sdccs6!ir320@Berkeley 19-Jul-84 01:58:01-MDT,970;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 01:57:56-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 3:26 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 18 Jul 84 21:42 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 18:28-PDT Date: 16 Jul 84 22:52:54-PDT (Mon) To: info-cpm@Brl.arpa From: hplabs!sdcrdcf!sdcsvax!sdccs6!ir320@Ucb-Vax.arpa Subject: Need Morrow MD2 Help Article-I.D.: sdccs6.1629 Help! We have a Morrow MD2 with a USR Password 1200 on it and a Silver Reed printer. We have the modem on the printer/modem port and the Silver Reed on what appears to be an accesorry par. port. We can't seem to print from the modem program (MDM730 w. M7MD-1.OVL) nor can we dial the modem after using Wordstar. Any help, suggestions? John Antypas UC San Diego UUCP: ...!sdcsvax!sdccs6!ir320 arpa: sdcsvax!sdccs6!ir320@Berkeley 19-Jul-84 02:02:58-MDT,1062;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 02:02:52-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 3:26 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 18 Jul 84 22:03 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 18:56-PDT Date: 29 Jul 84 21:40:00-EDT (Sun) To: info-cpm@Brl.arpa From: pur-ee!uiucdcs!hohensee@Ucb-Vax.arpa Subject: Do You Know Kermit??!? - (nf) Article-I.D.: uiucdcs.36300001 #N:uiucdcs:36300001:000:459 uiucdcs!hohensee Jul 15 23:40:00 1984 Would anyone have information regarding a file transfer program called "Kermit"? From what I understand, it is used with DEC O/S running also under CP/M and MSDOS on the DEC Rainbow. Again, from what I understand, it is used to in file transfer within DEC's (?) public domain software BBS called the MARKET System. Rainbow owner, Bill Hohensee uiucdcs!hohensee 19-Jul-84 02:31:49-MDT,866;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 02:31:44-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 3:26 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 18 Jul 84 22:04 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 18:57-PDT Date: 29 Jul 84 21:44:00-EDT (Sun) To: info-cpm@Brl.arpa From: pur-ee!uiucdcs!hohensee@Ucb-Vax.arpa Subject: Access to Simtel20??!? - (nf) Article-I.D.: uiucdcs.36300002 #N:uiucdcs:36300002:000:267 uiucdcs!hohensee Jul 15 23:44:00 1984 Could I ask a dumb question ... Can anybody tell me what is the "simtel20" BBS, and how does one can access to it?? thanks, Bill Hohensee uiucdcs!hohensee 19-Jul-84 02:49:14-MDT,1801;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 02:49:07-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 3:26 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 18 Jul 84 23:32 EDT Date: 18 Jul 1984 21:25 MDT (Wed) Message-ID: From: Richard Conn To: Jim Forrest Cc: info-cpm@Brl-Aos.ARPA Subject: BYE & RBBS35 Info Needed In-reply-to: Msg of 18 Jul 1984 07:36-MDT from Jim Forrest Not meaning to sound like a broken record (squeek, squeek), but ... ZCPR3 solves that problem cleanly. A system can be made secure under ZCPR3 by disabling the DU form and enabling only the DIR form. Passwords are then assigned to each key directory, and all commands along the path are either "safe" or wheel-byte protected (PATH itself will only run if the wheel byte is set). Then, a user cannot: (1) see a protected disk dir or (2) TYPE a file, PRINT a file, or do anything with any file in a protected disk dir without giving the password for that dir! See the section on secure systems in the User's Perspective. I am excited about this concept and am fairly sure it can't be broken without internal knowledge of the target system. If anyone can find a way to break this, let me know. In the way of example, note that the DU form is disabled. This means that you cannot issue the command TYPE A7: or anything like that. You MUST use the DIR: form, so if you say TYPE SYSROOT:, ZCPR3 will see the PW entry for SYSROOT and prompt the user for a PW. If no match, SYSROOT is expanded as his current dir instead, and the command runs there! Hope this helps. Rick 19-Jul-84 02:51:31-MDT,1641;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 02:51:25-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 3:26 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 18 Jul 84 22:36 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 19:29-PDT Date: 16 Jul 84 5:04:14-PDT (Mon) To: info-cpm@Brl.arpa From: ihnp4!ihuxk!db21@Ucb-Vax.arpa Subject: C Compiler for CP/M-80? Article-I.D.: ihuxk.680 I am considering the possibility of purchasing a C compiler for use on my home computer which has a cpm based operating system. I have read the articles in the August 83 issue of BYTE - The Unix C complier in a CP/M Environment, and Five C Compilers for CP/M-80, and have reached a conclusion similar to Kern's about the five compilers he reviewed, namely that the compiler should adhere to the Kernighan & Ritchie standard, perform compilations rapidly and have clean implementation, and be reasonably priced. Of the compilers mentioned in the article, the Aztec, BDS and C/80 seem to fill the bill. I would like to hear from anyone who has experience with these compilers preferably with more than one and can make a valid comparison. I would also like to hear from anyone who might know of a compiler that was not mentioned in the article, but meets the criteria. The upper price limit for this is about $250. Mail replies to ihuxk!db21. If there is sufficient response and/or information not mentioned in the articles, I will try to summarize for the net. Thanks in advance for your help. Dave Beyerl 19-Jul-84 03:00:10-MDT,4662;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 02:59:56-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 3:26 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 19 Jul 84 0:06 EDT Date: 18 Jul 1984 22:05 MDT (Wed) Message-ID: From: Richard Conn To: ACB.TYM@OFFICE-2.ARPA Cc: info-cpm@Brl-Aos.ARPA Subject: ZCPR3 and Ampro In-reply-to: Msg of 18 Jul 1984 10:40-MDT from ACB.TYM at OFFICE-2.ARPA You are partly right and partly wrong. You are wrong in that the CP is really the ZCPR3 CP. Yes, that is absolutely true. All ZCPR3 features are supportable with it. You are right in that they (Ampro) are not [yet] sending out the ZCPR3 SYSTEM, with all of the utilities. I recommend that you contact Ampro directly and complain. One disk with the 58 COM files will give you what you want, and Echelon has already sent me all 14 distribution disks in Ampro format. Ampro is eager to please its customers and get a good rep (note that you can buy their BIOS and sources to ALL their system-specific utilities for $49!). What they have had trouble with (and I can't blame them because full doc isn't out yet) is grasping the scope of ZCPR3. EONs ago (EON = more than 2 months) when we first established relations, Ampro had known of me thru ZCPR2 and was explicitly after FRIENDLY. We contracted for FRIENDLY, and, at that time, ZCPR2+ was in use by me. No one will ever see ZCPR2+ because it lived for only a few months until I completed the first ZCPR3. Anyway, ZCPR2+ had shells which made FRIENDLY work. As ZCPR3 developed, I did not want to have to support ZCPR2+, so we agreed that Ampro would go to ZCPR3, but, again, their mind set was on getting FRIENDLY, NOT ZCPR3. Anyway, to make a long story short, as the ZCPR3 CP finalized, I sent them four versions of ZCPR3 for the Ampro Little Board. They ranged from the minimum system thru a full-featured system with everything turned on. A secure system was even included. Still thinking of FRIENDLY, they elected to provide the minimum system. It gave the users the max TPA possible and supported the major ZCPR3 features sans RCPs, FCPs, etc. The external command line, shells, (I think) named dirs, messages, and registers were in there. This is probably what you have. Now that more doc is coming out, Ampro is finding out more about what ZCPR3 is. Evidently they still have not changed their original approach (again, I don't blame them since they had thousands of disks preconfigured and it would cost lots to change), but if you call them (and other Ampro users like you call them) and tell them that you want a full-featured ZCPR3, I have a hunch that they will comply. They already have it ... it is just a matter of setting up the disks. If enough people ask, they may start sending out full systems as standard. Some will want the full system, others will be very applications oriented and want the min system. Another note: early versions of the Ampro had an error in the BIOS. If a file was opened, a long delay occurred (long enough to let the drives stop), and then a write occurred, the disk was trashed. This shows itself when PIP runs to concatenate two large files usually. This has definitely been fixed, but test it and see if yours does it. If it does, you need the new BIOS also. Ampro is an excellent company. I really like dealing with them. Remember that they are learning about ZCPR3 like the rest of us (myself included, since I just discovered something really wonderful about it this morning ... more on this later), and, since they already have the rights to include ZCPR3 and they want to please their customers, if enough of you bother them with requests for the rest of the software, they may start including it naturally. Their only additional overhead is the extra disk and copying for it. I can't speak for them, and they may have a different perspective on this than I, but it would be worth your time to call them and ask. Finally, note also that the release of ZCPR3 is not complete. Phase 2 is coming, and, if you liked Phase 1 ... Phase 2 will open so many doors you won't know where to start. I am starting to boggle here at all of the possiblities and HAVE to decide when to stop with Phase 2 soon. Completeness is the key ... and I don't want to leave anything out. The book will be current thru the entire release, including phase 2. It is only two utilities behind right now. Enjoy! Rick 19-Jul-84 03:24:50-MDT,1920;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 03:24:40-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 3:26 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 19 Jul 84 0:11 EDT Date: 18 Jul 1984 22:10 MDT (Wed) Message-ID: From: Richard Conn To: info-cpm@Brl-Aos.ARPA Subject: [SSalzman.ES: booting in different user areas] FYI -- I thought you might me interested in general on what Isaac has to say. You see, while the ZCPR3 doc is a lot so far, the book (which is already 380+ pages in draft form) tells everything, including the hidden capabilities of ZCPR3. For instance, you may be familiar with the shell concept and the RCP concept, but what happens if you COMBINE them??? Wonderful, wonderful ... golly, gee whiz, Batman! I can't stand it ... more later. Rick Date: Wednesday, 18 July 1984 09:11-MDT From: SSalzman.ES at XEROX.ARPA To: Richard Conn cc: ssalzman.ES at XEROX.ARPA Re: booting in different user areas Rick, Hi. Thanks a lot! I made a little 3 byte patch to my BIOS and low and behold, I boot into A15:. The shell idea sounds good too, for other things, but this does solve my problem at the moment. I'm looking forward to the books and the phase 2 stuff. I'd like to know how to go about writing a shell and using the shell stack and the message buffer. I actually started working on one for ZCPR2 a while back (in C) but with the shell stack, I'll postpone that 'till I know more about it. You I'm having fun with it! I think the aliases are the most usefull things of all (in conjunction with the FCP). I've got tons of things I'd like to do with it, but no time. It's made my work a lot easier too. Well, thanks again, as usual! Take it easy.... Isaac. 19-Jul-84 03:39:14-MDT,878;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 03:39:08-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 3:26 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 19 Jul 84 0:14 EDT Date: 18 Jul 1984 22:14 MDT (Wed) Message-ID: From: Richard Conn To: SSalzman.ES@XEROX.ARPA Cc: info-cpm@Brl-Aos.ARPA Subject: booting in different user areas In-reply-to: Msg of 18 Jul 1984 09:11-MDT from SSalzman.ES at XEROX.ARPA Isaac, The book will include all of those internal details. There is a package devoted to shells (how they work, how to write one, etc) and a new Phase 2 utility can make ANY COMMAND SEQUENCE [which is short] into a shell! Like, DDT can be a shell ... your favorite editor ... etc, etc. Rick 19-Jul-84 03:50:56-MDT,3929;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 03:50:40-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 3:27 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 19 Jul 84 0:21 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 20:44-PDT Date: 16 Jul 84 18:12:43-PDT (Mon) To: info-cpm@Brl.arpa From: hplabs!tektronix!uw-beaver!uw-june!entropy!dataio!del@Ucb-Vax.arpa Subject: MOVCPM: The final solution!!!!! Article-I.D.: dataio.157 < nonononono please... > < leave a line for me.. > OK everyone, I'll talk. I have enjoyed all the discussions on the net about how to avoid the SYNCHRONIZATION error. Digital Research sure has you bozos pegged :-). D-R figured you'd try something like this, and anticipated most of your moves. To patch the package to work the way we would all like is definitely not worth the effort (I know, I have a fully disassembled listing stuck on a backup disk somewhere). KEEP READING>>>>> I will divulge the solution after I indulge myself :-). What they did was check the serial number, nothing new to all of you by now, of the running operating system and compare with an internally stored serial number within MOVCPM. You folks have all been taken for a ride, BECAUSE THEY DO IT TWICE!!! So even after the clever individual has come to the point of finding the first check, and fixes it, said problem does not go away. ha-ha. Like I said, they got you pegged (me too). Most of us go looking somewhere else once we find this first check. I have seen some other solutions, like one guy (not on the net) that had an incredibly involved patch to cause MOVCPM to look at it's OWN serial number. Not worth the effort. I have done so many configurations for people that I plumb run out of toes and fingers to count with. In each instance it was the same thing, MY system (actually running CDOS) trying to assemble and incorporate some CBIOS into the OTHER GUYS CPM. While I can appreciate D-R's desired to protect their software, they left the user with a classic chicken and egg problem - can't run the software till it's configured, can't configure the software till it runs. So, I now keep two versions of MOVCPM around: MOVCPM, and MOVXCPM. One runs under an operating system with the correct serial number, one runs under any other serial number. If you run the wrong one, you still get the SYNCH. ERR. What I did is so simple it will make you laugh. I've been chuckling for years over it. Naturally if you do a test, there is a conditional branch after it. I simply reversed the sense of the conditional!!! Now the MOVXCPM program checks to see if the operating system DOES NOT have the correct serial number (jokes on you, D-R). I don't have a copy of my listing handy, but I remember the task VERY well. So, take this patch, and apply to your MOVCPM with a grain of salt: meaning I may be off a byte or three (no more than that, I promise), and the sense of the conditional may be wrong. Just remember that the idea is to use the opposite conditional. Get out your debugger and look at the location 234h. I am positive of this location to the extent that it has been at this location in every MOVCPM that I have seen. JP NZ,025A Change this instruction to the opposite: JP Z,025A ; (or vice-versa, whichever is appropriate). Now look around 2CBh. You will find an identical instruction! Now you take and do the same hack to this guy and call your new program something unique (how about HAHA$DR.COM? :-) Just remember that after you have your new CPM up and running, use the unmodified version of MOVCPM, or you get halted, same as before. Please send mail, I want to hear about your success and gratitude. :-) Erik Lindberg AKA del @ dataio Redmond, WA ( I used to call myself a hacker.... ) 19-Jul-84 04:02:49-MDT,1367;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 04:02:43-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 3:27 EDT Received: From usc-isid.arpa.ARPA by BRL-AOS via smtp; 19 Jul 84 1:38 EDT Date: 19 Jul 1984 01:36-EDT Sender: ABN.ISCAMS@USC-ISID.ARPA Subject: Re: BYE & RBBS35 Info Needed From: ABN.ISCAMS@USC-ISID.ARPA To: JFORREST@SIMTEL20.ARPA Cc: info-cpm@BRL-AOS.ARPA Message-ID: <[USC-ISID.ARPA]19-Jul-84 01:36:31.ABN.ISCAMS> In-Reply-To: The message of Wed 18 Jul 84 07:36:04-MDT from Jim Forrest Jim I expect some experienced RBBS/BYE Sysops to answer you with more sophisticated responses, but a PD program I was just looking at kind of tickled my fancy. You say your users can access the password file, so no luck with passwords. Well, a little utility program called MAKEFCB (think I got it from SIMTEL20, maybe the SIG/M archives) changes the file name on disk and directory from upper case to lower case. CANNOT be listed, typed, transferred, erased -- NUTTIN! But it CAN be called from within other programs! So BYE or whatever could reach it and use it, but those curious ones cannot! Just a suggestion that might be fruitful. (An unusual potential fix anyway!) Regards, David Kirschbaum Toad Hall ABN.ISCAMS@USC-ISID 19-Jul-84 04:06:06-MDT,1215;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 04:06:00-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 3:48 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 19 Jul 84 3:39 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 19 Jul 84 0:26-PDT Date: 17 Jul 84 11:17:31-PDT (Tue) To: info-cpm@Brl.arpa From: hplabs!sdcrdcf!sdcsvax!sdccs6!ir320@Ucb-Vax.arpa Subject: Need Morrow Drivers || Morrow System Diskette Article-I.D.: sdccs6.1630 Attention Morrow User Community! I have a friend who has a Morrow MD2. It appears that the person who did her system integration only allowed her to use EITHER the serial port OR the parallel port. (As you can see, this make printing material coming off the modem very difficult.) I need some kind person out there to either mail me the source for a parallel && serial drivers so I can integrate them into her CP/M or I need some person local to San Diego, to allow me to have a copy of their system diskette already preconfigured. Thanks again. John Antypas UC San Diego UUCP: ...!sdcsvax!sdccs6!ir320 arpa: sdcsvax!sdccs6!ir320@Berkeley 19-Jul-84 04:57:06-MDT,2293;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 04:56:58-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 5:57 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 19 Jul 84 5:53 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 19 Jul 84 2:33-PDT Date: 17 Jul 84 6:19:09-PDT (Tue) To: info-cpm@Brl.arpa From: ihnp4!zehntel!dual!decwrl!dec-rhea!dec-cache!leigh@Ucb-Vax.arpa Subject: Announcement: The HOME COMPUTER Newsletter Article-I.D.: decwrl.2632 I've begun as a home business the publishing of a monthly newsletter for people who have an interest in home computers but know little or nothing about them. You are probably too sophisticated for this newsletter, but you have friends who would enjoy reading it. The newsletter is called The HOME COMPUTER Newsletter. Without a lot of technical jargon and buzz words, it will bring the following: o price information o quality information o new product announcements o trends from the computer industry o information for new users to help them feel comfortable with their new systems and to learn how to use the systems more effectively. o my opinions and recommendations about home computer matters. o answers to questions, etc. The first issue, which is a pre-subscription issue (subscriptions begin in October), discusses the following topics: o Welcome to the Newsletter o What the Newsletter will contain o The home computer market o News flashes o Protection from lightning o What are home computers? o Some good reading o Price trends o In the next issue (news flashes, what to do with a home computer, how to select a home computer, should you buy mail order or from a store, and should you buy a "complete package" or individual components.) If you feel your friends would be interested in looking at the paper, please pass this information on. The yearly subscription is $7.00 in the USA and Canada. A sample issue can be obtained by sending 25 cents and a stamped self addressed envelope. The address is: The HOME COMPUTER Newsletter P.O. Box K126 E. Pepperell, MA 01437 Thanks! Allen Leigh ...decvax!decwrl!rhea!cache!leigh 19-Jul-84 05:40:37-MDT,773;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 05:40:31-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 7:01 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 19 Jul 84 6:57 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 19 Jul 84 3:41-PDT Date: 24 Jul 84 10:04:38-EDT (Tue) To: info-cpm@Brl.arpa From: hplabs!tektronix!uw-beaver!cornell!vax135!ukc!west44!westcsr!phil@Ucb-Vax.arpa Subject: .PRL File Format Wanted Article-I.D.: westcsr.166 <> Could anybody let me have the precise format of the .PRL files used by Digital Research's Link-80 program? -- Thank you, Phil Thompson. {ENGLAND}..!ukc!west44!westcsr!phil ..!ukc!west44!phil 19-Jul-84 05:42:05-MDT,863;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 05:42:00-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 7:02 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 19 Jul 84 6:59 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 19 Jul 84 3:39-PDT Date: 24 Jul 84 9:52:05-EDT (Tue) To: info-cpm@Brl.arpa From: hplabs!tektronix!uw-beaver!cornell!vax135!ukc!west44!westcsr!phil@Ucb-Vax.arpa Subject: .PRL File Format Wanted Article-I.D.: westcsr.165 <> Could anybody supply me with the precise format of .PRL files used by Digital Research's Link-80 program? Thank you, Phil Thompson. {ENGLAND}..!ukc!west44!westcsr!phil ..!ukc!west44!phil -- Phil Thompson. {ENGLAND}..!ukc!west44!westcsr!phil ..!ukc!west44!phil 19-Jul-84 06:37:13-MDT,900;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 06:37:08-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 7:59 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 19 Jul 84 7:50 EDT Date: 19 Jul 1984 05:50 MDT (Thu) Message-ID: From: CSTROM@Simtel20.ARPA To: hplabs!sdcrdcf!sdcsvax!sdccs6!ir320@Ucb-Vax.arpa Cc: INFO-CPM@Brl-Aos.ARPA, CSTROM@Simtel20.ARPA Subject: Need Morrow Drivers || Morrow System Diskette In-reply-to: Msg of 17 Jul 1984 12:17-MDT from hplabs!sdcrdcf!sdcsvax!sdccs6!ir320 at Ucb-Vax.arpa Morrow supplies the source to the BIOS, so why not just work from there? I do understand that in the earliest systems, the BIOS source was not included. If your friend has such an old software version, I suggest that she obtain an update in any event. 19-Jul-84 07:37:35-MDT,1172;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 07:37:27-MDT Received: From mitre.arpa.ARPA by AMSAA via smtp; 19 Jul 84 8:55 EDT Date: 19 Jul 1984 7:57:26 EDT (Thursday) From: Jeffrey Edelheit Subject: Re: Do You Know Kermit??!? - (nf) In-Reply-to: Your message of 29 Jul 84 21:40:00-EDT (Sun) To: pur-ee!uiucdcs!hohensee@Ucb-Vax.ARPA Cc: info-cpm@Amsaa.ARPA Bill - Kermit is a file transfer protocol developed by Columbia University. It is a protocol that runs on a large number of "mainframes" (often super- minis) and also a large number of micros. The June and July issues of Byte had a two part article on Kermit. As you don't have FTP capabilities with Columbia-20, you can send a net msg to Frank da Cruz (cc.fdc at columbia-20.arpa) to get further specifics on how a usenetter can get Kermit. For what its worth, we are currently looking at Kermit as a candidate as the "official" file transfer protocol of MITRE. Also, it is the official protocol used by the National Institutes of Health's DEC-20 computer system. Jeff Edelheit (edelheit@mitre) 19-Jul-84 08:00:38-MDT,992;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 08:00:31-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 19 Jul 84 9:21 EDT Date: 19 Jul 1984 07:22 MDT (Thu) Message-ID: Sender: KPETERSEN@Simtel20.ARPA From: Keith Petersen To: Jim Forrest Cc: Info-Cpm@Amsaa.ARPA Subject: BYE & RBBS35 Info Needed In-reply-to: Msg of 18 Jul 1984 07:36-MDT from Jim Forrest Look at SECURTY2.ASM in MICRO:. This is assembled and renamed to RBBS.COM and placed in user zero. The "real" RBBS and all its files are placed in a user area that is inaccessable to callers. SECURTY2 is a small loader program which switches user numbers and then loads RBBS and jumps to it. When the user exits RBBS they return to the original drive/user because the user number change was only temporary. --Keith 19-Jul-84 10:52:49-MDT,1255;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 10:52:34-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 12:22 EDT Received: From usc-isid.arpa.ARPA by BRL-AOS via smtp; 19 Jul 84 12:21 EDT Date: 19 Jul 1984 12:20-EDT Sender: ABN.ISCAMS@USC-ISID.ARPA Subject: Re: Do You Know Kermit??!? - (nf) From: ABN.ISCAMS@USC-ISID.ARPA To: pur-ee!uiucdcs!hohensee@UCB-VAX.ARPA Cc: info-cpm@BRL.ARPA Message-ID: <[USC-ISID.ARPA]19-Jul-84 12:20:22.ABN.ISCAMS> In-Reply-To: The message of 29 Jul 84 21:40:00-EDT (Sun) from pur-ee!uiucdcs!hohensee@Ucb-Vax.arpa Rainbow owner (Bill to his friends), Re Kermit - see last month's BYTE Magazine for all the details (actually, the month before too - a 2-month production). Know LOTS about Kermit - but full documentation is available on most hosts in , and for sure at COLUMBIA-20, the home of the whole program. Look out there (via anonymous FTP) in KERMIT: for various documents, READMEs, etc. I'm forwarding separately the latest Info-Kermit Digest, which reviews how to get Kermit (and you can subscribe too!). Regards (Ain't it fun being green?) David Kirschbaum Toad Hall ABN.ISCAMS@USC-ISID 19-Jul-84 10:53:13-MDT,756;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 10:53:06-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 12:21 EDT Received: From amsaa.arpa.ARPA by BRL-AOS via smtp; 19 Jul 84 12:18 EDT Date: Thu, 19 Jul 84 12:08:10 EDT From: David Towson (CSD) To: pur-ee!uiucdcs!hohensee@ucb-vax.arpa cc: info-cpm@brl.arpa Subject: Re: Do You Know Kermit??!? - (nf) Bill - Since Jeff Edelheit has already answered your question, "what is KERMIT?", I will address your other point - a computer called MARKET. MARKET is one of several aliases for a DEC2060T known formally on the Arpanet as DEC-MARLBORO.ARPA. Dave towson@amsaa.arpa 19-Jul-84 11:10:45-MDT,695;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 11:10:39-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 12:32 EDT Received: From usc-isid.arpa.ARPA by BRL-AOS via smtp; 19 Jul 84 12:33 EDT Date: 19 Jul 1984 12:30-EDT Sender: ABN.ISCAMS@USC-ISID.ARPA Subject: Re: Access to Simtel20??!? - (nf) From: ABN.ISCAMS@USC-ISID.ARPA To: pur-ee!uiucdcs!hohensee@UCB-VAX.ARPA Cc: info-cpm@BRL.ARPA Message-ID: <[USC-ISID.ARPA]19-Jul-84 12:30:51.ABN.ISCAMS> In-Reply-To: The message of 29 Jul 84 21:44:00-EDT (Sun) from pur-ee!uiucdcs!hohensee@Ucb-Vax.arpa Info-CPM+ I got him, guys. David Kirschbaum Toad Hall 19-Jul-84 12:21:11-MDT,1239;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 12:21:03-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 12:54 EDT Received: From usc-isid.arpa.ARPA by BRL-AOS via smtp; 19 Jul 84 12:49 EDT Date: 19 Jul 1984 12:47-EDT Sender: ABN.ISCAMS@USC-ISID.ARPA Subject: Re: MOVCPM: The final solution!!!!! From: ABN.ISCAMS@USC-ISID.ARPA To: hplabs!tektronix!uw-beaver!uw-june!entropy!dataio!del@UCB-VAX.ARPA Cc: info-cpm@BRL.ARPA Message-ID: <[USC-ISID.ARPA]19-Jul-84 12:47:37.ABN.ISCAMS> In-Reply-To: The message of 16 Jul 84 18:12:43-PDT (Mon) from hplabs!tektronix!uw-beaver!uw-june!entropy!dataio!del@Ucb-Vax.arpa Erick, You can call yourself a hacker anytime you want! Nice fix...elegant even. Simplest is always bestest. (My initial fix prior to some elaborate poking around with DDT (yep, and I DID find both places)) was to let the sucker crash with that "SYNCH..." and then SAVE 48 CRASHCPM.COM. Go about my business, patch, etc. Seemed to be a real relocated CP/M there! (As I remember...) Thanks, mate - kudos to you. "Golum LOVES Eriks" (<== requested gratitude) Regards, David Kirschbaum Toad Hall ABN.ISCAMS@USC-ISID 19-Jul-84 13:07:37-MDT,3138;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 13:07:20-MDT Received: From ucb-vax.arpa.ARPA by AMSAA via smtp; 19 Jul 84 14:18 EDT Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.31) id AA26109; Thu, 19 Jul 84 11:18:04 pdt Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.14/4.22) id AA05922; Thu, 19 Jul 84 11:18:49 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.23.1) id AA19832; Thu, 19 Jul 84 11:18:51 pdt Date: Thu, 19 Jul 84 11:18:51 pdt From: William C. Wells Message-Id: <8407191818.AA19832@ucbopal.CC.Berkeley.ARPA> To: info-cpm@amsaa.ARPA Subject: CP/M Plus (CP/M 3.0) Software CP/M Plus Software Digest # 84-1 ================================ Date: Sat, 14 Jul 84 23:24:42 pdt From: William C. Wells To: info-cpm@amsaa.ARPA Subject: CP/M Plus (CP/M 3.0) Software I am trying to identify commercial and public domain software that runs under CP/M Plus. Most lists of software only list programs for CP/M 8080/Z80 as CP/M-80. However, not all CP/M software can handle CP/M Plus disk directories (with time stamps turned on). If you are running CP/M 3.0 or later on a Z80 or Z80A I would like to hear about what software you have found to work. I am also interested in software that takes advantage of the CP/M Plus banked memory. Bill Wells wcwells@Berkeley.ARPA ucbvax!wcwells WCWELLS@UCBJADE.BITNET P.S. I am running a PMC Micromate with CP/M 3.0 and 128K banked memory. ------- Date: Mon 16 Jul 84 15:08:18-PDT From: Sam Hahn I'd also be curious to find similar software. Last time I called New Generation systems, they were planning on a 3.0 versin of MicroShell, but that was at least half a year ago... -- sam hahn [shahn@sumex, samuel@score] ------- Date: Mon 16 Jul 84 20:59:19-PDT From: Bruce Tanner Two products I have used that support CP/M 3.0 are Kermit from Columbia and DU (ver 8.7 I think) from simtel-20. To support Kermit binary transfers, I've modified the modem input routine to not strip off the parity bit. PMC said that this functionality was in the newer BIOS's under a feature test switch, but I don't know if it is or not. [non-related text deleted; In the last paragraph Bruce is referring to implementing Kermit binary transfers on a PMC Micromate running CP/M Plus - WCW] -Bruce ------- Date: Tue 17 Jul 84 17:28:57-EDT From: J. Eliot B. Moss I have used the following on CP/M 3.0 with success: The FinalWord, CardBox, SuperCalc, BDS-C, JRT Pascal, Turbo Pascal, MODEM7, and a variety of SIG/M type public domain things. I do not use directory time stamping (my clock is not integrated into the BIOS yet, etc.). This may change if I ever get my own BIOS done .... Eliot [In separate correspondance, Eliot says he is using a SD System SBC-200 (S-100 board) - WCW] ------- End of forwarded messages -- CP/M Plus Software Digest # 84-1 19-Jul-84 14:46:12-MDT,637;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 14:46:05-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 19 Jul 84 16:15 EDT Received: From xerox.arpa.ARPA by BRL-AOS via smtp; 19 Jul 84 16:13 EDT Received: from Chardonnay.ms by ArpaGateway.ms ; 19 JUL 84 13:13:14 PDT Date: Thu, 19 Jul 84 13:13 PDT From: Pugh.PA@XEROX.ARPA Subject: Re: Xerox 820-I clearinghouse/mailing list/bulletin board In-reply-to: "hplabs!hao!seismo!rlgvax!cvl!umcp-cs!aplvax!cp1!hart@UCB-VAX.ARPA's message of 14 Jul 84 9:01:10 PDT (Sat)" To:hart@ucb.arpa cc: info-cpm@BRL.ARPA 20-Jul-84 09:47:10-MDT,719;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 20 Jul 84 09:46:58-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 20 Jul 84 11:07 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 20 Jul 84 8:08 EDT Date: 20 Jul 1984 06:08 MDT (Fri) Message-ID: From: Richard Conn To: info-cpm@Brl-Aos.ARPA Subject: Ampro I noted in this month's Microsystems that the ad on page 31 (or so) explicitly states that they are including the ZCPR3 CCP and says nothing else. This is absolutely true. Remember, however, that the CCP can be configured in a lot of ways (billyuns and billyuns). Rick 20-Jul-84 10:06:44-MDT,674;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 20 Jul 84 10:06:32-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 20 Jul 84 11:07 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 20 Jul 84 8:10 EDT Date: 20 Jul 1984 06:09 MDT (Fri) Message-ID: From: Richard Conn To: ABN.ISCAMS@USC-ISID.ARPA Cc: info-cpm@Brl-Aos.ARPA Subject: booting in different user areas In-reply-to: Msg of 19 Jul 1984 10:36-MDT from ABN.ISCAMS at USC-ISID.ARPA I DO sleep in my spare time ... usually from 3-4 AM every day, whether I need it or not! Rick 20-Jul-84 10:13:45-MDT,1239;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 20 Jul 84 10:13:36-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 20 Jul 84 11:19 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 20 Jul 84 11:12 EDT Received: From gmr.csnet by csnet-relay; 20 Jul 84 10:41 EDT Date: Fri, 20 Jul 84 09:51 EST From: haar%gmr.csnet@csnet-relay.arpa MMDF-Warning: Parse error in preceeding line at csnet-relay.arpa To: info-cpm@mit-mc.arpa Subject: modem programs Does anyone ahve a public domain program for doing modem control, communications, and file transfer that is compatible with MODEM7 protocol and is written in a high level language ( C, PASCAL, or FORTRAN preferred)? I need to communicate with several different host systems and want compatible file transfer with all of them. The systems include VAX/VMS, VAX/UNIX, PDP-11/RT-11, Motorola VMC-68/Versados. I am on CSNET, not ARPANET, so I cannot FTP files. If there is a suitable program archived somewhere on the net, I will have to access it indirectly. Thanks for any help you can give. Robert Haar General Motors Research Labs (313) 575-2105 HAAR.GMR@CSNET-RELAY 20-Jul-84 10:14:39-MDT,5074;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 20 Jul 84 10:14:14-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 20 Jul 84 11:08 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 20 Jul 84 8:49 EDT Date: 20 Jul 1984 06:48 MDT (Fri) Message-ID: From: Richard Conn To: info-cpm@Brl-Aos.ARPA Subject: SHSET Well, the new feature (actually, utility pair) is in place, and it works quite nicely. I thought I'd describe the concept to you and see what people think about it. ZCPR3 supports a concept (taken from AT&T's UNIX) which I call shells. The UNIX shell accepts a command line, interprets it, suspends itself and allows the command line to execute, and then resumes. The ZCPR3 shell, since we have a single-process (simple) OS, simply accepts a command line, interprets it, terminates (leaving messages about as to how ZCPR3 CP should reinvoke it) and allows the command line to execute, and then is resumed by the ZCPR3 CP. The bottom line is that, once a shell is running, whenever the ZCPR3 CP would print its prompt (DU:DIR>, like the CP/M D> prompt), the shell runs instead (no prompt appears from the ZCPR3 CP), and whatever the shell does becomes the user's interface to his system. Shells can be nested up to N levels deep (I recommend 4), so one shell can run another can run another ... . Examples of supplied ZCPR3 shells are MENU (which prints a menu and allows the user to select a menu item with a single keystroke), VFILER (which shows a file directory, allows the user to move the cursor around and manipulate files [copy, delete, rename, etc]), VMENU (which is a cross between VFILER [with the directory display and arrow] and MENU [with the menu display and selection]), and SH (which allows named variable sets and substitution in various forms). The new SHSET command (which is ONLY 1K in size) now exists and it allows ANYTHING to become a shell, whether is knows about ZCPR3 or not. The syntax is: SHSET cmd1;cmd2;... and, like a shell, when the ZCPR3 CP is going to print its prompt, it realizes that a shell has been defined, but instead of running just one program as a shell, it runs a command sequence. Along with SHSET is CMD, another 1K utility, which prompts the user for a command line and builds the new command line into the command line buffer in place of itself, allowing execution to resume with the command line the user just typed followed by any commands which originally followed CMD. Now commands like the following can be created: SHSET WS;CMD Each time the ZCPR3 CP is going to print a prompt, Word Star is run instead. The users does what he wishes inside of Word Star, and, when he exits, CMD is run. CMD will prompt him for a line: CMD DU:DIR> user input goes here The user's input is entered, it is executed, and then the shell is reinvoked, running Word Star again. To get out of the loop, the handy ZCPR3 Phase 1 command SHCTRL can be run. The command SHCTRL POP will pop the shell stack one level, terminating the WS;CMD sequence, and invoking the next lower shell, whether it is VFILER, VMENU, or the ZCPR3 CP itself. One feature I plan to zip into CMD this evening is sending output to a register to indicate whether an input line was entered. If this is done, ZEX could be run on top of the new SHSET shell: SHSET CMD;IF 9 0;WS;FI would establish the new shell to be: CMD - input a command line from the user and run it in place of CMD in the above script (if the command line was empty, set reg 9 to 0, else set reg 9 to 1) IF 9 0;WS;FI - if reg 9 = 0, run WS (no command was input, so run WS) go back and run CMD again after WS exits or the command line is finished If ZEX was running, ZEX would see the prompt and provide input. The line would be non-empty, so reg 9 = 1, we run the line, and then run CMD again. If ZEX was not running, the user could either input his own line (to be run immediately) or strike return (to enter WS). Of course, in the above example, WS could be anything, such as DBASE II, if the user desired [this capability has no limitation that I can see]. Note that all of this was done without any modification to the ZCPR3 CP (as would have to have been done with ZCPR2). All that was needed were two little 1K COM files. The concept of CMD is still firming up, but this is the idea (altho I may use the ERROR message instead of Reg 9 - have not decided yet). SHSET and CMD are basically running now. Also note that standard ZCPR3 shells, such as VFILER, already allow ZEX to run on top of them and the user can issue any command line he wishes from within the shell (VFILER has a Z command which prompts for command line, stores it, and exits, allowing the command to run and VFILER be reinvoked when the ZCPR3 CP decides to run the shell at the top of the shell stack). Comments? Rick 20-Jul-84 10:48:10-MDT,909;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 20 Jul 84 10:47:57-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 20 Jul 84 11:08 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 20 Jul 84 9:59 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 20 Jul 84 6:42-PDT Date: 19 Jul 84 14:54:14-PDT (Thu) To: info-cpm@Brl.arpa From: hplabs!sdcrdcf!sdcsvax!sdccs6!ir320@Ucb-Vax.arpa Subject: How much is the M80/LN80/LIB80 system? Article-I.D.: sdccs6.1634 How much can one pick up the M80 system for? I can't seem to find any ads still selling it. I have heard it is THE 8080/Z80 assembly language tool. If you know of a place that sells it at a reasonable or better price, I'd appreciate knowing about it too. John Antypas UC San Diego UUCP- ...!sdcsvax!sdccs6!ir320 arpa: sdcsvax!sdccs6!ir320@Berkeley 20-Jul-84 11:17:16-MDT,954;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 20 Jul 84 11:17:08-MDT Date: Fri, 20 Jul 84 12:12:49 EDT From: Dave Towson (info-cpm) To: info-cpm@Amsaa.ARPA Subject: Info request: Radio Shack Model 100 Can anyone help with this request? ----- Forwarded message # 1: Received: From usc-isi.arpa.ARPA by AMSAA via smtp; 19 Jul 84 10:30 EDT Date: 19 Jul 1984 10:30:57 EDT Subject: Radio Shack Model 100 From: Paul W. Sparks To: INFO-CPM-REQUEST@AMSAA.ARPA cc: PSPARKS@USC-ISI.ARPA I am in great need of the ROM Map for Radio Shack's Model 100 "Lapper". My task is to install (if possible) MEX,MDM or KERMIT in the thing. My wildest hope is for the whole ROM Map, but I really need only the4 I/O addresses. TNX Paul W. Sparks (PSPARKS@ISIA) ------- ----- End of forwarded messages 20-Jul-84 11:46:18-MDT,2011;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 20 Jul 84 11:46:09-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 20 Jul 84 12:52 EDT Received: From xerox.arpa.ARPA by BRL-AOS via smtp; 20 Jul 84 12:44 EDT Received: from Muscat.ms by ArpaGateway.ms ; 20 JUL 84 09:43:25 PDT Date: Fri, 20 Jul 84 12:41 EDT From: leisner.henr@XEROX.ARPA Subject: Re: C Compiler for CP/M-80? In-reply-to: "ihnp4!ihuxk!db21@UCB-VAX.ARPA's message of 16 Jul 84 5:04:14 PDT (Mon)" To: ihnp4!ihuxk!db21@UCB-VAX.ARPA cc: info-cpm@BRL.ARPA Dave, I've used BDS C and Aztec C on a Xerox 820 (I've also used Whitesmith's C and Small C). BDS C is lightening fast to compile, seems to produce reasonably efficient code but I don't trust it (I once developed a program on another C compiler and ported it over to CP/M and BDS made me crazy). I'd recommend it for doing developed on the compiler but don't trust it for portable code. Friends of mine have told me it misses some obvious errors. It also is a limited implementation (i.e. cannot define static arrays with data at allocation time). Aztec seems to be the best of all worlds -- reasonably fast compiles, reasonably efficient code, Unix compatibility. The only complaint I have with Aztec is their library source is generally uncommented (especially the assembly language written stuff). Whitesmiths is a product I cannot say a good word about. It's expensive, it takes forever to compile, it takes up enormous amounts of space (I think printf("Hello world" is 18 k of 8080 object code), the older versions I/O is not Unix compatible and the documentation is unreadable. Stay away from it by all means unless newer versions are different than the one I'm using. All in all, Aztec is very recommended as being Unix compatible. BDS is recommended with a grain of salt, but it is great for hacking out one day programs since it compiles so fast. Hope I've helped. Marty. 22-Jul-84 17:23:07-MDT,920;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 22 Jul 84 17:23:02-MDT Received: From xerox.arpa.ARPA by AMSAA via smtp; 22 Jul 84 18:58 EDT Received: from Gamay.ms by ArpaGateway.ms ; 22 JUL 84 15:59:29 PDT From: ssalzman.es@XEROX.ARPA Date: 22 Jul 84 15:59:29 PDT Subject: ZCPR3 BBS To: info-cpm@AMSAA.ARPA There is aa ZCPR3 BBS system now running in El Segundo Calif., on a Xerox 820-II. This is a FULL ZCPR3 implementation. All files are on line for downloading. There is also an LBR file with installation notes for the Xerox 820-II called Z3XEROX.LBR. The number is : (213)615-6410. *** Hours: 1700-0730 PDT On Weekdays, 24 hours on weekends. Please don't call at any other time! The system runs at 300/1200 baud, also with a 10mb rigid. The RBBS4 bulletin board is available for messages. -Isaac Salzman (SYSOP of Xerox Customer Ed. RBBS) 22-Jul-84 23:43:53-MDT,854;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 22 Jul 84 23:43:49-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 23 Jul 84 1:16 EDT Received: From sumex-aim.arpa.ARPA by BRL-AOS via smtp; 23 Jul 84 1:09 EDT Date: Sun 22 Jul 84 22:08:37-PDT From: Leslie Zatz Subject: MDM PROBLEM To: INFO-CPM@BRL.ARPA I am using MDM711 with a 2 MHz machine. Works fine at 300 baud but at 1200 baud I lose the first ffew letters of each line. Probably due to the slowness of my machine in scrolling. In a communication program I wrote for 1200 baud I had to use xoff at end of each line while I wrapped around and then xon to restart. (Problem not only due to slowness in scrolling but also in wraparound at end of each line). Is there a way to get around this? ------- 23-Jul-84 21:35:44-MDT,572;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 23 Jul 84 21:35:40-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 23 Jul 84 23:07 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 23 Jul 84 22:59 EDT Date: Mon, 23 Jul 84 22:54:11 EDT From: Manny Crivello Subject: help cpm .com to .hex To: info-cpm@mit-mc.arpa What I need is a program that will run under unix and that will convert cpm .com files to .hex files. thank you for any help that you can give. M.D.Crivello 24-Jul-84 05:07:39-MDT,2518;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 24 Jul 84 05:07:30-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 24 Jul 84 6:36 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 24 Jul 84 6:35 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 24 Jul 84 3:28-PDT Date: 18 Jul 84 2:53:47-PDT (Wed) To: info-cpm@Brl.arpa From: decvax!decwrl!amd!fortune!foros1!jr@Ucb-Vax.arpa Subject: Re: C Compiler for CP/M-80? Article-I.D.: foros1.242 In-Reply-To: Article <680@ihuxk.UUCP> Hi. I've been using C/80 (version 3.1, under CP/M) for a while, so I guess I'll toss out a few comments. Language: more or less full K&R, with some documented restrictions: no typedefs, no longs or floats (unless you get MATHPAK), no bit fields, no parameterized macros, no #line, no declarations within nested blocks. Big complaint number one: no parameterized macros. This turns out to be more useful than I thought it would be. It also has an undocumented restriction: structures can't contain pointers to structures which haven't been declared yet. Library: Incomplete. It doesn't even have !!!!!! If you want to use "stdin", you have to declare it yourself. No open() or close(), read() and write() can only do multiples of 128 bytes, no lseek() unless you buy MATHPAK (not sure if you get it then, but it would be easy to write). Big complaint number two: because of the order which subroutine arguments are pushed onto the stack (leftmost first), routines which get passed multiple parameters are implemented with a "kluge" (their word) which involves #defines to call TWO routines, one of which saves information about the top of the stack, for the other. This affects every routine which calls printf, for instance. Quality of compiler and code produced: No complaints. I haven't run anything big enough to get a feel for how fast or how large the generated code is. Overall impression: Still a bargain for $50. What this compiler really needs are (1) a full preprocessor (which there are a couple of public domain implementations in the works), and (2) and complete runtime library (which is also in the works, although it looks like it won't be public domain). I hope this helps. If you have any questions or whatever, just drop me a line. See ya! -- JR (John Rogers) ...ihnp4!fortune!foros1!jr also fortune!jr and proper!jr 24-Jul-84 06:18:31-MDT,1257;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 24 Jul 84 06:18:24-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 24 Jul 84 7:51 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 24 Jul 84 7:46 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 24 Jul 84 4:45-PDT Date: 22 Jul 84 5:59:47-PDT (Sun) To: info-cpm@Brl.arpa From: hplabs!hao!seismo!harvard!wjh12!genrad!grkermit!masscomp!bonnie!clyde!watmath!utzoo!utcsrgv!utai!mts@Ucb-Vax.arpa Subject: MP/M-86 Article-I.D.: utai.191 I would like to communicate (speak) to anyone out there who has done any system programming with the MP/M-86 operating system. I am trying to customize an existing system (add a new Tmp, etc.) and am having a lot of trouble with DRI's documentation (?). Thanks in advance. Martin Stanley Department of Computer Science University of Toronto Toronto, ON M5S 1A4 {cornell,decvax,ihnp4,linus,utzoo,uw-beaver}!utcsrgv!utai!mts Phone: (416) 961-4778 (home) (416) 978-8700 (daytime, sometimes) -- Martin Stanley Department of Computer Science University of Toronto Toronto, ON M5S 1A4 {cornell,decvax,ihnp4,linus,utzoo,uw-beaver}!utcsrgv!utai!mts 24-Jul-84 06:49:39-MDT,823;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 24 Jul 84 06:49:35-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 24 Jul 84 8:19 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 24 Jul 84 8:16 EDT Date: 24 Jul 1984 06:16 MDT (Tue) Message-ID: From: Richard Conn To: Manny Crivello Cc: info-cpm@Brl-Aos.ARPA Subject: help cpm .com to .hex In-reply-to: Msg of 23 Jul 1984 20:54-MDT from Manny Crivello MICRO: contains what you are looking for. COMHEX.C and COMHEX.MAN. COMHEX accepts a COM file as input and generates an Intel HEX file as output. It can be used as a filter. The archive is on SIMTEL20. Rick 24-Jul-84 14:27:46-MDT,567;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 24 Jul 84 14:27:42-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 24 Jul 84 15:33 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 24 Jul 84 15:27 EDT Date: Tue 24 Jul 84 14:43:15-EDT From: MLY.G.DRU%MIT-OZ@MIT-MC.ARPA Subject: Custon OpSys To: INFO-CPM%MIT-OZ@MIT-MC.ARPA Is it possible to write a "custom operating system" in BASIC? (could I put it on the system tracks like ZCPR?) Andrew Moore MLY.G.DRU@MIT-OZ ------- 24-Jul-84 20:22:25-MDT,806;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 24 Jul 84 20:22:21-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 24 Jul 84 21:55 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 24 Jul 84 21:51 EDT Date: 24 Jul 1984 20:52:33 EDT (Tuesday) From: Marshall Abrams Subject: Retirement planning programs To: arpanet-bboards@Mit-Ml.ARPA, info-apple@Mit-Mc.ARPA, info-atari@Su-Score.ARPA, info-cpm@Mit-Mc.ARPA, info-ibmpc@Usc-Isib.ARPA Cc: abrams@Mitre.ARPA Has anyone heard of retirement planning programs? I would be especially interested in those in the public domain in BASIC, but would like to learn about any products on the market. My brief survey hasn't turned up any. Thanks, Marshall Abrams 24-Jul-84 23:14:02-MDT,579;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 24 Jul 84 23:13:58-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 25 Jul 84 0:50 EDT Received: From usc-eclb.arpa.ARPA by BRL-AOS via smtp; 25 Jul 84 0:48 EDT Date: Tue 24 Jul 84 21:48:38-PDT From: Dick Subject: NSWP207 bug? To: info-cpm@BRL.ARPA I recently received NSWP207 on my system from a user. I have found that the SQ/USQ function no longer works on any of my systems, while it worked fine with version 205 of NSWP. ..Dick.. ------- 25-Jul-84 00:34:08-MDT,1639;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 00:34:00-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 25 Jul 84 2:04 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 25 Jul 84 1:55 EDT Date: 24 Jul 1984 23:55 MDT (Tue) Message-ID: From: Richard Conn To: Chapman.ES@XEROX.ARPA Cc: info-cpm@Brl-Aos.ARPA Subject: SHSET In-reply-to: Msg of 24 Jul 1984 12:08-MDT from Chapman.ES at XEROX.ARPA Cheryl, Yes, what they are describing can be done under ZCPR3 quite easily. In a sense, it has already been done. ZCPR3 has a facility which I call Error Handlers. These programs are invoked when an error in the command line occurs. The ZCPR3 CP leaves a message to its Error Handler which points to the command in error. The Error Handler can then do whatever it wishes. There are currently five different Error Handlers with ZCPR3. Two of them display the command line which was in error and the rest of the commands on the multiple command line buffer. They then give the user the option of reentering the erroneous command, advancing to the next command, entering a whole new command string, or flushing the entire command string. This does what the UNIX people were talking about, but, rather than advancing to the next command being automatic, the user has to manually choose to do so. It would not hurt to create another Error Handler which just skips to the next command. I will log your message and do so if I have the time. Thanks for the input. Rick 25-Jul-84 00:36:47-MDT,1445;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 00:36:42-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 25 Jul 84 2:04 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 25 Jul 84 2:03 EDT Date: 25 Jul 1984 00:03 MDT (Wed) Message-ID: From: Richard Conn To: MLY.G.DRU%MIT-OZ@MIT-MC.ARPA Cc: info-cpm@Brl-Aos.ARPA Subject: Custon OpSys In-reply-to: Msg of 24 Jul 1984 12:43-MDT from MLY.G.DRU%MIT-OZ at MIT-MC.ARPA In a word, nothing is impossible given the time. I see two immediate problems with writing an opsys in BASIC: (1) you would have to org the absolute binary to the CCP location or modify the cold boot routine to load the binary at its execution address and (2) you would have to restrict the use of the run-time library as much as possible if you want to store the opsys on the system tracks. In the ZCPR3 environ, if you want to have a BASIC application act as your front-end (shell), then it can be done quite easily with SHSET. Just give the command "SHSET MBASIC MYSHELL" and MBASIC MYSHELL will always be running. You may be able to use POKE to store a command for ZCPR3 to run in the command line buffer and then exit the MBASIC, at which time the command in the buffer wll run and MBASIC MYSHELL will be reexecuted. If this is what you want ... Rick 25-Jul-84 00:58:14-MDT,730;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 00:58:10-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 25 Jul 84 2:25 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 25 Jul 84 2:26 EDT Date: 25 July 1984 02:23-EDT From: Stephen C. Hill Subject: Wordstar 3.3 patching? To: CSTROM@Simtel20.ARPA cc: INFO-CPM@Mit-Mc.ARPA In-reply-to: Msg of 21 Jul 1984 19:17 MDT (Sat) from CSTROM at Simtel20.ARPA Our system uses a spooler as an intermediary, but WordStar still seems to take the same time as if it actually printed on a 1200 bps printer. Do you know of any way to speed things up? We have W* 3.3 running on a Z-80. 25-Jul-84 02:47:50-MDT,752;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 02:47:46-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 25 Jul 84 4:23 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 25 Jul 84 4:15 EDT Date: 25 July 1984 04:04-EDT From: Jerry E. Pournelle Subject: Wordstar 3.3 patching? To: STEVEH@Mit-Mc.ARPA cc: INFO-CPM@Mit-Mc.ARPA, CSTROM@Simtel20.ARPA In-reply-to: Msg of 25 Jul 1984 02:23-EDT from Stephen C. Hill WordStar takes so long, and uses such inefficient algorithms, for formatting text that adding a large print buffer does almost no good at all. The problems is not in your philosophy but in your [Word]Stars... 25-Jul-84 05:34:35-MDT,1530;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 05:34:27-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 25 Jul 84 7:02 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 25 Jul 84 6:59 EDT Date: 25 Jul 1984 04:59 MDT (Wed) Message-ID: From: CSTROM@Simtel20.ARPA To: "Stephen C. Hill" Cc: INFO-CPM@Brl-Aos.ARPA, CSTROM@Simtel20.ARPA Subject: Wordstar 3.3 patching? In-reply-to: Msg of 25 Jul 1984 00:23-MDT from Stephen C. Hill I assume that you are outputting the data to the spooler quite a bit faster than 1200 baud, correct? Unfortunately, WS has a nasty habit of sending the character stream out the printer port at a very slow rate. I assume that at least part of the delay is due to processing for the target printer, but I would not be a bit surprised if there was some delay built in as well, allowing effective simultaneous editing while printing without hogging the resources of the CPU. I think you would find that the actual effective output is faster than 1200 baud; on systems with buffers and 1200 baud printers, the buffer does indeed fill, but certainly the effective baud rate is probably more on the order of 2400 baud or thereabouts (a seat of the pants guess). I will try to get some info on this out of my friends at MicroPro, but things seem to get more screwed up there every day, so don't expect much from that quarter. 25-Jul-84 05:58:09-MDT,830;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 05:58:05-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 25 Jul 84 7:35 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 25 Jul 84 7:26 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 25 Jul 84 4:18-PDT Date: 24 Jul 84 9:52:07-PDT (Tue) To: info-cpm@Brl.arpa From: hplabs!tektronix!orca!iddic!rickc@Ucb-Vax.arpa Subject: C features Article-I.D.: iddic.1766 I appreciated the opinions from Marty about the different C's he has used - how about features? I have heard that BDS has floating point numbers, but they are implemented as strings. Does not sound good. Does Aztec support float (and double)? Thanks, Rick Coates tektronix!iddic!rickc 25-Jul-84 06:59:29-MDT,2054;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 06:59:17-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 25 Jul 84 8:31 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 25 Jul 84 8:25 EDT Date: 25 Jul 1984 06:16 MDT (Wed) Message-ID: From: Richard Conn To: info-cpm@Brl-Aos.ARPA Subject: [Penny.Anderson: LRUN as CMDRUN question] FYI -- I thought you might like to know about this. -- Rick Date: Wednesday, 25 July 1984 03:56-MDT From: Penny Anderson To: RCONN at SIMTEL20.ARPA cc: APA at CMU-CS-C.ARPA Re: LRUN as CMDRUN question Rick, First, kudos: Z3 came right up just like your doc said it would! We ran Z2 for about 8 months and it was wonderful. This is as much of an improvement over Z2 as Z2 was over 8080 cp/m. Thank you (if this was speech instead of typing, that would be in the sincerest tone I could muster)!! Second, a question: is there going to be an LRUNZ for Z3? I re-GENINSed my Z2 LRUNZ to use as my CMDRUN, however if LRUNZ doesn't find the .COM file, Z3 doesn't know, so my ERRORn is avoided even though it's a perfect job for it. A LRUN that can set the Message Buffer error flag (isn't that how it works?) would allow the Error handler to catch it. Did I miss something? Another suggestion: I was surprised there was no SAK option in the SYSRCP.LIB. Even a stripped down version with no bells and such would be nice. I hate sacrificing the disk and directory space for such a simple function. For your statistics: We run a N* Horizon with 2 5in floppies and LifeBoat CP/M, TeleVideo 950 (lucky for me when using your stuff), Centronics 739 printer on parallel, and USR Password with MEX and YAM. Congratulations on another wonderful (and large) piece of work and thanks again for giving it away. Looking forward to the books. Don Shields c/o Penny Anderson APA@CMU-CS-C.ARPA 25-Jul-84 07:11:32-MDT,1309;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 07:11:25-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 25 Jul 84 8:31 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 25 Jul 84 8:25 EDT Date: 25 Jul 1984 06:14 MDT (Wed) Message-ID: From: Richard Conn To: Penny Anderson Cc: info-cpm@Brl-Aos.ARPA Subject: LRUN as CMDRUN question In-reply-to: Msg of 25 Jul 1984 03:56-MDT from Penny Anderson Thank you for your message, Penny. Phase 2 of ZCPR3 is yet to come out, and I have a number of things planned. One is LRUNZ. Phase 2 is still forming (altho not for very long now because my book deadline is coming up and I want the book to include everything), so any last-minute suggestions that anyone has are welcome, but I can't guarantee that they will make it in. Also, FYI, I got a report on beta-test efforts for a part of the Phase 2 software. The only problem reported so far is that VFILER and VMENU (the VFILER/MENU shell) interact strangely from time to time when VFILER runs under VMENU. VFILER tends to cancel VMENU. Will have to fix this one before release. Rick 25-Jul-84 07:34:59-MDT,1060;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 07:34:52-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 25 Jul 84 8:56 EDT Date: 25 Jul 1984 06:58 MDT (Wed) Message-ID: Sender: KPETERSEN@Simtel20.ARPA From: Keith Petersen To: Info-Cpm@Amsaa.ARPA Subject: UNERA20 unerase utility now available The popular utility UNERA has been updated to version 2.0. Users with deblocking CBIOSs will want to get this new version, which corrects a problem with not restoring files whose names were in the last sector used in the directory. The files are now available on SIMTEL20. Here's a list: Filename Type Bytes Sectors CRC Directory MICRO: UNERA20.ASM.1 ASCII 17261 135 = 87H 54C6H UNERA20.COM.1 COM 1408 11 = BH 29E4H UNERA20.DOC.1 ASCII 4760 38 = 26H 0E8CH UNERA20.HEX.1 ASCII 3440 27 = 1BH D801H UNERA20.HLP.1 ASCII 4796 38 = 26H EFD0H --Keith 25-Jul-84 13:11:08-MDT,992;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 13:10:58-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 25 Jul 84 14:28 EDT Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp; 25 Jul 84 14:29 EDT Received: from MIT-MC by MIT-OZ via Chaosnet; 25 Jul 84 14:28-EDT Received: from Concord.ms by ArpaGateway.ms ; 25 JUL 84 11:27:09 PDT Date: 25 Jul 84 10:17:53 PDT (Wednesday) From: Bicer.ES@XEROX.ARPA Subject: Re: Custon OpSys In-reply-to: MLY.G.DRU%MIT-OZ's message of Tue, 24 Jul 84 14:43:15 EDT To: MLY.G.DRU%MIT-OZ@MIT-MC.ARPA cc: INFO-CPM%MIT-OZ@MIT-MC.ARPA I presume that it is possible to write a "custom operating system" in BASIC, but WHY BASIC? Do you like pain? Jack Bicer P.S: It'll probably be easier to boot CP/M first and (maybe automatically) load your operating system. If you really need it, you could write your cold start sequence and load anything you want from anywhere you want. 25-Jul-84 20:59:40-MDT,1280;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 20:59:35-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 25 Jul 84 22:39 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 25 Jul 84 22:39 EDT Date: 25 Jul 1984 20:37 MDT (Wed) Message-ID: From: Richard Conn To: William C. Wells Cc: info-cpm@Brl-Aos.ARPA Subject: ZCPR3 and CP/M 3.0 In-reply-to: Msg of 25 Jul 1984 12:03-MDT from wcwells%ucbopal.CC at Berkeley (William C. Wells) Yes, ZCPR3, SYSLIB3, Z3LIB, and VLIB all run under CP/M 2.2. Due to their direct BIOS calls, they will not run under CP/M 3.0. Some degree of modification to the low-level device drivers is required in order to get the libraries to be useful under CP/M 3.0. ZCPR3, however, is another problem, since, as a command processor, it directly loads the COM files it selects, a knowledge of your bank-switched environment is required. I suspect that the degree of modification to get ZCPR3 to run under CP/M 3.0 would be extensive. Re the files on SIMTEL20 that you referenced, I am not familiar with them. I am not moving toward the CP/M 3.0 world. Rick 26-Jul-84 07:50:56-MDT,1172;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 26 Jul 84 07:50:50-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 26 Jul 84 9:13 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 26 Jul 84 9:09 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 26 Jul 84 6:00-PDT Date: 25 Jul 84 8:25:41-PDT (Wed) To: info-cpm@Brl.arpa From: hplabs!sdcrdcf!sdcsvax!sdccs6!loral!simard@Ucb-Vax.arpa Subject: Epson QX-10 serial port question Article-I.D.: loral.297 [Do not write in this space] I am seeking to implement MODEM7 on an Epson QX-10. So far I have not seen any reference to the serial port in the documentation other than an acknowledgement of its existence. I'd like to know the following: 1: What physical device(s) is the serial port in the CP/M environment? 2: Is the port configured as DTE or DCE? 3: What modem control lines are needed to use it, if any? 4: Port addresses, UART/ACIA/whatever type, and I/O or memory mapped? Any of this info would be appreciated. -- Ray Simard Loral Instrumentation, San Diego {ucbvax, ittvax!dcdwest}!sdcsvax!sdccsu3!loral!simard 26-Jul-84 08:28:21-MDT,860;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 26 Jul 84 08:28:16-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 26 Jul 84 9:45 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 26 Jul 84 9:46 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 26 Jul 84 6:41-PDT Date: 24 Jul 84 5:28:13-PDT (Tue) To: info-cpm@Brl.arpa From: hplabs!sdcrdcf!sdcsvax!akgua!mcnc!ecsvax!mjg@Ucb-Vax.arpa Subject: mdm7xx overlay for Toshiba T100 wanted Article-I.D.: ecsvax.2984 Does anyone have an overlay for a Toshiba T100 CP/M system to go with the Modem 7xx series programs. I would appreciate it greatly if anyone could give me a lead or better yet mail me a copy of the overlay if it exists. Thanks, Mike Gingell, Raleigh NC ...decvax!mcnc!ecsvax!mjg 26-Jul-84 21:19:08-MDT,3251;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 26 Jul 84 21:18:58-MDT Received: From ucb-vax.arpa.ARPA by AMSAA via smtp; 26 Jul 84 22:11 EDT Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA02089; Thu, 26 Jul 84 19:11:08 pdt Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.14/4.23.1) id AA05143; Thu, 26 Jul 84 19:12:24 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.23.1) id AA01732; Thu, 26 Jul 84 19:12:23 pdt Date: Thu, 26 Jul 84 19:12:23 pdt From: William C. Wells Message-Id: <8407270212.AA01732@ucbopal.CC.Berkeley.ARPA> To: RCONN@SIMTEL20.ARPA Subject: Re: ZCPR3 and CP/M 3.0 Cc: info-cpm@amsaa.ARPA Richard, In reply to: Date: 25 Jul 1984 20:37 MDT (Wed) Message-Id: From: Richard Conn To: wcwells@ucbopal (William C. Wells) Cc: info-cpm@brl Subject: ZCPR3 and CP/M 3.0 In-Reply-To: Msg of 25 Jul 1984 12:03-MDT from wcwells%ucbopal.CC at Berkeley (William C. Wells) Yes, ZCPR3, SYSLIB3, Z3LIB, and VLIB all run under CP/M 2.2. Due to their direct BIOS calls, they will not run under CP/M 3.0. Some degree of modification to the low-level device drivers is required in order to get the libraries to be useful under CP/M 3.0. ZCPR3, however, is another problem, since, as a command processor, it directly loads the COM files it selects, a knowledge of your bank-switched environment is required. I suspect that the degree of modification to get ZCPR3 to run under CP/M 3.0 would be extensive. Re the files on SIMTEL20 that you referenced, I am not familiar with them. I am not moving toward the CP/M 3.0 world. Rick The files, I referred to on SIMTEL20 are: Filename Type Bytes Sectors CRC Directory MICRO: BIOS2RSX.ASM.1 ASCII 11748 92 = 5CH D10BH BIOS2RSX.RSX.1 COM 1536 12 = CH 7218H The BIOS2RSX.ASM is the source for BIOS2RSX.RSX and is a copy of the CP/M Exchange Listing in Dr. Dobb's Journal, July 1984, starting at page 23. BIOS2RSX.ASM, to quote the author, Mike Griswold of Fort Worth, Texas: ... will provide CP/M 2.2 compatible BIOS support for CP/M 3.x. Primarily it performs logical sector blocking and deblocking needed for some programs. All actual I/O is done by the CP/M 3.0 BIOS. How Resident System Extensions (RSX) may be used is discussed in an article by Garry M. Silvey in the same issue of Dr. Dobb's Journal starting at page 36. Robert Blum, on page 22, stated that he attached the RSX to a CP/M 2.2 version of DU, and that it worked perfectly. Thus it appears that BIOS2RSX.RSX when attached to a COM file using GENCOM, will intercept the 2.2 I/O calls and convert them to 3.0 I/O calls. If this is true for all I/O calls, then it should be possible to assemble CP/M 2.2 programs that use members of SYSLIB3, Z3LIB, and VLIB, attach BIOS2RSX.RSX and have a program that works under CP/M 3.0. I suspect you are right about ZCPR3. Bill Wells wcwells@Berkeley.ARPA ucbvax!wcwells WCWELLS@UCBJADE.BITNET 27-Jul-84 09:02:43-MDT,821;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 27 Jul 84 09:02:39-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 27 Jul 84 10:03 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 27 Jul 84 9:56 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 27 Jul 84 6:48-PDT Date: 26 Jul 84 9:50:16-PDT (Thu) To: info-cpm@Brl.arpa From: hplabs!sdcrdcf!sdcsvax!sdccs6!loral!simard@Ucb-Vax.arpa Subject: How to you access SIMEL20? Article-I.D.: loral.317 [Do not write in this space] I've seen many references to CP/M programs residing in something called SIMTEL20 (or SIMEL20). How do users access this library? Thanks for any help. -- Ray Simard Loral Instrumentation, San Diego {ucbvax, ittvax!dcdwest}!sdcsvax!sdccsu3!loral!simard 27-Jul-84 10:20:37-MDT,910;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 27 Jul 84 10:20:30-MDT Received: From brl-vgr.arpa.ARPA by AMSAA via smtp; 27 Jul 84 11:18 EDT Received: from hi-multics.arpa by BRL-VGR.ARPA id a005902; 27 Jul 84 11:13 EDT Date: Fri, 27 Jul 84 10:10 CDT From: "David S. Cargo" Subject: ? ASM S error flag To: info-cpm@BRL-VGR.ARPA Message-ID: <840727151020.761538@HI-MULTICS.ARPA> While trying to bring up KERMIT v3.9A I discovered two things. ASM does NOT object to an ASEG declaration after the ORG 100H. I expected that it would, but it didn't. On some code it generated an S error flag for the line, but none of the DRI documentation for ASM indicates what the S error flag means. Are there other undocumented features in ASM? What does S mean in this context? .... David S. Cargo (Cargo at HI-Multics) 27-Jul-84 13:23:57-MDT,1984;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 27 Jul 84 13:23:44-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 27 Jul 84 13:00 EDT Received: From xerox.arpa.ARPA by BRL-AOS via smtp; 27 Jul 84 13:01 EDT Received: from Concord.ms by ArpaGateway.ms ; 27 JUL 84 09:57:38 PDT Date: 27 Jul 84 09:48:41 PDT (Friday) From: Bicer.ES@XEROX.ARPA Subject: Re: C features In-reply-to: hplabs!tektronix!orca!iddic!rickc's message of 24 Jul 84 9:52:07 PDT (Tue) To: hplabs!tektronix!orca!iddic!rickc@UCB-VAX.ARPA cc: info-cpm@BRL.ARPA Here is a quick chart of CP/M C compilers: Version Small Smallc+ Q/C C80 Super- BDS C AZTEC C v1 soft ------------------------------------------------------------------------------ Operators most most all all all all all Arrays oned oned oned nd nd nd nd Datatypes char y y y y y y y int y y y y y y y short n n y n n n ? unsigned n n n y y y y pointer y y y y y y y long n n n n n n y float,double n n n n n n y extern n n y y y y y static n n y y n n y register n n n static static static y*** structure n n n y y y y union n n n n n y y intialize n n y y n n y casts n n n n ? n y program control most all all all all all all #define y y y y y y y #define f(x) n n n n ? y y #include y* y* y y y y y #ifdef/ifndef n n y y y y y #if/else/endif n n y y y y y #asm/endasm y y y y y n ? Output asm/mac y n y y y n asm** m80/l80 n y y y y n y object n n n n n y n Source? y y y n n n n Price: (free) $24 $95 $50 $200 $150 $199 * Includes can not nest (and in some versions have funny syntax.) ** Assembler/linker supplied. *** Even on an 8080, Aztec C puts the first "register" declaration in register pair BC. On a Z80, the first three go to BC, IX, and IY. However, when the function is not recursive you win by *not* using IX and IY registers instead of explicit "static"s. (tekecs!andrew) 27-Jul-84 15:47:11-MDT,1457;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 27 Jul 84 15:47:01-MDT Received: From brl-vgr.arpa.ARPA by AMSAA via smtp; 27 Jul 84 17:09 EDT Received: from usc-isid.arpa by BRL-VGR.ARPA id a014091; 27 Jul 84 17:01 EDT Date: 27 Jul 1984 16:59-EDT Sender: ABN.ISCAMS@USC-ISID.ARPA Subject: Re: ? ASM S error flag From: ABN.ISCAMS@USC-ISID.ARPA To: Cargo@HI-MULTICS.ARPA Cc: info-cpm@BRL-VGR.ARPA Message-ID: <[USC-ISID.ARPA]27-Jul-84 16:59:41.ABN.ISCAMS> In-Reply-To: <840727151020.761538@HI-MULTICS.ARPA> David, Appears the S error flag in ASM is harmless - I use it all the time to put little messages to the user within code so it will say things while assembling. Never appears in the final assembled code at all. I make it a habit to comment out ASEGs and other stuff unique to other assemblers (juuuust in case...), but you're right - sometimes ASM yelps and sometimes it doesn't. Weird. I suggest you look at the Public Domain linking assembler LASM.COM (available via Anonymous FTP from SIMTEL20 micro:LASM2.ASM (I believe). Faster than ASM, same rules apply, PLUS you can link segments together in the simplest fashion! I'm using it right now to link together a bunch of segments for KERMIT 4.0 (test), and works just fine and fast. You can also get a symbol file out of the thing too. Regards, David Kirschbaum Toad Hall (ABN.ISCAMS@USC-ISID) 27-Jul-84 19:24:47-MDT,1905;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 27 Jul 84 19:24:37-MDT Received: From ucb-vax.arpa.ARPA by AMSAA via smtp; 27 Jul 84 20:32 EDT Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA02124; Fri, 27 Jul 84 17:32:30 pdt Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.14/4.23.2) id AA04542; Fri, 27 Jul 84 17:34:17 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.23.2) id AA13910; Fri, 27 Jul 84 17:33:04 pdt Date: Fri, 27 Jul 84 17:33:04 pdt From: William C. Wells Message-Id: <8407280033.AA13910@ucbopal.CC.Berkeley.ARPA> To: sdcsvax!sdccs6!loral!simard@Ucb-Vax.ARPA Subject: Re: How to you access SIMEL20? Cc: info-cpm@amsaa.ARPA In reply to: To: info-cpm@Brl.arpa From: hplabs!sdcrdcf!sdcsvax!sdccs6!loral!simard@BERKELEY Subject: How to you access SIMEL20? Article-I.D.: loral.317 [Do not write in this space] I've seen many references to CP/M programs residing in something called SIMTEL20 (or SIMEL20). How do users access this library? Thanks for any help. -- Ray Simard Loral Instrumentation, San Diego {ucbvax, ittvax!dcdwest}!sdcsvax!sdccsu3!loral!simard Only users on the DOD Internet can access files on SIMTEL20, they are not accessable from UUCP. Some are posted to the USENET news group "net.sources". Most of the files placed in the CP/M Library are distributed to RCPM systems around the country. Some of the files are copies of volumes distributed by SIG/M. Because SIMTEL20 is at the top of the RCPM distribution tree, you will often see programs and other files announced on SIMTEL20 a month or so before the files find there way out to local CP/M user group libraries. Bill Wells wcwells@Berkeley.ARPA WCWELLS@UCBJADE.BITNET ucbvax!wcwells 27-Jul-84 22:42:08-MDT,1117;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 27 Jul 84 22:42:02-MDT Date: Fri, 27 Jul 84 22:52:02 EDT From: Dave Towson (info-cpm) To: info-cpm@Amsaa.ARPA Subject: [Bicer.ES: Accounting Software - HELP!] Can anyone help with this? If so, please respond to Jack Bicer, not to me. Dave ----- Forwarded message # 1: Received: From xerox.arpa.ARPA by AMSAA via smtp; 25 Jul 84 20:07 EDT Received: from Concord.ms by ArpaGateway.ms ; 25 JUL 84 17:00:08 PDT Date: 25 Jul 84 10:41:49 PDT (Wednesday) From: Bicer.ES@XEROX.ARPA Subject: Accounting Software - HELP! To: XeroxInfo-CPM^.wbst@XEROX.ARPA cc: info-cpm-request@AMSAA.ARPA Reply-To: Bicer.ES@XEROX.ARPA Help! I need some information about accounting software for CP/M. Currently hoping that Accounting Partner form Star Software will fill the need. Also, the Champion looked pretty good but expensive. Every bit (or byte) of information will be greatly appreciated. Thanks in advance Jack Bicer ----- End of forwarded messages 28-Jul-84 02:22:17-MDT,2516;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 28 Jul 84 02:22:08-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 28 Jul 84 1:27 EDT Date: 27 Jul 1984 23:29 MDT (Fri) Message-ID: From: "Frank J. Wancho" To: "William C. Wells" Cc: INFO-CPM@Amsaa.ARPA Subject: SIG/M distribution In-reply-to: Msg of 27 Jul 1984 18:33-MDT from William C. Wells Bill, I'm actually on the tail end of one of the three regional distribution chains of SIG/M because I asked to be in that position. I have been travelling alot in recent months and thus cannot guarantee quick turnaround to the next point if someone is behind me. SIG/M is getting considerably better organized of late. Almost every month their Regional Coordinator sends out the three sets of updates about a month before they are "officially" announced. Thus, by the time I get them, convert the disks, and have them uploaded, the announcement is made, giving the appearance of being timely. BTW, for those interested in such things, I had found an 8" disk controller that behaves properly in my N*, called the MCP/FDC, from MCP Computer Products. It's only drawback is that it doesn't pass through the two-sided disk signal from the 50-pin connector. Otherwise, it's a clean, simple, and relatively inexpensive ($199) board that doesn't require any mods. Unfortunately, it was only on loan, and is now sitting in another N* running TurboDOS... I still have a semi sick DJDMA awaiting the new PROM set. If that doesn't fix the double-density-only problem, it goes back for repair. There are two CCS2422 FDCs which still cause memory parity errors on write, even after replacing my ancient 350ns RAM with 150ns RAM... (that change seemed to cure the mpe's on read), and a CompuPro Disk 1 that hangs the system (and the factory could care less about their boards in foreign machines as they are a System House now... so much for the leader of IEEE-696 cards...) A possible cure for my troubles is in the works: we are applying the IEEE-696 upgrade mods to the N* CPU card (as published in the April issue of Microsystems). I'll let you all know the results of that. (I may even end up believing the rumor that the N* motherboard is noisy and splurge on an active termination card.) Sorry for the core dump. --Frank 28-Jul-84 02:47:21-MDT,1197;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 28 Jul 84 02:47:15-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 28 Jul 84 1:37 EDT Date: 27 Jul 1984 23:39 MDT (Fri) Message-ID: From: "Frank J. Wancho" To: "David S. Cargo" Cc: INFO-CPM@Amsaa.ARPA Subject: ? ASM S error flag In-reply-to: Msg of 27 Jul 1984 09:10-MDT from David S. Cargo Dave, The error code is documented in the MAC manual: S - Syntax error: the fields of this statement are ill-formed and cannot be processed properly; may be due to invalid characters or delimiters which are out of place. Both ASM and MAC share common roots, and, for some reason, this description was left out of the ASM manual. It usually means there is some invisible character in the line, such as a NULL, and the fix is to delete the line and retype it. Note that it is possible for the line either before or after the flagged line to actually have the offending character. So, it may save some time to simply retype all three lines... --Frank 28-Jul-84 12:08:48-MDT,728;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 28 Jul 84 12:08:43-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 28 Jul 84 10:07 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 28 Jul 84 10:00 EDT Date: 28 Jul 1984 07:57 MDT (Sat) Message-ID: From: Richard Conn To: William C. Wells Cc: info-cpm@Brl-Aos.ARPA Subject: ZCPR3 and CP/M 3.0 In-reply-to: Msg of 26 Jul 1984 20:12-MDT from wcwells%ucbopal.CC at Berkeley (William C. Wells) Good point ... I wasn't aware of it. Thanks for the note. Have you tried doing this or do you intend to? Rick 29-Jul-84 06:08:54-MDT,642;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 29 Jul 84 06:08:51-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 29 Jul 84 7:41 EDT Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp; 29 Jul 84 7:36 EDT Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 29 Jul 84 4:28-PDT Date: 27 Jul 84 18:39:06-PDT (Fri) To: info-cpm@Brl.arpa From: decvax!ittvax!dcdwest!sdcsvax!sdccs6!loral!simard@Ucb-Vax.arpa Subject: cmsg cancel <317@loral.UUCP> Article-I.D.: loral.324 -- Ray Simard Loral Instrumentation, San Diego {ucbvax, ittvax!dcdwest}!sdcsvax!sdccsu3!loral!simard 30-Jul-84 07:47:04-MDT,4546;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 30 Jul 84 07:46:50-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 30 Jul 84 8:46 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 30 Jul 84 8:44 EDT Date: 30 Jul 1984 06:44 MDT (Mon) Message-ID: From: Richard Conn To: info-cpm@Brl-Aos.ARPA Cc: rconn@Simtel20.ARPA Subject: ZCPR3 Phase 2 ... ... is coming along quite nicely. It now includes DPROG, which stands for Device PROGrammer. Under ZCPR2, we had CONFIG and TINIT which were nice for programming a TVI950. Under ZCPR3, BOTH OF THESE are replaced by one 3K interpreter called DPROG, and DPROG can program any terminal or printer. DPROG is a complete programming language in its own right. You can define words to it (a word is a symbol up to 16 characters long) which contain any combination of output format control instructions and text strings and references to other words (words can be nested up to 128 levels deep). Once a word is defined, it can be named in an output line, and its definition (including format controls) will be translated and output to either your console, printer, or punch device. For example: ; ; Sample DPROG programming file ; ; Define Basic Words -esc (%c) "\E" ; the escape character -ctrly "^Y" ; the character control-Y -test (Char: %c %x %d\n) ; character test format -normal_form (%c) ; normal single-character output format ; ; Use Words ; "This is a test\n" test "ABC" normal_form "\nEnd of Test" The output from the execution of the output line will be: This is a test Char: A 41 65 Char: B 42 66 Char: C 43 67 End of Test Used in conjunction with both format definitions (where they are output literally) and quoted strings (where they are output according to the current format definition), the following escape sequences apply: ^c Define control character (2-char sequence) \b Backspace char \d Delete char (DEL) \e Escape char (ESC) \l Line Feed Char (LF) \n New Line char (CRLF pair) \r Carriage Return char (CR) \t Tab char (TAB) \# Numeric value (forms are \d for decimal, \dH for hex, \dq for octal, \dB for binary: \1, \245, \33h, \0feH, \111b, \77q, etc) Additionally, the format expression is of the form () where can contain any character sequence as well as recognize the following output directives: %c Output chars as ASCII characters %d Output chars as floating decimal ASCII chars %x Output chars as 2 hex ASCII chars %2 Output chars as 2 decimal ASCII chars %3 Output chars as 3 decimal ASCII chars Any text can surround these output directives, and each directive can be used as many times as desired in a format expression. Once a format expression is given, it is used until a new expression is defined. For example: (%x %d ) "\12\10hA" (%c) "\12\10hA" will output: 0C 12 10 16 41 65 ^L^PA where ^L and ^P are the ASCII control-L and control-P characters. Finally, to make all of this complete, you can direct output to the console, printer, or punch at any time (for programming whatever device you want to program), there are debugging commands (pause to examine output, dump word definition table, dump format expression), and you can set up as many *.DPG files that you want to program a variety of functions. DPROG is a true ZCPR3 utility, and it searches the path for the *.DPG files, so you can store all of your useful programs in the ROOT directory and DPROG will find them. DPROG is used by issuing a command of the form: DPROG filename.typ <-- program from filename.typ DPROG filename <-- program from filename.DPG DPROG <-- program from STD.DPG I currently have 6 different files to program my TVI950 for working with assemblers, C, Pascal, dBASE II and Multiplan, Word Star and Starindex, and standard definitions, and a 7th program file for a TVI 970 (still being tested). DPROG, of course, can be used within an alias, ZEX command file, or any other ZCPR3 environment. For instance, the following Word Star alias is reasonable: IF NEC=$2 DEV L NEC <-- assign printer WSN $1 <-- run NEC version of WS ELSE DEV L TTY <-- assign printer DPROG CORRESP <-- program printer for correspondence WS $1 <-- run proper version of WS FI And so on ... comments? Rick 30-Jul-84 11:10:15-MDT,1169;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 30 Jul 84 11:10:04-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 30 Jul 84 11:25 EDT Received: From xerox.arpa.ARPA by BRL-AOS via smtp; 30 Jul 84 11:24 EDT Received: from Muscat.ms by ArpaGateway.ms ; 30 JUL 84 08:22:36 PDT Date: Mon, 30 Jul 84 11:20 EDT From: leisner.henr@XEROX.ARPA Subject: Re: C features In-reply-to: "hplabs!tektronix!orca!iddic!rickc@UCB-VAX.ARPA's message of 24 Jul 84 9:52:07 PDT (Tue)" To: hplabs!tektronix!orca!iddic!rickc@UCB-VAX.ARPA cc: info-cpm@BRL.ARPA Rick, I never used the floating point support on BDS but it looked cludged (not part of the base system, it looked like an addon. Aztec provides true floating point support, along with a slew of scientific routines (trig functions, log functions, etc.). If you have any questions in particular, feel free to ask. Like I said, Aztec looks like ( and is advertised as) a full Unix compatible C without bit fields, BDS is a wonderfully fast compiler with limited capability for large scale software projects. It is fine for small projects. Marty 30-Jul-84 11:56:33-MDT,855;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 30 Jul 84 11:56:26-MDT Received: From brl-vgr.arpa.ARPA by AMSAA via smtp; 30 Jul 84 13:15 EDT Received: from usc-isid.arpa by BRL-VGR.ARPA id a027291; 30 Jul 84 13:14 EDT Date: 30 Jul 1984 13:12-EDT Sender: ABN.ISCAMS@USC-ISID.ARPA Subject: Re: ? ASM S error flag From: ABN.ISCAMS@USC-ISID.ARPA To: Hirst.rx@XEROX.ARPA Cc: Cargo@HI-MULTICS.ARPA, info-cpm@BRL-VGR.ARPA Message-ID: <[USC-ISID.ARPA]30-Jul-84 13:12:07.ABN.ISCAMS> In-Reply-To: The message of 30 Jul 84 17:56:36+0100 (Monday) from Hirst.rx@XEROX.ARPA Ken (et al), Yes, I believe LASM is the same as LINKASM by Christensen. It has, as I recall from the .ASM notes, been upgraded somewhat. Sure do work good, yep. Regards, David Kirschbaum Toad Hall (ABN.ISCAMS@USC-ISID) 30-Jul-84 11:57:00-MDT,651;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 30 Jul 84 11:56:56-MDT Received: From brl-vgr.arpa.ARPA by AMSAA via smtp; 30 Jul 84 13:06 EDT Received: from xerox.arpa by BRL-VGR.ARPA id a027213; 30 Jul 84 13:07 EDT Received: from GreeneKing.ms by ArpaGateway.ms ; 30 JUL 84 10:05:57 PDT Date: 30 Jul 84 17:56:36+0100 (Monday) From: Hirst.rx@XEROX.ARPA Subject: Re: ? ASM S error flag In-reply-to: <[USC-ISID.ARPA]27-Jul-84 16:59:41.ABN.ISCAMS> To: ABN.ISCAMS@USC-ISID.ARPA cc: Cargo@HI-MULTICS.ARPA, info-cpm@BRL-VGR.ARPA David, Is LASM the same as LINKASM by Ward Christensen Ken 30-Jul-84 14:19:12-MDT,1418;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 30 Jul 84 14:19:05-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 30 Jul 84 15:00 EDT Received: From lll-mfe.arpa.ARPA by BRL-AOS via smtp; 30 Jul 84 14:58 EDT Date: Mon, 30 Jul 84 11:50 PDT From: Maron@LLL-MFE.ARPA Subject: C features: BDS-C supporter To: info-cpm@brl.arpa I tend to disagree that BDS-C is useful for only small projects. I'm not sure what we want to define small as but I have written a large specialized database program in BDS-C just fine. I did not need full floating point, in fact what I did need I wrote directly in C because the full floating-point hack that BDS-C does have was too much for me. The program was so big (tell me how big is big, etc. joke) that I run it as two co-routine which cross chain each other. There is the main routine with lots of routines and fairly small in memory data and the sort (co)routine which is small but requires (for efficiency) lots of in memory data. Whereas BDS-C is not a good as other C's I've used (such as Lattice-C on the IBM-PC) I think it is great for CP/M-80 for (1) price, (2) speed (3) features. I have written a cross assembler (6502) in BDS-C, a terminal concentrator interface, and various other utilities-all just fine. There are just a few features I wish I could inspire Leor to put in but... --Neil Maron 30-Jul-84 15:26:28-MDT,1646;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 30 Jul 84 15:26:20-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 30 Jul 84 16:43 EDT Received: From ucb-vax.arpa.ARPA by BRL-AOS via smtp; 30 Jul 84 16:45 EDT Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.33) id AA18512; Mon, 30 Jul 84 13:43:10 pdt Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.14/4.23.2) id AA08977; Mon, 30 Jul 84 13:45:06 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.23.2) id AA11166; Mon, 30 Jul 84 13:20:38 pdt Date: Mon, 30 Jul 84 13:20:38 pdt From: William C. Wells Message-Id: <8407302020.AA11166@ucbopal.CC.Berkeley.ARPA> To: RCONN@SIMTEL20.ARPA Subject: Re: ZCPR3 and CP/M 3.0 Cc: info-cpm@brl.ARPA In reply to: Date: 28 Jul 1984 07:57 MDT (Sat) Message-Id: From: Richard Conn To: wcwells@ucbopal (William C. Wells) Cc: info-cpm@brl Subject: ZCPR3 and CP/M 3.0 In-Reply-To: Msg of 26 Jul 1984 20:12-MDT from wcwells%ucbopal.CC at Berkeley (William C. Wells) Good point ... I wasn't aware of it. Thanks for the note. Have you tried doing this or do you intend to? Rick I have not tried applying the RSX to a CP/M 2.2 program yet. I am more of an applications person than I am a ASM hacker. Anybody want to try attaching the RSX to some of the ZCPR3 programs to see if they will work under CP/M 3.0 without ZCPR3 ? Bill wcwells@BERKELEY.ARPA, WCWELLS@UCBJADE.BITNET, ucbvax!wcwells 31-Jul-84 04:36:48-MDT,819;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 31 Jul 84 04:36:44-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 31 Jul 84 6:12 EDT Received: From ucb-vax.arpa.ARPA by BRL-AOS via smtp; 31 Jul 84 6:04 EDT Received: by UCB-VAX.ARPA (4.28/4.33) id AA01150; Tue, 31 Jul 84 03:03:21 pdt Received: by HP-VENUS id AA19921; Mon, 30 Jul 84 19:34:58 pdt Message-Id: <8407310234.AA19921@HP-VENUS> From: hplabs!iddic!rickc@Ucb-Vax.ARPA To: info-cpm@BRL.ARPA Received: from iddic.uucp by tektronix ; 30 Jul 84 08:43:33 PDT Subject: cpm info Date: Mon Jul 30 08:38:44 1984 Persons: Does any method exist for people on USENET to gain access to the cp/m archives at SIMTEL20? Thanks, Rick Coates . . .tektronix!iddic!rickc 31-Jul-84 04:37:56-MDT,1872;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 31 Jul 84 04:37:47-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 31 Jul 84 6:12 EDT Received: From xerox.arpa.ARPA by BRL-AOS via smtp; 31 Jul 84 6:07 EDT Received: from CheninBlanc.ms by ArpaGateway.ms ; 31 JUL 84 02:37:20 PDT Date: 30 Jul 84 07:44:03 PDT (Monday) From: Chapman.ES@XEROX.ARPA Subject: Problem with Creating a file To: info-cpm@BRL-AOS.ARPA cc: Chapman.ES@XEROX.ARPA Last weekend, I needed to do a quick and dirty test of transfering data from one computer to another over an RS232 direct hookup. So I entered DDT and started hand assembling a short job to create a file, read the appropriate port, and store the data in the file. Since I wasn't sure the data would come over (hardware parameters needed to be futzed with), I used the debugger breakpoint facilities to watch what was happening. I found that the FCB at 5? (Hex) (I'm at work with no documentation, so I don't remember the number off the top of my head, but it's the default FCB) would be set up properly according to the documentation by the appropriate BDOS Create file call, but after the first sector of data had been stored, the "number of sectors used in current extent" byte was garbage. Manually reseting it to 1 and proceeding allowed me to capture the rest of my data. The byte was properly incremented thereafter. Any ideas what's going on? Is it an artifact of using the Debugger? (If that were so, I might expect the byte to keep getting clobbered.) I have used my system (an Imsai 8080, running CP/M 2.2) with many standard programs with no problems. I don't usually bother to write my own, but I do when I have to. I followed the documentation in the CP/M manuals for making BDOS calls correctly, to the best of my knowledge. Cheryl 31-Jul-84 05:06:30-MDT,936;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 31 Jul 84 05:06:25-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 31 Jul 84 6:12 EDT Received: From xerox.arpa.ARPA by BRL-AOS via smtp; 31 Jul 84 6:08 EDT Received: from CheninBlanc.ms by ArpaGateway.ms ; 31 JUL 84 02:37:28 PDT Date: 30 Jul 84 07:54:54 PDT (Monday) From: Chapman.ES@XEROX.ARPA Subject: Re: SHSET In-reply-to: To: Richard Conn cc: Chapman.ES@XEROX.ARPA, info-cpm@BRL-AOS.ARPA Rick As I understood the description, the choice of what to do with the next command depended on the previous command being CORRECT, executed, and the PROGRAM returning a completion code. This is quite different from deciding what to do if the COMMAND LINE itself is in error. In most cases you would want to abort, fix up the command line and restart. Cheryl 31-Jul-84 07:01:14-MDT,1624;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 31 Jul 84 07:01:07-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 31 Jul 84 8:19 EDT Received: From simtel20.arpa.ARPA by BRL-AOS via smtp; 31 Jul 84 8:15 EDT Date: 31 Jul 1984 06:14 MDT (Tue) Message-ID: From: Richard Conn To: Chapman.ES@XEROX.ARPA Cc: Richard Conn , info-cpm@Brl-Aos.ARPA Subject: SHSET In-reply-to: Msg of 30 Jul 1984 08:54-MDT from Chapman.ES at XEROX.ARPA Yes, SHSET assumes that the command line is correct. Once ZCPR3 decides to invoke a shell, the shell is processed like any other command line, so your concern would be addressed by an Error Handler should the command line loaded by SHSET be incorrect. Current Error Handlers do not have a provision for aborting a shell, so your point is well-taken. A new error handler, say ERROR5, should be created which can abort a shell as well as redirect execution of the command line (like current error handlers do). Of course, if the SHSET command line includes CMD, then when the conventional error handler is invoked, the user could instruct execution to proceed to CMD, at which point the user could issue a SHCTRL POP command to clear the shell stack. For that matter, a convnetional error handler will simply allow the user to issue the SHCTRL POP command anyway. Hence, your problem is solved by using a conventional error handler. I think I will still add ERROR5, which will be able to deal with the shell stack. Rick 31-Jul-84 13:01:03-MDT,739;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 31 Jul 84 13:00:58-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 31 Jul 84 14:25 EDT Date: 31 Jul 1984 10:50 MDT (Tue) Message-ID: Sender: KPETERSEN@Simtel20.ARPA From: Keith Petersen To: "Paul L. Kelley" Cc: Info-Cpm@Amsaa.ARPA Subject: Setup program for Gemini-10 Printer In-reply-to: Msg of 29 Jul 1984 21:47-MDT from Paul L. Kelley Thanks for contributing GEMSET10 for the Gemini-10 printer, Paul. Sorry I neglected to give credit to you when I announced the files to Info-Cpm. Keep up the good work! --Keith 31-Jul-84 13:04:14-MDT,1607;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 31 Jul 84 13:04:01-MDT Received: From brl.arpa.ARPA by AMSAA via smtp; 31 Jul 84 14:08 EDT Received: From utexas-20.arpa.ARPA by BRL-AOS via smtp; 31 Jul 84 13:21 EDT Date: Tue 31 Jul 84 11:06:55-CDT From: John Otken Subject: Re: Problem with Creating a file & ASM "S" error To: Chapman.ES@XEROX.ARPA, info-cpm@BRL-AOS.ARPA In-Reply-To: Message from "Chapman.ES@XEROX.ARPA" of Mon 30 Jul 84 07:44:03-CDT What you probably needed to do was to clear the CR field of the FCB after the MAKE BDOS function call. This is documented under the OPEN FILE function. Becareful with statements such as "according to the documentation". My CP/M book sez the following for the MAKE FILE function: "The FDOS creates the file and initializes both the directory and the main memory value to an empty file. [...] The make file function has the side effect of activating the FCB and thus a subsequent open is not necessary." Well, I dont know about you but *initializes ... the main memory value* doesn't mean anything to me. And *activating the FCB* probably means what it meant for the OPEN function which is that you still need to clear the CR field. One thing is for sure, DDT is NOT responsible for messing with the FCB unless, of course, you told him to do it. While on the subject of DR docs... Another way to get the "S" error from ASM is to use an instruction mnemonic as a label. ALL INFORMATION PRESENTED HERE IS PROPRIETARY TO JOHN OTKEN [sic] ------- 31-Jul-84 13:43:56-MDT,1983;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 31 Jul 84 13:43:48-MDT Received: From simtel20.arpa.ARPA by AMSAA via smtp; 31 Jul 84 14:24 EDT Date: 31 Jul 1984 10:45 MDT (Tue) Message-ID: Sender: KPETERSEN@Simtel20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: GEMSET10 setup program for Gemini-10 printer GEMSET10 is a version of MXSET by Simon J. Ewins set up for a Gemini-10 printer. The following has been done - 1. Home printhead command removed. 2. Carriage return and linefeed not sent to printer after commands. 3. Proportional spacing command added. 4. 12 cpi command added. 5. Start column command added. 6. Lines per inch command added. 7. Formfeed command added. 8. Optional printer status checking added. 9. Header line position command added. 10. Eliminated stack imbalance and improper use of PRINT##. Here is a short review of MXSET: MXSET Rev. 1.2 by Simon J. Ewins, Toronto, Ontario, Canada. This program will set/reset all of the major functions of the Epson MX-80 printer. The program uses Z80 Zilog mnemonics and calls are made to Richard Conn's excellent SYSLIB.REL file. Microsoft's M80 macro assembler is needed for assembly of this file as well as the SYSLIB file. The GEMSET files are available on SIMTEL20 as: Filename Type Bytes Sectors CRC Directory MICRO: GEMSET10.COM.1 COM 2816 22 = 16H CE53H GEMSET10.HEX.1 ASCII 7933 62 = 3EH 497EH GEMSET10.MAC.1 ASCII 7127 56 = 38H 0B96H GEMSET10.MSG.3 ASCII 549 5 = 5H B324H The original MXSET12 files are also available for Epson owners: Filename Type Bytes Sectors CRC Directory MICRO: MXSET12.COM.1 COM 2176 17 = 11H EED5H MXSET12.HEX.1 ASCII 6133 48 = 30H 2923H MXSET12.MAC.1 ASCII 4068 32 = 20H DB1DH