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 pa