1-Jul-85 00:22:42-MDT,2173;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 1 Jul 85 00:20:00-MDT Received: from simtel20.arpa by AMSAA.ARPA id a020652; 1 Jul 85 1:42 EDT Date: Sun 30 Jun 85 23:43:37-MDT From: Rick Conn Subject: VMENU37 To: info-cpm@AMSAA.ARPA Re the recent upload to VMENU, two items: 1. The message said that VMENU is now a "true shell"; VMENU has always been a ZCPR3 shell since the Z3 release a year ago. An improved technique, which decreases the shell installation time by about 50%, is now being employed in shell designs under Z3. This technique has the shell look into the CL buffer to see if anything follows, and, if not, the shell proceeds to execute. The original design did not do this, simply returning to the OS and letting Z3 load and invoke the shell as a shell almost immediately. This caused a second, unnecessary load when the shell was first installed. See Chapter 6 (on shells) and Chapter 5 (on menu subsystems) in ZCPR3: The Manual for a lot more detail. Also see the shell manipulation routines in Z3LIB. 2. I have not yet been informed by Echelon that VMENU 3.7 has been approved. As such, I recommed that users approach with care. One of the biggest differences between the version control of Z2 and Z3 is that Echelon plays the role of configuration manager on all Z3 software releases. Users are encouraged to change the software if they like, but releases are to be done thru Echelon. There is a file checkout mechanism, which insures that people aren't wasting effort by working on the same file at the same time, and Echelon runs tests on the released files before it approves the release. While this does not guarantee that no bugs creep in, it helps a lot. I'm no exception to this rule -- I currently have SYSLIB, Z3LIB, and VLIB checked out, and Echelon will test the software after I check it back in. Rick PS If the situation with VMENU has gotten out of hand, it is quite possible that the uploaded VMENU 3.7 is not the same as that which will be released. Al Dunsmuir currently has VMENU checked out. ------- 1-Jul-85 04:32:41-MDT,715;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 1 Jul 85 04:28:15-MDT Received: from simtel20.arpa by AMSAA.ARPA id a020953; 1 Jul 85 6:01 EDT Date: Mon, 1 Jul 1985 04:02 MDT Message-ID: From: CSTROM@SIMTEL20.ARPA Subject: CCPM driver needed To: INFO-CPM@AMSAA.ARPA cc: CSTROM@SIMTEL20.ARPA I would appreciate any pointers to hard disk driver code for a Konan DGC-100/Rodime 27Mb combination. I am in the initial stages of a do-it-yourself, but have less than complete confidence in my abilities along these lines! Oh, yes, I am doing this for Concurrent CP/M, not 8-bit, on a CompuPro system. -Charlie 1-Jul-85 07:51:15-MDT,1598;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 1 Jul 85 07:49:28-MDT Received: from xerox.arpa by AMSAA.ARPA id a024383; 1 Jul 85 8:56 EDT Received: from Muscat.ms by ArpaGateway.ms ; 01 JUL 85 05:56:41 PDT Date: Mon, 1 Jul 85 08:56 EDT From: leisner.henr@XEROX.ARPA Subject: Re: C compilers for cpm In-reply-to: <1484@trwrba.UUCP> To: "Mark A. Ryding" cc: info-cpm@AMSAA.ARPA Message-ID: <850701-055642-1670@Xerox> Mark, I'm currently using Manx Aztec C on a CP/M system to write control code for xerographic devices within Xerox. I've had good results with it (it is almost a full implementation minus bit fields). I currently support interrrupts, but you'll have to write your own context saving mechanism (just save all the registers). Floats may be a problem within interrupt handlers, I don't know if you want to compute there. Supposedly, it is fairly easy to generate rommable code with the compiler. They support an initialized and uninitialized data array with their linker. However, doing these things are feasible but often a pain. The first time is always the hardest. By mixed language programming, I assume you mean support for assembly language. You can imbed assembly language within your C code and also write assembly language subroutines if you maintain the Aztec calling conventions. In addition, I found the code generation mechanism isn't too bad. I also use Aztec to support 6502 applications, but that is a different story altogether. Marty 1-Jul-85 10:46:21-MDT,590;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 1 Jul 85 10:44:36-MDT Received: from usc-isi.arpa by AMSAA.ARPA id a000492; 1 Jul 85 12:04 EDT Date: 1 Jul 1985 12:00:49 EDT Subject: Re: VMENU37 From: Steve Noland To: Rick Conn cc: info-cpm@AMSAA.ARPA In-Reply-To: (Message from "Rick Conn " of Sun 30 Jun 85 23:43:37-MDT) Note that the upload in question was for MENU 3.7, NOT VMENU 3.7, and the availability was first announced by Echelon in Z3NEWS 205. ------- 1-Jul-85 11:31:42-MDT,976;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 1 Jul 85 11:31:08-MDT Received: from mit-athena.arpa by AMSAA.ARPA id a001582; 1 Jul 85 12:55 EDT Received: from mit-priam (mit-priam.ARPA) by mit-athena (4.12/4.7) id AA29024; Mon, 1 Jul 85 12:56:41 edt Received: by mit-priam (4.12/4.7) id AA13106; Mon, 1 Jul 85 12:56:34 edt Date: Mon, 1 Jul 85 12:56:34 edt From: asp@MIT-ATHENA.ARPA Message-Id: <8507011656.AA13106@mit-priam> To: info-cpm@AMSAA.ARPA Subject: Kaypro 2 SIO interrupts Has anyone done anything using the SIO's interrupt capabilities to read characters from the serial port? What sort of things should I watch out for, and is it possible? I'm looking toward building a terminal emulator that gets around the character lossage most screen operations create at 1200bd. If anyone has done this already, I would very much like to hear from them. Thanks, Jim Aspnes (asp@mit-athena.ARPA) 1-Jul-85 21:08:21-MDT,1161;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 1 Jul 85 21:04:27-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a011298; 1 Jul 85 22:32 EDT Received: from usenet by TGR.BRL.ARPA id a013819; 1 Jul 85 22:16 EDT From: Mark Mallett Newsgroups: net.micro.cpm Subject: More on MIX editor Message-ID: <420@sii.UUCP> Date: 29 Jun 85 04:41:54 GMT To: info-cpm@AMSAA.ARPA I (also) bought a copy of the MIX editor for CP/M. I think that they have done a good job on this editor, excepting one slight lack which makes the product useless for me-- the editor does not know what to do with control characters in files that you edit. This includes such interesting characters as formfeeds and tabs. MIX will offer to convert LEADING tabs to spaces for you during editing, and back again when writing out the file, but to my way of thinking, this is not enough. If editing these control characters doesn't come up for you, MIX seems to be really good. I hope that they work on this problem so that I can use it, too. Mark Mallett decvax!sii!mem or ittvax!sii!mem 2-Jul-85 05:44:12-MDT,2039;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 2 Jul 85 05:42:19-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a012356; 2 Jul 85 6:59 EDT Received: from usenet by TGR.BRL.ARPA id a023551; 2 Jul 85 6:50 EDT From: John Blalock Newsgroups: net.micro.cpm Subject: Re: CPM 2.2 maximum disk storage space (?) Message-ID: <630@terak.UUCP> Date: 1 Jul 85 19:41:20 GMT To: info-cpm@AMSAA.ARPA > [] > I have a 10M byte hard disk running CPM 2.2. When I have 8M bytes > worth of files on my disk and then create another file, the new file > overwrites my directory. The maximum group number I could use is > 7FFh (which corresponds to 8M bytes) and the new file is allocated > group 0 which happens to be the directory area. > > A CPM book that I have states that the maximum storage space CPM 2.2 > supports is 16M bytes. Could somebody shed some light on this > discrepancy? > > I would appreciate any help. > > - Robert Ling. The maximum storage space depends on the block size your BIOS uses. CP/M allows up to 64K blocks, each block can be 1, 2, 4, 8, or 16K as I recall. An even more limiting feature (?) is only 16 blocks can be allocated to the directory. Assuming you use 2K blocks (32 MB disk capacity possible), you can have only 1024 directory entries... I hope this helps and, even tho I don't have the manuals here for reference, I think the numbers quoted are reasonably accurate. I'm currently in the process of hacking up my BIOS to add a couple of 8 MB disks and remember looking all this up in order to decide block size and determine my DPB. It sounds like you have an improperly defined DBP if your directory is getting wiped out. John Blalock, W7AAY uucp: ...{amd,decvax,hao,ihnp4,seismo}!noao!terak!jb phone: (602) 998-4800 us mail: Terak Corp., 14151 N. 76th St., Scottsdale, AZ 85260 \\\\\ -----> Soon to be part of CalComp, A Sanders Company 2-Jul-85 19:41:31-MDT,833;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 2 Jul 85 19:39:00-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a004936; 2 Jul 85 20:59 EDT Received: from usenet by TGR.BRL.ARPA id a016305; 2 Jul 85 20:53 EDT From: Peter Fales Newsgroups: net.micro.cpm Subject: CP/M-86 Software Message-ID: <189@ihlpl.UUCP> Date: 1 Jul 85 21:04:56 GMT To: info-cpm@AMSAA.ARPA Having recently acquired a CP/M-86 based computer, I am now looking for software. Does anyone out there know distributors that have good selections and prices for CP/M-86 software. Please respond to me, and if there is sufficient interest I will summarize to the net. Peter Fales UUCP: ...ihnp4!ihlpl!psfales work: (312) 979-7784 Indian Hill West, IW 1Z-243 5-Jul-85 05:52:46-MDT,911;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 5 Jul 85 05:48:18-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a000205; 5 Jul 85 7:17 EDT Received: from usenet by TGR.BRL.ARPA id a019758; 5 Jul 85 0:43 EDT From: Bill Randle Newsgroups: net.micro.cpm Subject: Re: Xerox 820-I micro documentation Message-ID: <372@tekred.UUCP> Date: 3 Jul 85 19:52:13 GMT To: info-cpm@AMSAA.ARPA Yes, there is also a users group for the 820-I and II. Contact Micro Cornucopia PO Box 223 Bend OR 97709 (503) 382-8048 They publish a monthly magazine with tips and features for the 820's, Big Board I&IIs, Kaypros, and some other "single board" computers. -Bill Randle Tektronix, Inc. tektronix!tekred!billr (uucp) tekred!billr@tektronix.csnet (CSnet) tekred!billr%tektronix@csnet-relay.ARPA (ARPA) 5-Jul-85 08:26:42-MDT,1353;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 5 Jul 85 08:25:06-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a002780; 5 Jul 85 9:49 EDT Received: from usenet by TGR.BRL.ARPA id a027701; 5 Jul 85 9:44 EDT From: Daniel Faigin Newsgroups: net.wanted,net.lang.pascal,net.micro.cpm,net.unix Subject: Pascal/MT+ Compiler for Unix(tm) Message-ID: <2114@sdcrdcf.UUCP> Date: 3 Jul 85 16:08:59 GMT Xref: seismo net.wanted:7129 net.lang.pascal:344 net.micro.cpm:4609 net.unix:5274 To: info-cpm@AMSAA.ARPA Does anybody know if there is a version of the Pascal/MT+ Compiler (tm Digital Research) available for the Unix(tm) Operating System, preferably 4.2 BSD. It would make a development team's life much easier is there was. PLEASE, PLEASE reply via Email if you have ANY information. Daniel. -- UUCP: {akgua allegra ihnp4 hplabs sdcsvax trwrb cbosgd}!sdcrdcf!faigin ARPA: sdcrdcf!faigin@UCLA-LOCUS.ARPA --or-- sdcrdcf!faigin@LOCUS.UCLA.EDU W: SDC, 2500 Colorado MD 52-46; Santa Monica CA 90406; (213) 820-4111 x6493 H: 11743 Darlington Avenue #9; Los Angeles CA 90049; (213) 826-3357 Don't have good ideas if you aren't willing to be responsible for them. -- A. J. Perlis, SIGPLAN 17:9 Sept 1982 5-Jul-85 14:32:08-MDT,757;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 5 Jul 85 14:30:06-MDT Received: from brl-aos.arpa by AMSAA.ARPA id a011160; 5 Jul 85 15:57 EDT Received: from mit-mc.arpa by AOS.BRL.ARPA id a011679; 5 Jul 85 15:51 EDT Received: from MIT-EECS by MIT-MC.ARPA via Chaosnet; 5 JUL 85 15:35:26 EDT Date: Fri 5 Jul 85 15:34:49-EDT From: Andrew Moore Subject: Wanted: Apple-Cat BYE To: info-cpm@MIT-MC.ARPA I'm looking for a BYE program overlay for the Apple-Cat ][ modem that supports 1200 bps. So far I have found only 300 bps overlays, no 300/1200 overlays. Please mail me directly if you know of this overlay. -drew T.MOORE%MIT-EECS@MIT-MC.ARPA ------- 5-Jul-85 15:49:08-MDT,685;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 5 Jul 85 15:48:31-MDT Date: Fri, 5 Jul 85 17:14:54 EDT From: Dave Towson (info-cpm-request) To: info-cpm@AMSAA.ARPA Subject: info-cpm-request on vacation Fellow CP/Mers - I will be on vacation the week of 8 July. As of now, the info-cpm-request mailbox contains no unread mail. If the delivery of mail to any info-cpm readers becomes flaky while I am away, some of you may receive reject messages from various mail handlers. I will correct any such problems when I return. In the mean time, please grin and bear it. Thanks. Dave 6-Jul-85 00:23:54-MDT,1994;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 6 Jul 85 00:19:14-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a012669; 6 Jul 85 1:47 EDT Received: from usenet by TGR.BRL.ARPA id a017137; 6 Jul 85 1:41 EDT From: GEDDIS Newsgroups: net.lang.forth,net.micro.cpm Subject: March 1981 Microcomputing Magazine Message-ID: <768@burl.UUCP> Date: 5 Jul 85 10:42:28 GMT Xref: seismo net.lang.forth:281 net.micro.cpm:4610 To: info-cpm@AMSAA.ARPA [did they ever fix the first-line bug?] Before I say anything (while I still have your attention), please note that I do not have access to the net, much less this newsgroup. I have mailed this artical to a good friend who has posted it for me (And I don't think she reads net.lang.forth or net.micro.cpm). So please *DON'T* use your 'f'-key or your 'r'-key to reply to this artical, but reply instead by replacing the "burl!smg" at the end of this artical's path with "burl!bu-3b5!wjb". Many thanks. Microcomputing put out a couple of articals once on how to write your own FORTH interpreter/compiler, written for a CP/M machine in 8080 assembly language. Someone with whom I've since lost touch gave me copies of the articals, which I have been using as a guide to do an implementation on my C64. I've gotten a lot of the work done, but right at the end of the second artical (the one about the compiler), I discovered that there were a couple of listings that came after the textual part of the artical that my friend neglected to give to me. Which brings me to the point of this posting: If anybody has hardcopies, on-line listings, or can point me to where I can get copies of those listings, I would appreciate it if you would get in touch with me at {ihnp4, among other machines}!burl!bu-3b5!wjb adTHANKSvance --Bill -- Sharon Geddis -- 919-228-4913 (Cornet 291) ...![ floyd sb1 mhuxv ]!burl!smg 6-Jul-85 02:24:46-MDT,949;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 6 Jul 85 02:22:35-MDT Received: from su-star.arpa by AMSAA.ARPA id a012783; 6 Jul 85 3:58 EDT Date: 6 Jul 85 00:52:00 PDT From: "R. Meier" Subject: kermit To: info-cpm Reply-To: "R. Meier" Help, I have been unable to get access to the kermit files on columbia-20 and suspect that there have been some changes recently to the access procedures. When I login anonymous and try the command cd ps:, it says that the directory does not exist. It will accept cd ps:, but when I do a dir it responds that ? is not found. Can anyone out there tell me (and possibly others?) how the current versions of kermit for the ibm-pc (ms-dos), and apple ][+ (Dos 3.3 and CP/M 2.2) can be obtained? Thank you, Bob Meier (rmeier@star%su-sierra) ------ 6-Jul-85 03:14:39-MDT,704;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 6 Jul 85 03:11:56-MDT Received: from su-star.arpa by AMSAA.ARPA id a012838; 6 Jul 85 4:38 EDT Date: 6 Jul 85 01:25:00 PDT From: "R. Meier" Subject: simtel20 To: info-cpm Reply-To: "R. Meier" Help, I have been unable to connect to simtel20 recently. The command quote stat returns mode s, stru f, type a n, the data connection is CLOSED. A cd micro: command is accepted, but a dir command produces an empty list. How can the data connection be Openned? Thank you, Bob (rmeier@star%su-sierra.arpa) ------ 6-Jul-85 06:19:06-MDT,846;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 6 Jul 85 06:14:59-MDT Received: from mit-charon.arpa by AMSAA.ARPA id a000418; 6 Jul 85 7:51 EDT Received: by mit-charon (4.12/4.7) id AA02239; Sat, 6 Jul 85 07:54:40 edt Message-Id: <8507061154.AA02239@mit-charon> To: info-cpm@AMSAA.ARPA Subject: Re: Kermit Reply-To: holtzman@mit-athena.mit.edu Date: 06 Jul 85 07:54:07 EDT (Sat) From: "Henry N. Holtzman" Columbia moved kermit from cucs20 (columbia-20) to cu20b a while back when cu20b joined the net. For a while they maintained both, but I guess they have removed it from cucs20. ftp to cu20b, login anonymous, and have fun with kermit: One small problem, however. Due to phys. plant maintenance, cu20b will be down this weekend. -Hank 6-Jul-85 12:39:27-MDT,823;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 6 Jul 85 12:38:53-MDT Received: from usc-isi.arpa by AMSAA.ARPA id a001279; 6 Jul 85 14:13 EDT Date: 6 Jul 1985 14:13:49 EDT From: DKREBILL@USC-ISI.ARPA Subject: PD Info Rqst To: info-cpm@AMSAA.ARPA cc: krebill@ARDC.ARPA To assist some folks at USMA who do not have net access, I am asking for info/documentation/source code on the following packages, all of which are beleived to be in the public Domain: (1) XLISP [We have tracked down binaries for this but need source] (2) The cardboard inference engine--source is believed to be in pascal or c. (3) Power ---A user here has this in a power.com version only, with no documentation. Thanks in advance for any pointers/help/assistance!...Dan ------- 6-Jul-85 19:28:24-MDT,3611;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 6 Jul 85 19:24:29-MDT Received: from office-2.arpa by AMSAA.ARPA id a001824; 6 Jul 85 20:55 EDT Date: 6-Jul-85 17:55 PDT From: Alan Bomberger Subject: More on AMPRO Little board BIOS To: info-cpm@AMSAA.ARPA Message-ID: Some problems never seem to get fixed. My wife has been using an Ampro Little Board for over a year now for a writing project. I put together a system including TEAC 55B and 55F drives for her. One of the chronic problems with the Little Board and the TEAC drives has been intermittant write errors. The latest version (received a few weeks ago) of their BIOS shows that in the past the problem may even have been solved. It ain't today. The problem: How long do you wait for the heads to settle. The controller has a really good idea that 1 second is good if the motor was not running (and the heads are not loaded) but Ampro has tried several attempts at optimization which are all failures. Katie started having trouble with bad writes after file saves from Magic Wand. MW always writes to a brand new file which it opens before it allows any editing. There are no disk reads involved as output to a new file only requires allocation of blocks. So this problem is the same one observed with MODEM transfers where the writes are after pauses long enough for the motors to stop. Well Katie had been running on an old version of the BIOS which clearly had the problem as there was almost no wait time for the motor to start. The latest release "fixes" the problem by waiting for several revolutions (requires several good reads of sector id of the same id ) after starting the motor. Still broke! Apparently older TEAC drives slow down (longer head load times) as his started to become a burden just this week. I got out my trusty AM radio and tuned into a good buzz and started poking around with DU. When writing to the TOP side (the side with the loading head) nothing starts to happen until the head slams to the surface. In this case the current 3 revolutions for the heads to settle is quite adaquate. On the BOTTOM side the ID reads happen before the flux in the head solenoid had even started to build up. The write operation starts even before the head is loaded and the head slams to the surface in the middle of the write. The head hitting the disk rattles the disk and completely destroys any synchronization that may have been achieved before the write began, result: BDOS BAD SECTOR. Two weeks ago the head came down either before the write started or AFTER the write ended!. The only thing that works ALL the time is the technique used in a very early BIOS version. Turn on the bit in the Disk Controller commands that causes a 1 second pause whenever the motor is started. If the motor is already running, the pause is not executed. 1 second is not a very long time to wait to insure that your data gets written on the disk! The current BIOS just isn't good enough! So maybe my drives are a little slow! Big deal! The patch is really very easy. The MOTOR ON routine has a few READ ID commands in it for Ampro's "optimized" timing. Simply patch on the Motor Pause bit for these READ ID operations and all your troubles are over. Peace !! I hope that someone is saved an aggravating day by reading this. Incidentally I bought a TEAC 53B drive and like it a lot. No head loading and very quiet seeks! 8-Jul-85 10:17:00-MDT,867;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 8 Jul 85 10:12:41-MDT Received: from ucb-vax.arpa by AMSAA.ARPA id a015916; 8 Jul 85 11:28 EDT Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.48) id AA01613; Mon, 8 Jul 85 08:26:02 pdt Received: from ucbamber.CC.Berkeley.ARPA (ucbamber.ARPA) by ucbjade.CC.Berkeley.ARPA (4.19/4.36) id AA13001; Mon, 8 Jul 85 08:29:26 pdt Received: by ucbamber.CC.Berkeley.ARPA (4.19/4.35.3) id AA05434; Mon, 8 Jul 85 08:30:58 pdt Date: Mon, 8 Jul 85 08:30:58 pdt From: swillett%ucbamber.CC@ucb-vax.ARPA Message-Id: <8507081530.AA05434@ucbamber.CC.Berkeley.ARPA> To: DKREBILL@USC-ISI.ARPA, info-cpm@AMSAA.ARPA Subject: Re: PD Info Rqst Cc: krebill@ARDC.ARPA Power is definately not in the public domain - it is a commercial program 8-Jul-85 14:44:46-MDT,1227;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 8 Jul 85 14:41:45-MDT Received: from ames-vmsb.arpa by AMSAA.ARPA id a023105; 8 Jul 85 15:00 EDT Date: 8 Jul 85 11:49:00 PDT From: max.hartman@AMES-VMSB.ARPA Subject: --- info request --- To: info-cpm@AMSAA.ARPA Reply-To: max.hartman@AMES-VMSB.ARPA I would like information on the following: 1) Has anyone out there installed ZCPR3 on a Kaypro "luggable"? We couldn't do it. Some points: we DO NOT have the CP/M macro assembler, we tried assembling with the plain-vanilla assembler and a DIFFERENT macro ass- embler than was used in the installation instructions. Could this have been the problem? Other than that, we followed installation instructions as closely as possible. If you want more details from which to help us, please ask. 2) Does anyone know the format of a WordStar created file? I know some things: CR/LF pair ends a line, if the high-bit is set on the LF it ends the page, ctrl-S toggles the underlining. Can anyone out there tell me more info? 3) There is no third question. Thanks in advance, -Richard Hartman max.hartman@ames-vmsb ------ 8-Jul-85 16:34:01-MDT,729;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 8 Jul 85 16:31:06-MDT Received: from ames-vmsb.arpa by AMSAA.ARPA id a001755; 8 Jul 85 17:53 EDT Date: 0 0 00:00:00 PDT From: max.hartman@AMES-VMSB.ARPA Subject: --- Otrona Attache --- To: info-cpm@AMSAA.ARPA Reply-To: max.hartman@AMES-VMSB.ARPA Does anyone know how much an Otrona Attache would cost these days? (I have heard that the company is out of business, but that they are good machines.....) And/or where I might be able to get one? I am just looking, but might buy if I can find a good deal.... -Richard Hartman max.hartman@ames-vmsb P.S.: "good deal" changes w/ the current budget..... ------ 9-Jul-85 11:22:21-MDT,623;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Jul 85 11:21:12-MDT Received: from wpafb-info1.arpa by AMSAA.ARPA id a005550; 9 Jul 85 12:33 EDT Date: 9 Jul 85 08:03:00 EST From: "CPT.GREG.ELDER" Subject: I.C. Express To: info-cpm Reply-To: "CPT.GREG.ELDER" I'm thinking about ordering some 41256 RAM chips (150ns) from I.C. Express. They have an advertised price of $4.25. Has anyone done any business with this company or know anything good or bad about them? Thanks. -Greg ------ 9-Jul-85 12:25:23-MDT,965;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Jul 85 12:21:47-MDT Received: from simtel20.arpa by AMSAA.ARPA id a007098; 9 Jul 85 13:17 EDT Date: Mon, 8 Jul 1985 21:27 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: max.hartman@AMES-VMSB.ARPA Cc: Info-Cpm@AMSAA.ARPA Subject: Installing ZCPR3 on a Kaypro In-reply-to: Msg of 8 Jul 1985 12:49-MDT from max.hartman at AMES-VMSB.ARPA There is a complete ZCPR3 installation package for the Kaypro-10 available via FTP from SIMTEL20 as: Filename Type Bytes CRC Directory MICRO: K10ZCPR3.LBR.1 BINARY 79616 3DDCH The .LBR includes a Z80 assembler (presumably used for installing this package). I know nothing more about it. If you don't have access to Simtel20, you can get the file from my RCPM (313-759-6569). --Keith 9-Jul-85 13:09:06-MDT,387;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Jul 85 13:07:05-MDT Received: from lll-mfe.arpa by AMSAA.ARPA id a008169; 9 Jul 85 13:59 EDT Date: Mon, 8 Jul 85 22:00 PDT From: "Webb Mike"@LLL-MFE.ARPA Subject: MSDOS CATALOG PROG To: INFO-CPM@AMSAA.ARPA DOES ONE OF THESE EXIST FOR 'MSDOS'(I HOPE,I HOPE,I HOPE) MIKE 9-Jul-85 13:35:57-MDT,1121;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Jul 85 13:34:38-MDT Received: from nosc-gw by AMSAA.ARPA id a009364; 9 Jul 85 14:27 EDT Received: from marlin.ARPA by nosc.ARPA (4.17/4.7) id AA07341; Tue, 9 Jul 85 11:24:29 pdt Received: by marlin.ARPA (4.17/4.7) id AA02288; Tue, 9 Jul 85 11:27:59 pdt Date: Tue, 9 Jul 85 11:27:59 pdt From: "Joseph G. Grovhoug" Message-Id: <8507091827.AA02288@marlin.ARPA> To: max.hartman@AMES-VMSB.ARPA Subject: Re: --- Otrona Attache --- Cc: grovhoug%marlin@nosc.ARPA, info-cpm@AMSAA.ARPA Richard...Have used two Otrona Attaches [one configured 8:16] constantly during the past three years and, yes, they are good machines. Unfortun- ately Otrona went tits up a while back, but service is readily available from several independent sources. Suggest you contact Computer Systems of Marin, 301 Poplar St, Mill Valley, CA 94941 (415) 388-4805 re: avail- ability of Attaches. As of May they advertised 8:16 machines (new) for $1200. Good luck & Aloha, Jeff Grovhoug grovhoug@nosc 10-Jul-85 06:04:58-MDT,1784;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 10 Jul 85 06:02:24-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a000251; 10 Jul 85 7:29 EDT Received: from usenet by TGR.BRL.ARPA id a000490; 9 Jul 85 23:55 EDT From: John Blalock Newsgroups: net.micro,net.micro.cpm,net.periphs Subject: Followup to Xebec 1410 BIOS help wanted request Message-ID: <632@terak.UUCP> Date: 7 Jul 85 22:29:06 GMT Xref: seismo net.micro:11597 net.micro.cpm:4612 net.periphs:797 To: info-cpm@AMSAA.ARPA To follow up my earlier request to the net for help with sample CP/M-80 BIOS listings for adding a Xebec S1410 controller and two Shugart SA606 Winchester drives to my system with a CCS 2422 FDC, I got a few suggestions and comments that indicated others may be interested in doing the same thing but no specific help. Even so, I now have the hardware running with BIOS mods I hacked together and can verify that such a task is not impossible. The drives formatted to 8.2 MB each with no problems so far. Source information: (I have no connection, just satisfied customer.) The Shugart SA606 drives were $150 each and the Xebec S1410 SASI Controller was $125 from Paramount Electronics, 649 Arques Ave., Sunnyvale, CA 94086, (408) 773-9595. The Xebec S-100 Host Adapter I ended up using was $90 from Hamilton-Avnet. For a sample BIOS and a diagnostic program in Z80 assembly language, feel free to contact me at the address below. John Blalock, W7AAY uucp: ...{amd,decvax,hao,ihnp4,seismo}!noao!terak!jb phone: (602) 998-4800 us mail: Terak Corp., 14151 N. 76th St., Scottsdale, AZ 85260 \\\\\ -----> Soon to be part of CalComp, A Sanders Company 10-Jul-85 06:10:10-MDT,4578;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 10 Jul 85 06:09:43-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a000351; 10 Jul 85 7:30 EDT Received: from usenet by TGR.BRL.ARPA id a007213; 10 Jul 85 5:46 EDT From: Bruce Eckel Newsgroups: net.micro.cpm Subject: C compilers for CP/M Message-ID: <801@vax2.fluke.UUCP> Date: 8 Jul 85 20:45:06 GMT To: info-cpm@AMSAA.ARPA >I am planning on buying a C compiler to run on my CP/M system. What I >would like to know is which one should I buy? Things that I would like >to do are: > * Write interrupt handlers. > * Produce 'com'able code > * Mixed language programming >Would anybody with C compilers on their machines care to relate their >experiences? All responses will be greatly appreciated. > > Mark Ryding > {..trwrb!trwrba!ryding} I have used several C compilers on CP/M and have tried most of the things you refer to. All of them produce "com"able code, if you mean produces a .com file. I also think all of them require you to go through and assembler, linker and loader to accomplish this. If you mean "rom"able, I know Aztec does it and I think the others will too if you put in the right ORG statements or whatnot. There is usually a way even if they didn't design it in. 1) Aztec. Expensive at $200, but K&R complete, or more so than most. Good library. Includes its own assembler, linker and librarian. Slow as mollasses. I use it because I am familiar with it and didn't want to mess with the idiosyncrasies of the others (at the time). No bit fields or preprocessor macros, but it seems NOBODY has those. The manual is geared after UNIX (not a terribly good precedent but OK) which I am sure they developed the language on. One of the big plusses about this system is its transportability -- Aztec makes (virtually) identical compilers for essentially every processor and operating system. They even make cross-compilers so you can (for example) develop on cp/m and run on apple. 2) BDS . A friend swears by it and it seems fast, efficient and correct. That is, the compiler seems fast. I don't know that much about the code efficiency but he says it is efficient. $150. The manual is very good. No library is as complete as Aztecs, but you can always add your own library modules to any of these. BDS was really the CPM C standard for quite a while, before: 3) C/80 . for 50$ (might be 60 now) and 20 extra for floating point, the real bargain in C compilers. I used an early version of this and didn't like it because they didn't seem to conform to K&R (at least not the library functions) and as I was struggling to *learn* the language in the first place, I didn't want to mess with language variants. Now, however, it seems to have been cleaned up significantly. People seem to love it only second to Turbo pascal, and amazing things have been written with it. The people at Software Toolworks (makers of C/80) have written a lot of stuff with it themselves, notably MyCalc (best spreadsheet for cpm I have seen; I am told supercalc does sorts better, but I just like the way MyCalc works. Amazing that visicalc made any money at all, considering how limited it was) and Mychess. Lots of other people use C/80. Real nice to have floating point; I think it comes with Aztec but you might have to pay extra for it. C/80 is probably your best bet (at least to get started). 4) Q/C. The only thing I can say about this is it comes with source code, written in C. I don't know how it runs since I've never used it, but if you want to know how a compiler is written, this would probably be $95 well spent. Chances are it is real slow (whereas BDS and C/80 are written, I believe, in assembly). What do I prefer? Well, they all do so many disk accesses, and of course going in and out of the editor (wordstar) is incredibly time consuming. I get very frustrated and am thinking of putting a RAM disk on my Kaypro with a megabyte (~$450) to speed up *everything*. But it seems such a waste for most tasks, which are fast. I keep hearing rumors about: 5) Turbo C. Vaporware at the moment, but if it is anything like Turbo P, it will be worth waiting for. They may have put all their efforts into Modula-2, but we can hope. I would by Turbo C in a second, and be off and running. Failing that, I may just give up the wait and buy Turbo Pascal. Bruce Eckel uw-beaver!fluke!morgan 10-Jul-85 14:38:43-MDT,2049;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 10 Jul 85 14:35:25-MDT Received: from usc-ecl.arpa by AMSAA.ARPA id a000522; 10 Jul 85 15:26 EDT Date: Wed 10 Jul 85 12:27:13-PDT From: Ted Shapin Subject: Library vs Archive files To: info-ibmpc@USC-ISIB.ARPA cc: info-cpm@AMSAA.ARPA Postal-address: Beckman Instruments, Inc. Postal-address: 2500 Harbor X-11, Fullerton, CA 92634 Phone: (714)961-3393 Some of the public IBM bulletin board systems are using a program called ARC.EXE to pack related files into "archives". In the past, this has been done with "LU*" library utility programs. I think the library utility programs are to be preferred for the following reasons: . 1) They are public domain, whereas ARC.EXE is a product of System Enhancement associates and asks for a "donation". . 2) The LU programs are well documented. Gary Novosielski wrote the first version in C. The documentation for current versions is in LUDEF5.DOC. Some versions have source available. . 3) Library programs exist on mainframes such as Unix and DEC-20 that will handle .LBR files. . 4) The format is compatible with CP/M-80 .LBR files, so the CP/M user can handle them (altho not run the executable). . 5) LBR utilities exist to run executable programs directly from the library file. . 6) Paul Homchick and Vernon Buerg have written high performance versions of LU* programs for the IBM-PC. LUE201.COM is 2688 bytes and will extract all members and unsqueeze them if necessary at the same time. . 7) ARC does result in slightly smaller files. Comparing library files with archive files shows .LBR files to be about 1000 bytes larger, for .LBR files from 11000 to 40000 bytes in size, apparently because a better algorithm is used for packing repeated characters in .EXE files. However, I believe the other reasons listed above justify using the .LBR programs. . Ted Shapin ------- 10-Jul-85 15:20:31-MDT,1485;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 10 Jul 85 15:16:45-MDT Received: from xerox.arpa by AMSAA.ARPA id a002752; 10 Jul 85 16:19 EDT Received: from CheninBlanc.ms by ArpaGateway.ms ; 10 JUL 85 10:10:20 PDT Date: 10 Jul 85 10:10:12 PDT (Wednesday) From: DHowell.ES@XEROX.ARPA Subject: Re: --- info request --- In-reply-to: Your message of 8 Jul 85 11:49:00 PDT To: max.hartman@AMES-VMSB.ARPA cc: info-CPM@AMSAA.ARPA Message-ID: <850710-101020-1458@Xerox> Answer to question number 2: Basically, a WordStar file is an ASCII text file with the high bit set to signify certain formatting features. All control characters using ctrl-P to enter are stored as straight ASCII, thus typing a ctrl-P ctrl-B stores a ctrl-B in the file. The uses of the high bit are as follows, as far as I have determined. a high bit on an LF signifies a page break (as you have noted) a high bit on a space signifies a "soft" space (used by WordStar to microjustify) a high bit on the last character of a word means that it is part of a justified paragraph. Also the hex characters 1E and 1F signify soft hyphens, one being in the middle of a line, the other at the end (I don't recall which is which). Using this information, I have been able to write a microjustification program for dot-matrix printers (WordStar only provides for daisy-wheel printers). Answer to question number 3: 42 :-) Dan 10-Jul-85 15:59:55-MDT,949;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 10 Jul 85 15:59:23-MDT Received: from xerox.arpa by AMSAA.ARPA id a003171; 10 Jul 85 16:36 EDT Received: from PinotNoir.ms by ArpaGateway.ms ; 10 JUL 85 13:38:17 PDT Date: 10 Jul 85 13:38 PDT From: Ghenis.pasa@XEROX.ARPA Subject: Re: C compilers for CP/M In-reply-to: Bruce Eckel 's message of 8 Jul 85 20:45:06 GMT To: info-cpm@AMSAA.ARPA Message-ID: <850710-133817-1734@Xerox> I'd like to add that C/80 produces the smallest and fastest .com files. BDS-C compiles very fast, but is probably the most non-standard. For "standardness" and portability you can't beat Aztec. Personally, I have a short fuse, so I stick with Turbo Pascal, which doesn't tax my patience at compile time. I recommend referring to the very complete review of C compilers published recently in Computer Language magazine. 10-Jul-85 21:32:52-MDT,1082;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 10 Jul 85 21:31:26-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a006264; 10 Jul 85 22:57 EDT Received: from usenet by TGR.BRL.ARPA id a011513; 10 Jul 85 22:52 EDT From: Melinda Shore Newsgroups: net.micro.cpm Subject: Re: C compilers for CP/M Message-ID: <795@sphinx.UChicago.UUCP> Date: 9 Jul 85 18:36:44 GMT To: info-cpm@AMSAA.ARPA [] A few quick follow-up notes to the discussion of various CP/M C compilers: 1) Aztec *does* support parameterized pre-processor macros. 2) The icky thing about the BDS compiler is that it is somewhat non-standard. Another thing is that, at least in earlier versions (here's hoping this has been fixed), the compiler didn't know about floats. There was floating point support in the libraries, however. -- Melinda Shore ..!ihnp4!gargoyle!sphinx!shor University of Chicago Computation Center Staff.Melinda%chip@UChicago.Bitnet 10-Jul-85 22:12:24-MDT,999;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 10 Jul 85 22:11:54-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a006497; 10 Jul 85 23:44 EDT Received: from usenet by TGR.BRL.ARPA id a011985; 10 Jul 85 23:42 EDT From: william edwards Newsgroups: net.micro.cpm Subject: Re: C compilers for CP/M Message-ID: <436@h-sc1.UUCP> Date: 10 Jul 85 12:41:12 GMT To: info-cpm@AMSAA.ARPA > > 1) Aztec. Expensive at $200, but K&R complete, or more so than most. Good > library. Includes its own assembler, linker and librarian. Slow as mollasses. > I use it because I am familiar with it and didn't want to mess with the > idiosyncrasies of the others (at the time). No bit fields or preprocessor > macros, but it seems NOBODY has those. My version of Aztec C for CP/M-80 (1.05g) definitely supports parameterized #defines. Bill Edwards harvard!edwards edwards@harvard.ARPA 11-Jul-85 01:20:17-MDT,1221;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Jul 85 01:18:44-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a007563; 11 Jul 85 2:53 EDT Received: from usenet by TGR.BRL.ARPA id a015286; 11 Jul 85 2:48 EDT From: Timothy D Margeson Newsgroups: net.lang.pascal,net.micro,net.micro.pc,net.micro.cpm Subject: Reading CPM/86 Command Line Message-ID: <505@tekigm.UUCP> Date: 10 Jul 85 05:57:44 GMT Xref: seismo net.lang.pascal:348 net.micro:11625 net.micro.pc:4884 net.micro.cpm:4624 To: info-cpm@AMSAA.ARPA Hello, I am looking for instructions on how to read the CPM/86 command line from within Turbo Pascal specifically. I have found the location of the command buffer, but it appears to be a circular referenced affair. What I need is the pointer location if my assumptions are correct, or any flames that might lead me in the correct direction should my assumptions be wrong. I will appreciate any and all advice as I haven't much hair left. Thanks! -- Tim Margeson (206)253-5240 tektronix!tekigm!timothym @@ 'Who said that?' PO Box 3500 d/s C1-465 Vancouver, WA. 98665 11-Jul-85 06:34:49-MDT,3114;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Jul 85 06:33:37-MDT Received: from simtel20.arpa by AMSAA.ARPA id a010829; 11 Jul 85 7:52 EDT Date: Thursday, 4 July 1985 18:19-MDT Message-ID: Sender: Andy Brown From: Andy Brown Subject: using both side of disks ReSent-From: KPETERSEN@SIMTEL20.ARPA ReSent-To: Info-Cpm@AMSAA.ARPA ReSent-Date: Thu 11 Jul 1985 05:54-MDT Whether it is a good idea to use both sides of a floppy disk depends on two things: 1) Is the magnetic material on both sides of the disk error-free. 2) Are the disks designed to be "flipped". That is, can the disk safely rotate in both directions with no damage. Most floppy disks are manufactured with a magnetic coating on *both* sides. The disks are then tested to make sure that there are no defects which would make them unsuitable for data storage. If one side of a disk is bad, then it is usually ceritfied as a single-sided disk, if both sides are good, then it is certified as a double-sided disk. When you buy blank disks, it will always say on the box whether the disks are single or double sided. Therefore, most single-sided disks have *known* defects on the uncertified side (you can tell which side is the correct side because it has the label on it). All floppy disks have what is known as a "liner". This is inside the cover of the disk and it has two main functions: to minimize friction as the disk is spinning; and to catch and redirect any dirt and dust which may have found its way into the disk jacket. There are a wide variety of liner designs, and some of them are intended for use with disks that will only be spinning in *one* direction. Flipping a disk with such a liner could cause dirt and dust that was trapped by the liner to be released onto the disk, creating the potential for head or disk damage. It must be mentioned that there are really *two* kinds of double-sided disks. Some disk drives, (such as the double sided drives in the IBM PC) have two heads, one for each side of the disk. Thus they use both sides of the disk, but the disks always spin in the same direction. When you "flip" a disk on a single-sided disk drive, such as the Commodore 1541, the disk will spin in the opposite direction when you flip it. Thus there are some floppy-disks on which both sides can be used, but you might not want to use the *back* side on your Commodore 1541 disk drive because using that side will cause the disk to spin in the wrong direction. It is absolutely safe to use both sides of a disk on a 1541 disk-drive if the disks are certified double-sided on the box, and there is a write-protect notch cut on both side edges of the disk. If not, then it is risky to use the uncertified side for data storage. If you buy a commercial software product which uses both sides of a disk, then it is probably safe to assume that they are using the correct kind of disk. --- Andy Brown 11-Jul-85 07:09:45-MDT,2087;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Jul 85 07:06:31-MDT Received: from xerox.arpa by AMSAA.ARPA id a012014; 11 Jul 85 8:25 EDT Received: from Muscat.ms by ArpaGateway.ms ; 11 JUL 85 05:27:51 PDT Date: Thu, 11 Jul 85 08:27 EDT From: Kushall.henr@XEROX.ARPA Subject: Re:HardDisks for DEC Rainbows To: HARRELL%EDUCOM.BITNET@WISCVM.ARPA cc: INFO-CPM@AMSAA.ARPA Message-ID: <850711-052751-1144@Xerox> Ralph, The following suppliers of rigid disk drives are listed in the spring 84 DEC Rainbow handbook. CORVUS SYSTEMS 2029 O'Toole Ave. San Jose, CA 95131 (408) 946-7700 External winchester drives 5.9 M, 12.1 M, 18.4 M UNIVATION INC 1037 North Fair Oaks Ave. Sunnyvale, CA 94089 (408) 745-0180 5 M removable hard disk with 64-320K RAM 11 M internal hard disk with 64-320 K RAM QUCES INC. 3 Quces Drive Metuchen NJ 08840 (800) 631-5944 (201) 548-2135 10, 16, 20, 42, 57, and 84 M Hard disk subsystems The June 85 Digital Review had an article on rigid disk drives for DEC computers, Rainbow to VAX. Of the vendors listed only digital and Univation were listed for the Rainbow. The following Univation list prices were given. DHD205R-64 5.25 inch 20 MB fixed 5 MB removable 85 msec access time 625KB/Sec List price $3995 DHD20-64 5.25 inch 20.7 MB fixed 85 msec access time 625KB/Sec List price $2750 DHD11-64 5.25 inch 11 MB fixed 80 msec access time 625KB/Sec List price $2160 I hope you find this info useful, if you had an IBM PC you can get a 10 MB drivesetup for about $600 and 20 MB for about $ 800. A while back Advanced Computer Products had a close on the DEC 5 MB Rainbow upgrade for $750, but none are left. Also please note unless you have thre Rainbow 100B you will have to replace the power supply as the 100A power supply can not supply a rigid. Sad note, you can buy a Tandy 1200 with 10 Meg Hard Disk($1995) for less than the cost of any of the above! ED ------------------------------------------------------------ 11-Jul-85 07:29:35-MDT,1691;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Jul 85 07:28:14-MDT Received: from usc-eclb.arpa by AMSAA.ARPA id a012899; 11 Jul 85 8:51 EDT Date: 11 Jul 1985 05:49-PDT Sender: STANLEY@usc-eclb.ARPA Subject: Re: PD Info Rqst From: STANLEY@usc-eclb.ARPA To: DKREBILL@usc-isi.ARPA Cc: info-cpm@AMSAA.ARPA, krebill@ardc.ARPA Message-ID: <[USC-ECLB]11-Jul-85 05:49:34.STANLEY> In-Reply-To: The message of 6 Jul 1985 14:13:49 EDT from DKREBILL@USC-ISI.ARPA Received: from AMSAA by USC-ECLB; Sat 6 Jul 85 11:42:04-PDT from usc-isi.arpa by AMSAA.ARPA id a001279; 6 Jul 85 14:13 EDT Date: 6 Jul 1985 14:13:49 EDT From: DKREBILL@USC-ISI.ARPA To: info-cpm@AMSAA.ARPA Cc: krebill@ARDC.ARPA Subject: PD Info Rqst Return-Path: To assist some folks at USMA who do not have net access, I am asking for info/documentation/source code on the following packages, all of which are beleived to be in the public Domain: (1) XLISP [We have tracked down binaries for this but need source] (2) The cardboard inference engine--source is believed to be in pascal or c. (3) Power ---A user here has this in a power.com version only, with no documentation. Thanks in advance for any pointers/help/assistance!...Dan ------- -------------------- Dan XLISP can be found on SIMTEL20 in the MICRO: directory. To be sure of what files are what, it would be good to download MICRO:CPM.CRCLST first to verify filenames and CRC's. ...Dick 11-Jul-85 07:56:34-MDT,1547;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Jul 85 07:51:47-MDT Received: from usc-eclb.arpa by AMSAA.ARPA id a013138; 11 Jul 85 8:57 EDT Date: 11 Jul 1985 05:55-PDT Sender: STANLEY@usc-eclb.ARPA Subject: Re: I.C. Express From: STANLEY@usc-eclb.ARPA To: elder@wpafb-info1.ARPA Cc: info-cpm@AMSAA.ARPA Message-ID: <[USC-ECLB]11-Jul-85 05:55:02.STANLEY> In-Reply-To: The message of 9 Jul 85 08:03:00 EST from "CPT.GREG.ELDER" Received: from AMSAA by USC-ECLB; Tue 9 Jul 85 10:25:10-PDT from wpafb-info1.arpa by AMSAA.ARPA id a005550; 9 Jul 85 12:33 EDT Date: 9 Jul 85 08:03:00 EST From: "CPT.GREG.ELDER" Reply-To: "CPT.GREG.ELDER" To: info-cpm Subject: I.C. Express Return-Path: I'm thinking about ordering some 41256 RAM chips (150ns) from I.C. Express. They have an advertised price of $4.25. Has anyone done any business with this company or know anything good or bad about them? Thanks. -Greg ------ -------------------- Greg Don't know about IC Express, but have just ordered some 150 ns. 41256 from Microprocessors Unlimited, Beggs, OK at $3.25 each, made by NEC. Although I haven't dealt with this company before, several others here have and have been quite satisfied. Hope that helps. ...Dick 11-Jul-85 08:11:36-MDT,2019;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Jul 85 08:11:04-MDT Received: from xerox.arpa by AMSAA.ARPA id a014115; 11 Jul 85 9:26 EDT Received: from Muscat.ms by ArpaGateway.ms ; 11 JUL 85 06:26:51 PDT Date: Thu, 11 Jul 85 08:22 EDT From: Kushall.henr@XEROX.ARPA Subject: Re: Reading CPM/86 Command Line In-reply-to: <505@tekigm.UUCP> To: Timothy D Margeson cc: info-cpm@AMSAA.ARPA, XeroxInfo-CPM^.Wbst@XEROX.ARPA, Pascal/Turbo^.x@XEROX.ARPA Reply-To: Kushall.henr@XEROX.ARPA Message-ID: <850711-062651-1179@Xerox> I have been using the following method for reading the command line arguments from Turbo Pascal. (CP/M-86 version 2.0, Turbo Pascal version 2.0) Declare the following global variable: var CmdLine : String[128] absolute(DSeg:$80); { this is the location of the CP/M 86 Command line buffer} CmdLineString : String[128]; { used to save the command line } You must execute the following code before your program does any IO and destroys the buffer ! CmdLineString := CmdLine; { Copies the command line args into the safe area} Note that if length(CmdLine) = 0 then no args were passed. The data format of Dseg:$80 is as follows: The byte at Dseg:$80 is the nunber of characters passed in the cmd line after the name of the .CMD file called including the leading space. This will be CmdLine[0] in the Turbo Pascal string. Thus the string is returned by CP/M in the same format as required by Turbo. The same method can be used for CP/M 80 except the declaration is: CmdLine : String[128] Absolute $80; And for MS-DOS CmdLine : String[128] Absolute(CSeg:$80); It is my understanding that the CP/M-80 versions only allow a limited number of characters to be passed as arguments(arround 30) I have not verified this for any of the implementations. Turbo Pascal 3.0 includes 'standard' procedures for reading the command line arguments. Ed Kushall 11-Jul-85 08:44:37-MDT,888;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Jul 85 08:42:05-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a015100; 11 Jul 85 9:53 EDT Received: from usenet by TGR.BRL.ARPA id a022896; 11 Jul 85 9:44 EDT From: Bill Hery Newsgroups: net.micro.cpm Subject: Terminal emulator for Vecotr Graphic micro Message-ID: <4385@hlexa.UUCP> Date: 10 Jul 85 14:08:57 GMT To: info-cpm@AMSAA.ARPA Does anyone know of a good terminal emulator for an old Vector Graphic VIP micro using CP/M? It's a Z-80 based machine with a single sided, double density disk drive. Support of full screen editors (e. g. vi) on the host is a requirement; emulating a VT100, or HP2621 is fine. I will pay a reasonable price for a suitable commercial product. Bill Hery ihnp4!hlexa!wjhe or ihnp4!hlwpb!hery 11-Jul-85 09:05:17-MDT,2932;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Jul 85 09:00:27-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a015070; 11 Jul 85 9:52 EDT Received: from usenet by TGR.BRL.ARPA id a022752; 11 Jul 85 9:41 EDT From: "Mike (I'll be mellow when I'm dead" MMDF-Warning: Parse error in original version of preceding line at BRL.ARPA Newsgroups: net.micro.cpm Subject: Re: C compilers for CP/M Message-ID: <1008@ucbtopaz.CC.Berkeley.ARPA> Date: 10 Jul 85 22:59:33 GMT To: info-cpm@AMSAA.ARPA More followup on the C compiler commentary. In article <801@vax2.fluke.UUCP> morgan@fluke.UUCP (Bruce Eckel) writes: >2) BDS . A friend swears by it and it seems fast, efficient and correct. >That is, the compiler seems fast. I don't know that much about the code >efficiency but he says it is efficient. $150. The manual is very good. >No library is as complete as Aztecs, but you can always add your own >library modules to any of these. BDS was really the CPM C standard >for quite a while, before: Unlike other C compilers, BDS C does not produce an intermediate assembler, but produces relocatables directly. This is one of the reasons for it's compile-time speed. It comes with a program to turn pseudo-assembler into .CRL files, and a source-level debugger (the only CP/M-80 compiler to do so, last time I looked). It can be used to generate rommable code and interrupt handlers (I've done so). The major loss with BDS C is the I/O library, and no initializers. The I/O library looks like the PWB library. BDS C is *not* suitable for writing code for porting to other system, or for porting code from other systems to CP/M-80. I think it's the best thing around for writing CP/M-80 code, though. >4) Q/C. The only thing I can say about this is it comes with source code, >written in C. I don't know how it runs since I've never used it, but if >you want to know how a compiler is written, this would probably be $95 >well spent. Chances are it is real slow (whereas BDS and C/80 are >written, I believe, in assembly). BDS C is written in assembler (yet another reason for it's speed). C/80 is written in C. In fact, C/80 and Q/C both started from the Public Domain Small/C compiler. I was never happy with C/80, as the early version (v2.0) I have is full of bugs. It did produce fast code, by copying the arguments into a fixed area of memory, and then back onto the stack for subroutine calls so recursion worked. This was (I think) the reason that it evaluated and stacked subroutine arguments from left to right instead of right to left (like nearly every other C compiler I know of). This quirk could expose portability problems in your code, and makes the printf function the single ugliest piece of C I've ever laid eyes on. They may have fixed this by now. Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Jul 85 09:36:53-MDT Received: from su-score.arpa by AMSAA.ARPA id a016784; 11 Jul 85 10:34 EDT Date: Thu 11 Jul 85 07:32:26-PDT From: Steven Bjork Subject: CPM-80 Deblocking routine question To: info-cpm@AMSAA.ARPA Message-ID: <12126153831.11.BJORK@SU-SCORE.ARPA> Does anyone know if there is an extended version of DR's deblocking algorithm around? Three features would be convenient to have-- 1. Greater than 255 sectors/track capability. 2. Variable blocking factors-i.e., 256, 512, or 1024 bytes/sector. 3. Z80 coded (feature?). Or, possibly even better, would be a flowchart or other information (hello, DR?) to help me in a custom implementation. My only source at the moment are the old CPM 2.2 manuals--the ones with all the mistakes. --Steve ------- 11-Jul-85 19:45:53-MDT,414;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Jul 85 19:43:51-MDT Received: from mit-mc.arpa by AMSAA.ARPA id a003940; 11 Jul 85 21:18 EDT Date: Thu, 11 Jul 85 21:21:14 EDT From: Eric Stork Subject: Buzz Words To: STORK@MIT-MC.ARPA, info-cpm@AMSAA.ARPA Message-ID: <[MIT-MC.ARPA].572604.850711.STORK> BD7\LGO:R'-V2\N0h 11-Jul-85 20:04:10-MDT,414;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Jul 85 20:01:06-MDT Received: from mit-mc.arpa by AMSAA.ARPA id a003973; 11 Jul 85 21:21 EDT Date: Thu, 11 Jul 85 21:24:17 EDT From: Eric Stork Subject: Buzz Words To: STORK@MIT-MC.ARPA, info-cpm@AMSAA.ARPA Message-ID: <[MIT-MC.ARPA].572606.850711.STORK> BD7\LGO:R'-V2\N0h 11-Jul-85 20:35:23-MDT,2010;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Jul 85 20:32:48-MDT Received: from mit-mc.arpa by AMSAA.ARPA id a004025; 11 Jul 85 21:29 EDT Date: Thu, 11 Jul 85 21:32:16 EDT From: Eric Stork Subject: BuzzWords To: STORK@MIT-MC.ARPA, info-cpm@AMSAA.ARPA Message-ID: <[MIT-MC.ARPA].572616.850711.STORK> Buzz Words by the Numbers There is circulating in Washington, D.C., a "foolproof system for those wishing to appear more learned than they are." It is called "convoluted phraseology." Here is how it works: . When you need to "language up", select at random any three-digit number. . Look up the words associated with your number in the table below (one digit per column). Col. 1 Col. 2 Col. 3 0. integrated 0. management 0. options 1. total 1. organizational 1. options 2. systematized 2. monitored 2. capability 3. parallel 3. reciprocal 3. capability 4. functional 4. digital 4. programming 5. responsive 5. logistical 5. concept 6. optimal 6. transitional 6. time-phase 7. synchronized 7. incremental 7. projection 8. compatible 8. third-generation 8. hardware 9. balanced 9. policy 9. contingency For example, 379 produces "parallel incremental contingency." No one knows what that means, but it sounds impressive. Now, someone truly clever out there in Netland should develop a module that can be integrated into any word processor so that when a specially defined key is hit, the module will: . Generate a three-digit random number, . Reach into the table for the Buzz Words, and . Insert the appropriate phrase into the document being prepared. Upward and onward. 13-Jul-85 12:05:48-MDT,761;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 13 Jul 85 12:04:05-MDT Received: from xerox.arpa by AMSAA.ARPA id a000443; 10 Mar 85 4:48 EST Received: from Muscat.ms by ArpaGateway.ms ; 12 JUL 85 09:50:21 PDT Date: Fri, 12 Jul 85 12:50 EDT From: Kushall.henr@XEROX.ARPA Subject: Re: Harddisks In-reply-to: "HARRELL@EDUCOM.BITNET.AG's message of 21 JUN 85 09:39 EDT" To: HARRELL%EDUCOM.BITNET@WISCVM.ARPA cc: INFO-CPM@AMSAA.ARPA Message-ID: <850712-095021-129@Xerox> DEC is selling the RD50 disk drive kits for Rainbow, Pro350 and DECmate for $750 as a close the 5 MB drives have beeb dropped. The Rainbow kit includes Controller, RD50 drive, Power Supply, CPM + MS-DOS operating systems. ED 13-Jul-85 12:05:55-MDT,563;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 13 Jul 85 12:04:23-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a000483; 10 Mar 85 4:48 EST Received: from usenet by TGR.BRL.ARPA id a002335; 12 Jul 85 15:09 EDT From: Graeme Clark Newsgroups: net.micro.cpm Subject: Re: PD Info Rqst Message-ID: <1143@ubc-cs.UUCP> Date: 10 Jul 85 16:26:56 GMT To: info-cpm@AMSAA.ARPA Although Power is not in the public domain, a prerelease version of it is available from SIG/M. 13-Jul-85 23:15:28-MDT,917;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 13 Jul 85 23:14:23-MDT Received: from usc-isid.arpa by AMSAA.ARPA id a000805; 14 Jul 85 0:51 EDT Date: 14 Jul 1985 00:46-EDT Sender: ABN.ISCAMS@USC-ISID.ARPA Subject: Re: Reading CPM/86 Command Line From: ABN.ISCAMS@USC-ISID.ARPA To: Kushall.henr@XEROX.ARPA Cc: timothym%tekigm.uucp@BRL.ARPA, info-cpm@AMSAA.ARPA Cc: XeroxInfo-CPM^.Wbst@XEROX.ARPA Cc: Pascal/Turbo^.x@XEROX.ARPA Message-ID: <[USC-ISID.ARPA]14-Jul-85 00:46:38.ABN.ISCAMS> In-Reply-To: <850711-062651-1179@Xerox> Re getting the command line in CP/M-80: FACT - in Version 1, at least, of Turbo Pascal, Turbo eats everything after maybe the 30th or 31st character - puts a bunch of (consistent) garbage there. I have extensively tested this and am sorely tried by this particular bug! David P Kirschbaum Toad Hall AB.ISCAMS@USC-ISID 13-Jul-85 23:32:49-MDT,8689;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 13 Jul 85 23:31:17-MDT Received: from simtel20.arpa by AMSAA.ARPA id a000819; 14 Jul 85 1:04 EDT Date: Sat, 13 Jul 1985 23:03 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: New files on SIMTEL20 between 7-May-85 and 13-Jul-85 The following is a list of new files added to SIMTEL20's directories between 7-May-85 and 13-Jul-85. For a complete list of all files, get MICRO:CPM.CRCLST. Filename Type Bytes CRC MICRO: APLICARD.REVIEW.1 ASCII 6998 F756H MICRO: FORM7.LBR.1 BINARY 9472 ABF8H MAKSRL.LBR.1 BINARY 8832 1CF7H NEAT7.LBR.1 BINARY 6144 9C8FH Z80MR.LBR.1 BINARY 41344 B0D0H Z80 macro assembler MICRO: TINIDISK.LBR.1 BINARY 44672 7D5FH Tiny disk basic MICRO: B3AC-0.IQS.1 BINARY 2304 C988H B3AD-0.IQS.1 BINARY 3072 16EEH B3AM-0.IQS.1 BINARY 2944 9767H B3AP-0.IQS.1 BINARY 2944 97CDH B3CC-0.IQS.1 BINARY 3968 BD72H B3CM-0.IQS.1 BINARY 3584 AEC4H B3CP-0.IQS.1 BINARY 4736 A9A7H B3DC-0.IQS.1 BINARY 1792 1E5BH B3DP-0.IQS.1 BINARY 2944 D2FBH B3EP-0.IQS.1 BINARY 2816 0BB0H B3H8-0.BUG.1 ASCII 222 6894H B3H8-1.IQS.1 BINARY 2432 C891H B3HZ-0.IQS.1 BINARY 3584 EDAEH B3KP-0.IQS.1 BINARY 2560 BA18H B3MD-0.IQS.1 BINARY 3840 E12CH B3OS-0.IQS.1 BINARY 5760 06EDH B3PH-0.IQS.1 BINARY 2688 6ABDH B3R1-0.IQS.1 BINARY 2176 B0D5H B3R2-0.IQS.1 BINARY 3072 DFA9H B3R3-0.IQS.1 BINARY 2176 48DCH B3R4-0.IQS.1 BINARY 2176 CED6H B3R4-1.IQS.1 BINARY 3968 38FFH B3SB-0.IQS.1 BINARY 2560 9164H B3TV-0.IQS.1 BINARY 3712 C2E0H B3US-0.IQS.1 BINARY 3072 73AFH B3ZB-0.IQS.1 BINARY 2944 1D59H BYE3-INS.IQF.1 BINARY 2560 F0B8H BYE3-INS.LBR.1 BINARY 77312 A3C9H BYE335.BUG.1 ASCII 623 E9E3H BYE335.LBR.1 BINARY 90368 9E85H MICRO: LSTPATCH.AQM.1 BINARY 2688 0406H Temp. list driver MICRO: TERM-V2.C1.1 ASCII 21359 67C2H Punter protocol TERM-V2.MSG.1 ASCII 831 04B0H modem program MICRO: CMDOSS.CPM.1 ASCII 1889 B172H CMDPF1.C.1 ASCII 19180 0FFDH CMDPF2.C.1 ASCII 9839 C130H CMDPFD.C.1 ASCII 8927 9FFDH CMDPSD.C.1 ASCII 1986 80D1H COMND.C.1 ASCII 21248 47C5H COMND.DOC.1 ASCII 34945 3094H COMND.EDT.1 ASCII 815 882EH COMND.H.1 ASCII 4068 2CBCH COMND.R.1 ASCII 28462 8BDDH COMND003.LBR.1 BINARY 100736 6A5DH COMNDI.H.1 ASCII 1394 419DH CPM.H.1 ASCII 2726 4F6BH DATE.CPM.1 ASCII 4295 485BH MEM.H.1 ASCII 734 1AB4H TEST.C.1 ASCII 11638 40E2H MICRO: BYEP-333.LBR.1 BINARY 62208 6AFEH BYEP-INS.LBR.1 BINARY 22400 0262H TS312.AQM.1 BINARY 9856 2546H time stamp MICRO: NULU01.IQF.1 BINARY 1152 63C0H MICRO: ERAQ20.LBR.1 BINARY 12288 A918H erase with querry MICRO: FRONT45.LBR.1 BINARY 42880 9308H turnkey menu SD99.LBR.1 BINARY 86528 3498H super directory MICRO: UNERA30.LBR.1 BINARY 14464 17FBH undo file erase MICRO: PATCH18A.LBR.1 BINARY 66176 2D51H MICRO: EMX313.LBR.1 BINARY 130944 E7D9H EMAIL for micros MICRO: FIDO-109.LQT.1 BINARY 14976 6B97H Fido list FIDO-203.NQS.1 BINARY 33152 D8F3H Fido News FIDO-204.NQS.1 BINARY 32384 FFC4H FIDO-209.NQS.1 BINARY 21120 D73AH FIDO-211.NQS.1 BINARY 23808 0C01H FIDO-212.NQS.1 BINARY 27392 E856H FIDO-219.NQS.1 BINARY 18304 D33FH FIDO-301.NQS.1 BINARY 34304 0C6AH FIDO-315.NQS.1 BINARY 24704 D59BH MICRO: ANTI-APS.CKT.1 ASCII 2470 232CH SNYOSCRN.DOC.1 ASCII 4457 3E77H WIREWRAP.DOC.1 ASCII 18404 4DB9H Z800MORE.DQC.1 BINARY 5120 0ED2H MICRO: GTWY1-20.TXT.1 ASCII 15629 6ADAH IC02A.MOD.1 ASCII 2483 BB44H MICRO: JMODZ100.LBR.1 BINARY 7424 6E4AH MICRO: ALTDRIVE.LBR.1 BINARY 33408 CF05H CURSOR.LBR.1 BINARY 4736 2E97H DSKDRV13.LBR.1 BINARY 56448 B1C3H FASTTERM.LBR.1 BINARY 4608 CD25H fast terminal JUL85.MQG.1 BINARY 29568 35A4H KPRESET.LBR.1 BINARY 1920 916EH MICRO: GALLERY.LBR.1 BINARY 9216 F696H galley proof lister MICRO: MBBS31A.LBR.1 BINARY 64384 22E8H Bulletin board MBBS31B.LBR.1 BINARY 112896 EA8AH MICRO: MEX-STAT.FIX.1 ASCII 804 4D73H MICRO: MEXSTAT.FIX.1 ASCII 635 3BD6H MXO-II13.AQM.1 BINARY 13440 D75EH MICRO: OTHERSYS.JUN.1 ASCII 67571 7DD4H June 85 PAMS list PDSE-063.LQT.1 BINARY 49152 A5C4H PD CP/M phone list MICRO: RCPM-062.LQT.1 BINARY 1920 4D2EH ROYALOAK.DQR.1 BINARY 64640 B334H my RCPM directory MICRO: 2400MICM.MSG.1 ASCII 2316 DB78H Microcom modem info 2400STDS.WRN.1 ASCII 5560 B8AAH Standards differ FONESGNL.DOC.1 BINARY 640 7284H Info on ringing signals HAYS2400.IQF.1 BINARY 5376 C444H HEXLINK.LBR.1 BINARY 17152 EEBEH JCATDIAL.LBR.1 BINARY 12544 0421H MODMLOOP.MSG.1 ASCII 3079 293DH Remote loopback info MICRO: M7AQ-4.AQM.1 BINARY 12800 E9B7H MICRO: PACKET93.LBR.1 BINARY 219648 0C0BH Ham radio packet PACKET93.MSG.1 ASCII 2144 C55CH ROUTING.TXT.1 ASCII 28795 2D49H TCP-IP.TXT.1 ASCII 56129 368BH MICRO: JDATE.PQS.1 BINARY 2816 B618H TAUSGEN3.PQS.1 BINARY 7680 6FCFH rand. number gen. MICRO: LPT-30.AQM.1 BINARY 17792 9E27H LPT-30.DQC.1 BINARY 3584 BCAEH LPT-30.MSG.1 ASCII 492 22F2H WSCONV.BAS.1 ASCII 822 5992H WSCONV.DOC.1 ASCII 587 0F1EH MICRO: RBBS40.LBR.1 BINARY 30976 728FH MICRO: CHAT43.LBR.1 BINARY 15104 013AH KMODEM.NEW.1 ASCII 1723 6D34H LUXTYP42.BUG.1 ASCII 590 D648H MBXMK484.LBR.1 BINARY 8832 F646H NBYE10.LBR.1 BINARY 100224 FBB4H RCPM-UG.PRN.1 ASCII 53332 A3CEH RCPM user's guide RCPM-UG.WQ.1 BINARY 33792 84DBH WHATSN04.LBR.1 BINARY 25984 6A7EH XMDM107.FIX.1 ASCII 1349 C336H XMDM107.LBR.1 BINARY 92544 4EECH XMFIX.NOT.1 ASCII 2711 229EH XMSTATS.LBR.1 BINARY 36864 79CBH MICRO: ROS32K10.LBR.1 BINARY 102272 A77BH Bulltin board... ROSMAC.LBR.1 BINARY 34944 F34FH ..in Turbo Pascal MICRO: (portable file squeezer/unsqueezer) MAKESQ..2 ASCII 156 23CEH MAKEUSQ..2 ASCII 91 8E4BH README..2 ASCII 3817 A23DH SQ.1.2 ASCII 1657 E6FCH SQ.C.2 ASCII 5518 7EE5H SQ.H.2 ASCII 1900 F320H SQCOM.H.2 ASCII 445 F27AH SQDEBUG.C.2 ASCII 791 78FFH SQIO.C.2 ASCII 810 B0BEH SQU-PORT2.MAN.1 ASCII 1954 A5DEH SQU-PORT2.MSG.1 ASCII 818 197FH TR1.C.2 ASCII 1361 CC07H TR2.C.2 ASCII 13424 763AH USQ.C.2 ASCII 6527 1AF0H USQ.H.2 ASCII 376 BF51H UTR.C.2 ASCII 1778 9735H MICRO: SQ17.BUG.1 ASCII 717 375DH SQU-PORT2.LBR.1 BINARY 33152 DA1EH SQU-PORT2.MSG.1 ASCII 818 197FH MICRO: SPLTVIO.LBR.1 BINARY 6528 54C9H split screen for VIO MICRO: MODEM.EXE.315 ASCII 20480 C5A0H MODEM.MAC.315 ASCII 53537 7ED1H MODEM7.DOC.1 ASCII 13552 C0A9H NCRC.EXE.7 ASCII 4500 CE85H crck-compatible NCRC.MID.7 ASCII 10085 DA97H USQ.EXE.42 ASCII 5655 0C9BH MICRO: REFS13.LBR.1 BINARY 12288 E598H TUGLINES.DOC.1 ASCII 613 F343H TURBOSAV.LBR.1 BINARY 6400 90C2H MICRO: TOUR20.LBR.1 BINARY 96512 2F91H TOURND.LBR.1 BINARY 10240 2300H VDO25.LBR.1 BINARY 41472 C4B7H MICRO: WS3330.DQC.1 BINARY 13440 60ACH patch locations WSPAT-33.DQC.1 BINARY 5504 C85CH " " MICRO: RBSB.SHAR.1 ASCII 44060 356DH batch send and recv. YMODEM.DQC.1 BINARY 24704 4837H YAM protocol doc MICRO: Z3NEWS.2Q5.1 BINARY 8576 4F28H ZNODELST.LBR.1 BINARY 10394 057CH MICRO: ACREATE2.LBR.1 BINARY 11648 8A0AH LDR13.LBR.1 BINARY 12160 E9B5H PATH31.LBR.1 BINARY 7936 0FEAH QUEUE.LBR.1 BINARY 14080 B8E7H SYSRCP11.LBR.1 BINARY 33408 8942H VFILER35.LBR.1 BINARY 145152 8C0AH ZNODELST.LBR.1 BINARY 10394 057CH --Keith 13-Jul-85 23:47:51-MDT,604;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 13 Jul 85 23:45:52-MDT Received: from simtel20.arpa by AMSAA.ARPA id a000821; 14 Jul 85 1:06 EDT Date: Sat, 13 Jul 1985 23:05 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: SIMTEL20 CP/M directory list updated MICRO:CPM.CRCLST on SIMTEL20 (the file listing all the filenames, sizes and CRCs of the MICRO directories) has been updated as of today. --Keith 14-Jul-85 09:21:34-MDT,593;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 14 Jul 85 09:21:24-MDT Received: from simtel20.arpa by AMSAA.ARPA id a001519; 14 Jul 85 11:05 EDT Date: Sun, 14 Jul 1985 09:04 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: RCPM-Sysops@SIMTEL20.ARPA Cc: Info-Cpm@AMSAA.ARPA Subject: SD99 bug fix Someone found a nested IF in SD99.ASM, which of course will not properly assemble with ASM.COM. See MICRO:SD99.FIX --Keith 14-Jul-85 09:51:31-MDT,1243;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 14 Jul 85 09:47:15-MDT Received: from simtel20.arpa by AMSAA.ARPA id a001532; 14 Jul 85 11:22 EDT Date: Sun, 14 Jul 1985 09:21 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: COEX 64k RAM board problems - help needed I received the following message asking for help: Date: 12-Jul-85 From: Robb Adams Re: COEX 64K RAM BOARD PROBLEMS Just acquired two COEX (Components Express) 64k Ram cards only to discover an interesting and persistent bug. It seems that RAM between 1000 - 1fffh is filled with 7eh (0111 1110b) throughout this 4k region as though b1-6 were jammed high and on BOTH boards. Continuity checks ok. Anyone know of this problem or bus conflict. The environment is a Morrow Decision I which has always taken kindly to OEM devices. --- End of message --- Please reply to me. I will relay any answers to Robb. --Keith Petersen Arpa: W8SDZ@SIMTEL20.ARPA uucp: ...!{decvax,unc,hao,cbosgd,seismo,aplvax,uci}!brl-bmd!w8sdz uucp: ...!{ihnp4!cbosgd,cmcl2!esquire}!brl-bmd!w8sdz 15-Jul-85 12:08:03-MDT,874;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 15 Jul 85 12:07:44-MDT Received: from wiscvm.arpa by AMSAA.ARPA id a007945; 15 Jul 85 13:20 EDT Received: from (HARRELL)EDUCOM.BITNET by WISCVM.ARPA on 07/15/85 at 12:19:57 CDT Date: 15 JUL 85 13:12-EDT From: HARRELL%EDUCOM.BITNET@WISCVM.ARPA To: INFO-CPM@AMSAA.ARPA Subject: Project Transport Theodore Needleman writes a monthly column in Hardcopy Magazine. He is trying to find out how much interest is out there for his "Project Transport". A project to transfer CP/M and MSDOS programs from the IBM PC to the DEC Rainbow. If you have interest, please write to him at Idea Technology P.O. Box 668 New York , New York 10956 or MCI Mail to Theodore Needleman or send a note back to me and I will forward it to him. Thanks, Ralph 15-Jul-85 14:50:06-MDT,547;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 15 Jul 85 14:47:22-MDT Received: from jpl-vlsi.arpa by AMSAA.ARPA id a000271; 10 Jul 85 7:29 EDT Date: Tue, 9 Jul 85 22:16:31 PDT From: august@JPL-VLSI.ARPA Subject: RE: --- Otrona Attache --- To: info-cpm-request@AMSAA.ARPA Resent-Date: Mon, 15 Jul 85 16:11:08 EDT Resent-From: cpmlist@AMSAA.ARPA Resent-To: info-cpm@JPL-VLSI.ARPA Whoever said that OTRONA ATTACHE's were a good machine certainly has a few wires loose. 15-Jul-85 14:56:06-MDT,939;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 15 Jul 85 14:51:18-MDT Received: from cmu-cs-c.arpa by AMSAA.ARPA id a009715; 9 Jul 85 14:35 EDT Received: ID ; Tue 9 Jul 85 14:37:08-EDT Date: Tue 9 Jul 85 14:37:07-EDT From: Drew Anderson Subject: I.C. Express To: info-cpm-request@AMSAA.ARPA Resent-Date: Mon, 15 Jul 85 16:10:26 EDT Resent-From: cpmlist@AMSAA.ARPA Resent-To: info-cpm@CMU-CS-C.ARPA I have never dealt with that company, but we (at CMU) use Microprocessors Unlimited for all of our memory purchases (chips.) They currently list the 41256 chips for $3.25 each. I think that you will be pleased ith their service. Their phone is (918)267-4961. We have ordered probably more than a thousand chips from them with no bad ones. Drew Anderson DDA@cmu-cs-c.arpa ------- 19-Jul-85 12:28:22-MDT,1561;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 19 Jul 85 12:26:19-MDT Date: Thu, 18 Jul 85 9:05:37 EDT From: David Towson (SECAD) To: info-cpm@AMSAA.ARPA Subject: Failure of network service to AMSAA.ARPA Fellow CP/Mers - While I was on vacation (6-13 July), the machine from which this list is distributed was moved from its normal site to a trailer located a short distance across the parking lot. Plans had been made for continuing network service, and indeed the network was just about the first form of communications to come up. Two days ago, we had a real humdinger of an electrical storm. Residential electric service was disrupted for many homes. Another casualty was the AMSAA network interface. As you can see, we are now back in netland, but this has been accom- plished using borrowed equipment. The loan is short-term, but repair of the network interface is underway. If all goes well, there will be no further interruption of service. However, Old Man Murphy hangs around here too, so we make no promises. In the worst-case scenario, there is another machine with a light enough load to host info-cpm. This machine has just had some new hardware installed, and it is presently not entirely well. But what the heck - we wouldn't want life around here to get dull, would we? So for the present, info-cpm is back. We'll see what the future brings. Dave towson@amsaa.arpa aka info-cpm-request@amsaa.arpa 19-Jul-85 12:33:21-MDT,1208;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 19 Jul 85 12:28:39-MDT Date: Thu, 18 Jul 85 10:15:10 EDT From: David Towson (SECAD) To: info-cpm@AMSAA.ARPA Subject: AMSAA.ARPA network problems persist. Fellow CP/Mers - It seems that I was a bit hasty in sending my last message. As it turns out, the machine from which this list is distributed is sort of "half back on the net". The lightning that took out the network interface in the VAX also zapped the IMP port which provides our published network address. Mike Muuss (pronounced "moose"), one of our system wizards, got AMSAA back on the local BRLNET by using another IMP port and suitably altering the entries in the local routing tables. However, this still leaves us with our published network address out of action. Thus, we can send packets out, but no one out in netland knows the address to use for sending packets back to us. I will let you know when this situation improves, but for now there is no point in sending mail to info-cpm, as it will just be rejected. Sigh, Dave towson@amsaa.arpa aka info-cpm-request@amsaa.arpa 19-Jul-85 12:33:27-MDT,1254;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 19 Jul 85 12:30:31-MDT Received: from nosc-gw by AMSAA.ARPA id a017696; 15 Jul 85 17:48 EDT Received: from marlin.ARPA by nosc.ARPA (4.17/4.7) id AA01051; Mon, 15 Jul 85 14:44:02 pdt Received: by marlin.ARPA (4.17/4.7) id AA03838; Mon, 15 Jul 85 14:47:36 pdt Date: Mon, 15 Jul 85 14:47:36 pdt From: "Joseph G. Grovhoug" Message-Id: <8507152147.AA03838@marlin.ARPA> To: august@JPL-VLSI.ARPA Subject: RE: --- Otrona Attache --- Cc: grovhoug%marlin@nosc.ARPA, info-cpm-request@AMSAA.ARPA Resent-Date: Thu, 18 Jul 85 11:31:56 EDT Resent-From: cpmlist@AMSAA.ARPA Resent-To: info-cpm@nosc.ARPA Well, everyone has his/her own opinion, but from my experience three+ years of nearly trouble-free HEAVY use of two Otrona machines in very hostile field environments [I'm a field marine biologist], this box HAS WORKED FOR ME! I guess my view is from the perspective "it gets the job done for me" soooo much better than B4. Am aware that there may be much better systems now [both hardware & software-wise]. Again, the machine has already paid for itself in utility for my projects. Aloha, Jeff Grovhoug 19-Jul-85 12:38:20-MDT,745;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 19 Jul 85 12:33:45-MDT Received: from usc-ecl.arpa by AMSAA.ARPA id a017825; 15 Jul 85 18:40 EDT Date: Mon 15 Jul 85 15:40:35-PDT From: Warren Apel Subject: RE: --- Otrona Attache --- To: august@JPL-VLSI.ARPA cc: info-cpm-request@AMSAA.ARPA, APEL@USC-ECL.ARPA In-Reply-To: Message from "august@JPL-VLSI.ARPA" of Mon 15 Jul 85 13:55:17-PDT Resent-Date: Thu, 18 Jul 85 11:32:30 EDT Resent-From: cpmlist@AMSAA.ARPA Resent-To: info-cpm@USC-ECL.ARPA I have used an Otrona Attache almost daily for three years now with absolutely no problems and have (for me, at least) found it an excellent CPM machine. ------- 19-Jul-85 12:43:37-MDT,953;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 19 Jul 85 12:41:40-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id aa26825; 19 Jul 85 8:07 EDT Received: from usenet by TGR.BRL.ARPA id a004037; 18 Jul 85 22:30 EDT From: Rick Fairfield Newsgroups: net.micro.cpm Subject: I Need KERMIT for a CCS 400 Message-ID: <50@ssc-vax.UUCP> Date: 16 Jul 85 19:32:23 GMT To: info-cpm@AMSAA.ARPA I have a CCS model 400 processor running CP/M 2.2. I need KERMIT for this machine. I tried a local copy of the "generic cp/m" KERMIT but it didn't work. If I can't find KERMIT a version of MODEM7 for the CCS might be usefull. If I can't find either, then some advice on how to configure generic KERMIT or generic MODEM7 for my machine would be helpfull. thanx, Rick Fairfield Boeing Aerospace Co. ...!sscvax!zadco 206-773-1004 19-Jul-85 12:53:41-MDT,1744;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 19 Jul 85 12:52:18-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a026825; 19 Jul 85 8:07 EDT Received: from usenet by TGR.BRL.ARPA id a004043; 18 Jul 85 22:30 EDT From: Bruce Eckel Newsgroups: net.micro.cpm Subject: Stuffing commands to the ccp Message-ID: <826@vax2.fluke.UUCP> Date: 15 Jul 85 23:16:00 GMT To: info-cpm@AMSAA.ARPA I have found myself a complexing little puzzle: I want to invoke a new .COM program from inside MBASIC. Now, I know MBASIC overwrites the CCP. So the first thing I will do is find where the CCP starts and use the /M directive when invoking MBASIC to prevent it from overwriting the CCP. I also suspect the CCP may not start at its lowest memory location, so I will write a little assembly program which pops the CCP return address off the stack (if you do not disturb the stack, you can just ret from a program). Now the problem is, the CCP seems to have its own buffer which it keeps the command line in. As the CCP is proprietary, I don't know where that is (maybe I should know and am just stupid. Someone enlighten me). But the people who write SUBMIT, XSUB and EX know how to do it. I really wonder how. Perhaps they take control of standard input and force it to the CCP somehow (a warm boot is always executed between programs, so the CCP gets reloaded, and they can't be diddling with it). If you could just feed the thing a line terminated with a CR, you would be home free. I am not trying to make any money with this, I just think it would be a very neat trick. Any suggestions? Bruce Eckel uw-beaver!fluke!morgan 19-Jul-85 13:05:36-MDT,2739;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 19 Jul 85 13:05:14-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a026853; 19 Jul 85 8:08 EDT Received: from usenet by TGR.BRL.ARPA id a004740; 18 Jul 85 22:46 EDT From: "R.Thomas" Newsgroups: net.micro.cpm Subject: Re: using both side of disks Message-ID: <549@sftig.UUCP> Date: 16 Jul 85 17:38:23 GMT To: info-cpm@AMSAA.ARPA > > It is absolutely safe to use both sides of a disk on a 1541 disk-drive > if the disks are certified double-sided on the box, and there is a > write-protect notch cut on both side edges of the disk. If not, then > it is risky to use the uncertified side for data storage. > > If you buy a commercial software product which uses both sides of a > disk, then it is probably safe to assume that they are using the > correct kind of disk. > > > --- Andy Brown Interesting. I have *never* seen a disk with notches cut on both sides, except when I have personally known the person who cut them. Most 'double sided' software distribution disks I have seen have actually not had notches on *either* side. They must have been produced on duplicating machines that ignored the presence or absence of write protect notches. On the other hand, I have the following philosophy on 'flippy' disks -- Because of the dirt entrapment/releasing problem, it is never a good idea to use the 'back' side of a disk, unless the disk is (almost) brand new. That means that for day to day use, if you only have a single sided drive, you should only use the front side of your disks. Whether you buy disks marked 'single sided' or 'double sided' is a matter of personal preference, especially since the price difference is so small, nowadays. I buy 'double sided' disks, personally, because of the following observation -- There *is* one safe use for 'flippy' disks. That is for distributing software that is too big to fit on a single side. In that case, you are going to use a new -- fresh out of the box -- disk, so you are not worried about dirt, and the recipient is going to make a backup copy (onto *two* disks!) as soon as she gets it, then put it away and (hopefully) never have to read it again, so she is not worried about dirt either. I do enough software swapping that I find it useful to have a supply of 'double sided' disks readily available at all times. As an aside, I don't think it is possible to design a liner that will not entrap some dirt, and release it if the disk is spun the other way. That just seems like the the inevitable workings of the laws of physics to me. Enjoy! Rick Thomas ihnp4!attunix!rbt 19-Jul-85 13:13:46-MDT,1475;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 19 Jul 85 13:08:49-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a000457; 19 Jul 85 9:03 EDT Received: from usenet by TGR.BRL.ARPA id a009110; 19 Jul 85 0:27 EDT From: Workstations Pubs 223-3439 Newsgroups: net.micro.cpm Subject: *** FOR SALE *** Message-ID: <3168@decwrl.UUCP> Date: 18 Jul 85 12:39:57 GMT Sender: daemon%decwrl.uucp@BRL.ARPA To: info-cpm@AMSAA.ARPA *** FOR SALE *** Epson Geneva (PX-8) laptop portable C/PM computer. 64K workspace, 80x8 display, built-in microcasette for storage, internal RAM disk for storage. Includes the latest operating system rev and comes complete with the following: Epson PF-10 3 1/2" microfloppy drive Epson integrated 120K RAM disk Epson CX-20 modem Wordstar ROM Spreadsheet and Scheduler ROM C/PM Utilities ROM Microsoft BASIC ROM All battery powered with AC adaptors, carry case for all, cables, manuals, large amount of public domain software tossed in free, including MEX, MODEM7, and many, many more. Entire system only for sale at a price well below retail. Everything is MINT and less than 9 months old. Contact Paul over the net, or call days at 617-493-3439 19-Jul-85 13:13:58-MDT,864;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 19 Jul 85 13:13:40-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id ab00457; 19 Jul 85 9:03 EDT Received: from usenet by TGR.BRL.ARPA id a009223; 19 Jul 85 0:30 EDT From: E Sciore Newsgroups: net.micro.cpm Subject: FOR SALE Boston area: VT180 Message-ID: <504@bu-cs.UUCP> Date: 18 Jul 85 21:40:44 GMT To: info-cpm@AMSAA.ARPA Subject: FOR SALE Boston area: VT180 Newsgroups: net.micro.cpm I am selling my "robin" system: vt100+z80 chip+4 disk drives. Software has SELECT, MULTIPLAN, BASIC. The system is basically unused. I had planned to use it for hacking, but I never got the time; most of its use has been in terminal mode. BEST OFFER. Ed Sciore BU Computer Science 353-3840 sciore@bu-cs 19-Jul-85 13:18:47-MDT,761;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 19 Jul 85 13:16:55-MDT Received: from almsa-1.arpa by AMSAA.ARPA id a020669; 19 Jul 85 13:36 EDT Received: by ALMSA-1 via almsab; 17 Jul 85 8:16 CDT Date: Wed, 17 Jul 85 8:18:29 CDT From: Crede Edens To: DDA@CMU-CS-C.ARPA cc: info-cpm@AMSAA.ARPA Subject: NEC 41256 chips Drew, I have an NEC APC computer which I would like to add RAM chips to increase my memory. I am having trouble finding out what chips fit the APC. Do you know if the NEC 41256 RAM chips sold by Microprocessors Unlimited will fit my machine? Thanks for any information you can give me. Crede Edens EDENS@ALMSA.ARPA 19-Jul-85 13:23:47-MDT,1665;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 19 Jul 85 13:22:10-MDT Received: from simtel20.arpa by AMSAA.ARPA id a021246; 19 Jul 85 13:44 EDT Date: Wed 17 Jul 85 20:48:38-MDT From: Mike Niswonger Subject: SB180 SBC CP/M machine To: info-cpm@AMSAA.ARPA cc: CNiswonger@SIMTEL20.ARPA Message-ID: <12127860716.15.CNISWONGER@SIMTEL20.ARPA> With all of the hoopla that Echelon has been putting on, they have kept us up to date on several continuing high-performance CP/M systems. The first of these systems (based on the Hitachi 64180) has appeared from MicroMint, the company made famous by BYTE magazine and Ciarcia's Circuit Cellar. A blurb has been released describing the board: The MICROMINT SB180 computer packs a lot of computing power in a very small package! The SB180, only 4" by 7 1/2", offers a Z-80 compatible CPU running at 6 MHz, 256K bytes of RAM, up to 32 K bytes of ROM, two serial ports, a parallel port, expansion bus, and an industry standard 765A-compatible disk controller for up to four disk drives - any combination of 3 1/2", 5 1/4", or 8" drives. Whether you use the SB180 as the basis for a complete disk based computer system or use its 32K of ROM space for a battery-powered dedicated controller application program, you will appreciate its ability to run standard 8080/8085 and Z-80 software at up to twice the speed of a 4 MHz Z-80. The description, price and order information can be found in the full file on SIMTEL20 as MICRO:SB180.TQT (squeezed format). -- Mike Niswonger ------- 19-Jul-85 13:33:50-MDT,1143;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 19 Jul 85 13:28:59-MDT Received: from simtel20.arpa by AMSAA.ARPA id a021269; 19 Jul 85 13:44 EDT Date: Thu, 18 Jul 1985 16:46 MDT Message-ID: From: CSTROM@SIMTEL20.ARPA To: INFO-CPM@AMSAA.ARPA Subject: 1k blockas arrive! At long last, we have an Xmodem that supports 1K blocks. The protocol, to be added to both the public domain and proprietary versions of Mex, is Ymodem, the YAM protocols to Christensen protocol. Ward has indicated that in his Byte article extending his protocol (yet to be written, but "real soon now"), he will give Ymodem his blessing. Please see the RELEASE.NTE file in the library for further details. Note that XMDM108 was released before we were made aware of XMDM107.FX2. The latter file is not in the library and the corrections therein should be made to XMDM108. Filename Type Bytes CRC Directory MICRO: XMDM107.FIX.1 ASCII 1349 C336H XMDM107.FX2.1 ASCII 1569 5901H XMDM108.LBR.1 BINARY 106112 7355H --Keith 19-Jul-85 13:49:19-MDT,888;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 19 Jul 85 13:44:37-MDT Received: from wiscvm.arpa by AMSAA.ARPA id a021557; 19 Jul 85 13:54 EDT Received: from (INNO)HWALHW5.BITNET by WISCVM.ARPA on 07/17/85 at 09:00:49 CDT Date: 17 JUL 85 10:17-N From: INNO%HWALHW5.BITNET@WISCVM.ARPA To: INFO-CPM@AMSAA.ARPA Subject:Cromemco-ZCPR3 For anyone who's interested: we have ZCPR3 running on a Cromemco. Inno Frencken (INNO@HWALHW5) Computing Centre Agricultural University Hollandseweg 1 6706 KN Wageningen The Netherlands phone: 08370-83875 20-Jul-85 05:59:10-MDT,677;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 20 Jul 85 05:55:12-MDT Received: from xerox.arpa by AMSAA.ARPA id a020803; 19 Jul 85 13:38 EDT Received: from Flora.ms by ArpaGateway.ms ; 19 JUL 85 08:49:32 PDT Date: 19 Jul 85 08:51:43 PDT (Friday) From: Chapman.ES@XEROX.ARPA Subject: Re: *** Epson Geneva FOR SALE *** In-reply-to: <3168@decwrl.UUCP> To: Workstations Pubs 223-3439 cc: info-cpm@AMSAA.ARPA Message-ID: <850719-084932-3163@Xerox> Paul You don't suggest a selling price, and I don't know what the original retail was. What do you want for your computer? Cheryl 20-Jul-85 06:23:40-MDT,1053;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 20 Jul 85 06:18:43-MDT Date: Fri, 19 Jul 85 15:25:27 EDT From: David Towson (SECAD) To: info-cpm@AMSAA.ARPA Subject: DON'T RESPOND TO FOR SALE NOTICES VIA THIS LIST!!! Readers of info-cpm - From time to time, people offer items for sale via usenet news and these notices are gatewayed to info-cpm. Use of the government sponsored Defense Data Network (over which we operate) for commercial purposes is not allowed. It is unavoidable that some such happenings will occur via the mechanism just described. The only way to stop that would be to cut the usenet gateway, which most agree would be shooting ourselves in the foot. But dammit, there is NO EXCUSE for carrying on sale negotiations via this newsgroup. I don't care how crummy your mailer is; if you can't send your reply to the seller without sending a copy to info-cpm THEN DON'T SEND IT AT ALL! Dave Towson, info-cpm-request 20-Jul-85 06:38:37-MDT,1219;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 20 Jul 85 06:36:34-MDT Received: from sdcsvax.arpa by AMSAA.ARPA id a006132; 20 Jul 85 7:02 EDT Received: from sdchema.chem.ucsd.arpa by sdcsvax.ARPA (4.24/4.41) id AA11395; Fri, 19 Jul 85 23:40:11 pdt Received: by sdchema.chem.ucsd.arpa (4.24) id AA04032; Fri, 19 Jul 85 23:39:31 pdt Date: Fri, 19 Jul 85 23:39:31 pdt From: Bret Marquis Message-Id: <8507200639.AA04032@sdchema.chem.ucsd.arpa> To: info-cpm@AMSAA.ARPA Subject: OTRONA ATTACHE 8:16 Cc: bang!dan@sdcsvax.ARPA The only known quantity of new CPM/MSDOS Otrona's are at Grindle Enterprises in San Diego, CA (619)571-3996.From what I have heard it is packaged with an unconditional 90 day warranty from the company mentioned above.I don't know the exact price, but somewhere around $1000.00.I do know they are factory sealed in the box.I found this information on a local board (619)283-0498. Fora total weight of 20lbs and 5 existing service locations in this area, its not a bad buy.I understand the the Mari company has sold all of their existing inventory. bang!dan@nosc Bang World Communications 22-Jul-85 05:50:01-MDT,1740;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 22 Jul 85 05:45:42-MDT Received: from simtel20.arpa by AMSAA.ARPA id a018776; 22 Jul 85 7:14 EDT Date: Thursday, 18 July 1985 18:21-MDT Message-ID: Sender: Andrew Moore From: Andrew Moore Subject: Apple-Cat insert for BYE ReSent-From: KPETERSEN@SIMTEL20.ARPA ReSent-To: Info-Cpm@AMSAA.ARPA ReSent-Date: Sat 20 Jul 1985 13:34-MDT It seems that Yet Another Bye insert for the Apple-Cat II modem has bombed. B3AC-0.INS for the BYE335 series of Bye programs has an "Await Ring" routine that checks for carrier only. It does not appear to check for RING. This may be because you need to have the Firmware chip in the modem card -- is this true? I have not been able to get any Apple-Cat insert working with any of the BYE programs so far (BYE3, also MBYE with -both- revisions of the insert file). Are these really bugs, or is the firmware chip required -- There is quite a demand for Apple-Cat II BYE overlays; perhaps someone with a bit more ex- perience at assembly language that I would be willing to contribute this over- lay, a TESTED, WORKING copy, to the MBYE/BYE collection. Please reply if you would be willing to write this insert, or if you know why I am having so much trouble getting this working, or if you know where I can get a working insert file. There are many RCP/M-SysOps who are anxious to get a system running, but have no BYE insert that seems to work. I was not able to contact Wayne Masters, author of the Apple-Cat insert. Thanks, -drew T.MOORE%MIT-EECS@MIT-MC.ARPA 22-Jul-85 05:50:28-MDT,1008;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 22 Jul 85 05:49:09-MDT Received: from simtel20.arpa by AMSAA.ARPA id a018783; 22 Jul 85 7:14 EDT Date: Sun 21 Jul 85 01:32:17-MDT From: Ron Fowler Subject: MEX 1.14 To: info-cpm@AMSAA.ARPA cc: cstrom@SIMTEL20.ARPA, kpetersen@SIMTEL20.ARPA Message-ID: <12128698785.13.RFOWLER@SIMTEL20.ARPA> I've just released MEX version 1.14. It fixes a few long-standing bugs, and adds support for 1K blocks (as implemented in the current (10.8) version of XMODEM. This enhancement complies fully with Chuck Forsberg's YMODEM specification for 1K packets. The files can be found on SIMTEL20, in MICRO: as follows: MEX114-U.LBR update files only MEX114.LBR entire package MEXOVL06.LQT List of all known overlays Note that MEXOVL06.LQT is also present in the two library files, so if you FTP either of these, you have the overlay list. --Ron Fowler ------- 22-Jul-85 06:15:11-MDT,1224;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 22 Jul 85 06:11:20-MDT Received: from simtel20.arpa by AMSAA.ARPA id a018803; 22 Jul 85 7:15 EDT Date: Sun, 21 Jul 1985 10:08 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: RCPM-Sysops@SIMTEL20.ARPA Cc: Info-Cpm@AMSAA.ARPA Subject: XMDM108 updates - XMDM109 released Someone please tell Paul Traina that I have just released XMDM109. I hear he's working on changes to XMDM108. Tell him PLEASE use XMDM109! It's available on my RCPM (Royal Oak) or the Sysop RCPM (Dave Hardy). After extensive testing of XMDM108 I found a few things that needed cleaning up. The changes were not in the area of the file transfer routines. XMDM108 is functional. There was a SERIOUS security problem, though, that needed to be fixed immediately. While I was at it, I set the equates to "generic" so the file could be assembled without editing for those who just wanted a simple transfer program between two computers. You'll find XMDM109.LBR in MICRO: after I have uploaded it (I'll announce it). --Keith 22-Jul-85 06:15:43-MDT,819;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 22 Jul 85 06:13:35-MDT Received: from simtel20.arpa by AMSAA.ARPA id a018808; 22 Jul 85 7:15 EDT Date: Sun, 21 Jul 1985 11:33 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Cc: RCPM-Sysops@SIMTEL20.ARPA Subject: XMDM109 released XMODEM version 10.9 is now available from Simtel20 as: Filename Type Bytes CRC Directory MICRO: XMDM109.LBR.1 BINARY 102656 CA53H Also available: XMDM108.MSG.1 ASCII 3257 0674H which explains the new 1k protocol capability (still compatible with earlier versions of XMODEM, MODEM7, and MEX). More details later. --Keith 22-Jul-85 06:39:24-MDT,1225;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 22 Jul 85 06:36:37-MDT Received: from simtel20.arpa by AMSAA.ARPA id a018819; 22 Jul 85 7:16 EDT Date: Sun, 21 Jul 1985 19:22 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Cc: Info-Modem7@SIMTEL20.ARPA, RCPM-Sysops@SIMTEL20.ARPA Subject: XMDM110 now available In-reply-to: Msg of 21 Jul 1985 17:00-MDT from CSTROM Date: Sunday, 21 July 1985 17:00-MDT From: CSTROM at SIMTEL20.ARPA To: Keith Petersen Re: XMDM108 updates - XMDM109 released Well, luckily Paul Traina based his 110 on Keith's 109 and I am about to upload XMDM110.LBR to Simtel. (Keith, please add it to .) His mods are in the form of bug fixes and addition of an Oxgate equate; the Ymodem protocol is untouched from previous versions according to the documentation. -Charlie It's now available in: Filename Type Bytes CRC Directory MICRO: XMDM110.LBR.1 BINARY 102656 2F5EH XMDM109 has been deleted. --Keith 22-Jul-85 07:20:00-MDT,799;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 22 Jul 85 07:15:29-MDT Received: from su-sierra.arpa by AMSAA.ARPA id a019080; 22 Jul 85 7:26 EDT Date: Sun 21 Jul 85 16:32:17-PDT From: IEEE CS Students Subject: Cromemco 4FDC/16FDC BIOS? To: INFO-CPM@AMSAA.ARPA Does anyone out there in Netland have a CP/M BIOS for a Cromemco system using the 4FDC or 16FDC disk controllers? I've heard that there may be one in the SIG/M library, but have not located it yet. If you know of such code, or (even better) a location on the NET which has a copy of it, please respond directly to IEEE-CS@SU-SIERRA.ARPA, as I am not currently on the distribution list. Regards, L. Brett Glass IEEE-CS@SU-SIERRA.ARPA ------- 22-Jul-85 09:53:37-MDT,853;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 22 Jul 85 09:53:20-MDT Date: Mon, 22 Jul 85 8:57:56 EDT From: Dave Towson (info-cpm-request) To: info-cpm@AMSAA.ARPA Subject: AMSAA.ARPA once again responding to it net address. Fellow CP/Mers - Now that BBN has repaired the lightning-damaged Interface Message Processor (IMP) through which AMSAA.ARPA access the net, mail sent to info-cpm can once again be delivered. We are still operating with a kludge, and physically pulling the plugs on the network at the close of each working day and at the first sign of a storm, but the mail is flowing. Efforts are underway to resume full-time network access. Feel free to submit articles to info-cpm. Dave Towson info-cpm-request@amsaa.arpa 22-Jul-85 13:37:54-MDT,685;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 22 Jul 85 13:34:52-MDT Received: from rand-unix.arpa by AMSAA.ARPA id a004368; 22 Jul 85 14:32 EDT Received: by rand-unix.ARPA; Mon, 22 Jul 85 11:15:25 pdt From: Bridger Mitchell Message-Id: <8507221815.AA26428@rand-unix.ARPA> Date: 22 Jul 85 11:15:22 PDT (Mon) To: info-cpm@AMSAA.ARPA Cc: randvax!bridger@rand-unix.ARPA Subject: CP/M S1 byte ? Can anyone enlighten me as to what the S1 (not S2) byte in the fcb and directory entry does, in both CP/M 2.2 and later systems? Are any applications or system utilities using it? --bridger mitchell 23-Jul-85 05:45:26-MDT,1091;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 23 Jul 85 05:43:04-MDT Received: from wiscvm.arpa by AMSAA.ARPA id a010266; 23 Jul 85 7:11 EDT Received: from (INNO)HWALHW5.BITNET by WISCVM.ARPA on 07/22/85 at 11:38:45 CDT Date: 22 JUL 85 17:39-N From: INNO%HWALHW5.BITNET@WISCVM.ARPA To: INFO-CPM@AMSAA.ARPA Subject:Interfacing Campbell C20/Rainbow 100 Has anybody ever interfaced a Campbell C20 cassette Interface with a Rainbow-100 microcomputer. C20 formats used are: - ASCII - DECODE Could someone please send me a sample program and specifications of hardware-settings. Inno Frencken (INNO@HWALHW5) Computing Centre Agricultural University Hollandseweg 1 6706 KN Wageningen The Netherlands phone: 08370-83875 23-Jul-85 06:09:59-MDT,867;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 23 Jul 85 06:09:21-MDT Received: from rand-unix.arpa by AMSAA.ARPA id a010769; 23 Jul 85 7:33 EDT Received: by rand-unix.ARPA; Mon, 22 Jul 85 14:05:28 pdt From: Bridger Mitchell Message-Id: <8507222105.AA00283@rand-unix.ARPA> Date: 22 Jul 85 14:05:19 PDT (Mon) To: info-cpm@AMSAA.ARPA Cc: randvax!bridger@rand-unix.ARPA Subject: umodem upgrade wishlist With the arrival of the YMODEM 1K packet protocol for MEX I hope one of the umodem guru's will sieze the opportunity to add support for the 1K packets! Could I also add my plea to put in the CRC option with auto-detection of CRC or CHECKSUM? We randomly encounter hardware problems that set the parity bit, which go undetected by a checksum 50% of the time! --bridger 23-Jul-85 14:19:59-MDT,904;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 23 Jul 85 14:19:18-MDT Received: from simtel20.arpa by AMSAA.ARPA id a028967; 23 Jul 85 15:37 EDT Date: Tue 23 Jul 85 13:32:35-MDT From: Larry Armijo Subject: Program Design Languages To: INFO-CPM@AMSAA.ARPA cc: COLSA@SIMTEL20.ARPA Message-ID: <12129354198.19.COLSA@SIMTEL20.ARPA> I have heard that there exist Program Design Languages (PDL's) which are used to develop preliminary versions of computer programs on larger computers. Does anyone know if PDL's are available for micros? I would think that these design languages would be very useful in the preliminary design of larger application programs. If you know of any PDL's for micros, either commercial or public domain, I would appreciate some guidance. Thanks in advance. Larry COLSA@SIMTEL20 ------- 24-Jul-85 06:55:04-MDT,2576;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 24 Jul 85 06:53:45-MDT Received: from mitre-gateway.arpa by AMSAA.ARPA id a016016; 24 Jul 85 7:19 EDT Date: 23 Jul 1985 20:12:49 EDT (Tuesday) From: Tom Reid (MS W932) Subject: Re: Program Design Languages In-Reply-to: Your message of Tue 23 Jul 85 13:32:35-MDT To: Larry Armijo Cc: info-cpm@AMSAA.ARPA While the Ada movement has tried to make the concept of PDLs concrete, the traditional notion is a "pidgen or structured English" statement of the intent of a procedure; the procedures being produced in a top-down, step-wise refinement process. The "syntax" is usually derived from an ALGOL base (Pascal, Ada, etc.). The object of a procedure written in PDL is WHAT the procedure is to accomplish, not HOW. The key words such as IF, THEN, WHILE, DO, BEGIN, etc. are there with the expressions and statements replaced with ENGLISH language statements. An example: WHILE train has not arrived DO IF you have a quarter THEN play pac-man ELSE IF you have a $1 bill THEN use coin changer ELSE try begging The English language statements can become comments in your final program. The object in this design phase is the overall structure and logic of what you want to accomplish, leaving the how to the next lower refinement. The Ada community has settled on the obvious: why should your PDL be any different from the programming language ==> the PDL for an Ada program should very closely resemble Ada so that there is little translation from the design to the implementation. In fact, you should be able to make the English language statements comments and/or replace them with the HOW. My feeling is that the PDL should be rather informal and very reader oriented with the intent of explaining what a routine is to do in the easiest, most understandable way without having a lot of syntax thrust upon you. PDL is for the human <--> the programming language is for the computer (I agree, too simplistic). There are some pseudo-compilers/interpreters which will execute and attempt to analyze PDL (ie., a logical expression is displayed and the user is prompted for a Y/N, an arithmetic expression is prompted for a number, and an English statement displayed as an effect - you are attempting to symbolicly execute your design). However, PDL languages with the usual notion of compilers are not really applicable. 24-Jul-85 07:00:03-MDT,971;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 24 Jul 85 06:55:53-MDT Received: from xerox.arpa by AMSAA.ARPA id a006585; 23 Jul 85 17:45 EDT Received: from PinotNoir.ms by ArpaGateway.ms ; 23 JUL 85 13:31:45 PDT Date: 23 Jul 85 08:58 PDT From: Ghenis.pasa@XEROX.ARPA Subject: Can't find XLISP12.COM To: info-cpm@AMSAA.ARPA cc: Ghenis.pasa@XEROX.ARPA Message-ID: <850723-133145-1192@Xerox> I need XLISP12.COM in a hurry, for distribution at an intro to LISP for local CPMers in Pasadena. I have searched most RCP/M systems in the Los Angeles area with no luck (just found an old version with several bugs). I got the source, but don't have Aztec C to compile it, so that didn't help either. If anyone knows of any RCP/M anywhere in the U.S. that has version 1.2 of XLISP.COM, please message me. (I cannot FTP) Thank you -- Pablo Ghenis Xerox Artificial Intelligence Systems Pasadena, CA 24-Jul-85 07:20:00-MDT,2924;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 24 Jul 85 07:16:08-MDT Received: from sdcsvax.arpa by AMSAA.ARPA id a011545; 24 Jul 85 7:07 EDT Received: by sdcsvax.ARPA (4.24/4.41) id AA04398; Wed, 24 Jul 85 00:40:45 pdt From: crash!ihom@sdcsvax.ARPA Message-Id: <8507240740.AA04398@sdcsvax.ARPA> Date: Tue, 23 Jul 85 21:52:27 PDT To: info-cpm@AMSAA.ARPA Subject: Turbo free space query Cc: info-pascal@brl.ARPA Does anyone know of a correct algorithm for finding the amount of free space on a drive in Turbo Pascal? My quick and dirty algorithm below outputs the corect results on my 128k floppies and 96k RAM disk, but errors on a hard drive. When a drive is activated in CP/M, an allocation vector is set up to determine the amount of free space remaining on the drive. This vector is composed of bits with a 0 indicating a free block and a 1 indicating an allocated block. Calling BDOSHL(alloc_vect) puts the address of the allocation vector (for the current selected drive) in the HL register pair. "temp" points to the address in memory where the allocation vector is stored. "quotient" incre- ments to the next consecutive 8-bit byte in the vector. "freek" tallies up all the 0 bits and is the value for the space remaining. Would someone compile and execute this, and mail me the results? (Be sure to change the constant "total_k" to match your drive size.) Or better yet, supply me with a correct algorithm... --Irwin Hom ...crash!ihom@ucsd ---------cut here---------cut here---------cut here---------cut here--------- program free_space; const alloc_vect = $1B; { Allocation vector address } total_k = 128; { since the total kilobytes is easy to find in the } { DPB, set to a constant here for this example } type alvec = byte; var cnt,freek,i : integer; quotient : byte; temp : ^alvec; begin writeln('Total k = ',total_k); { address of space allocation bit vector } temp := ptr(BDOSHL(alloc_vect)); freek := 0; { counter for free blocks } for i := 0 to (total_k div 8) - 1 do { 8 bits per byte } begin cnt := 0; { bit counter } quotient := mem[addr(temp^) + i]; writeln(quotient); while quotient > 0 do { kludge to convert from dec to bin } { 0 = free, 1 = allocated } begin { start from LSB to MSB } if not odd(quotient) then { even = free block } freek := freek + 1; cnt := cnt + 1; quotient := quotient div 2 end; freek := freek + (8 - cnt) { add remaining (0 bits) free blocks } end; writeln('Free k = ',freek) end. ----------------------------- 24-Jul-85 07:34:59-MDT,1151;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 24 Jul 85 07:31:39-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id aa28203; 24 Jul 85 7:57 EDT Received: from usenet by TGR.BRL.ARPA id a004513; 23 Jul 85 15:38 EDT From: Chuck McManis Newsgroups: net.micro.cpm,net.lang.pascal Subject: Turbo Pascal File Handling Message-ID: <24@intelca.UUCP> Date: 22 Jul 85 21:03:37 GMT Xref: seismo net.micro.cpm:4672 net.lang.pascal:360 To: info-cpm@AMSAA.ARPA Does anyone know of a collection of subroutines for Turbo Pascal to do file handling? Specifically, file look up, renaming, and deletion. I currently need ones for CP/M but anticipate a need in the near future for some MS-DOS ones also. Any pointers/References appreciated. --Chuck -- "Unix, the Teco of Operating Systems." - - - D I S C L A I M E R - - - {ihnp4,fortune}!dual\ All opinions expressed herein are my {qantel,idi}-> !intelca!cem own and not those of my employer, my {ucbvax,hao}!hplabs/ friends, or my avocado plant. :-} 24-Jul-85 08:14:49-MDT,1083;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 24 Jul 85 08:11:06-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a007498; 24 Jul 85 8:50 EDT Received: from usenet by TGR.BRL.ARPA id a011660; 23 Jul 85 22:04 EDT From: Stephen King Newsgroups: net.micro.cpm Subject: Re: using both side of disks Message-ID: <1632@dciem.UUCP> Date: 16 Jul 85 12:47:55 GMT To: info-cpm@AMSAA.ARPA -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Another consideration is the index hole, which is not going to be in the same place if the disc is flipped over. Thus, the disc drive must be able to cope with the index hole on the other side of the disc center line, or discs with two center holes must be used. (has anyone ever seen any of these?) -Another note- the certified side of a disc is *not* the side with the label on it. When inserting a disc into a drive with the label up, the read/write head accesses the disc surface through the slot in the *underside* of the disc jacket. -=-=-= sjk 24-Jul-85 08:29:46-MDT,1151;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 24 Jul 85 08:25:44-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a007541; 24 Jul 85 8:50 EDT Received: from usenet by TGR.BRL.ARPA id a012507; 23 Jul 85 22:56 EDT From: Jeffrey Miller Newsgroups: net.micro.cpm Subject: Re: using both side of disks Message-ID: <509@mmintl.UUCP> Date: 22 Jul 85 15:46:35 GMT To: info-cpm@AMSAA.ARPA * Double sided disks are usually for drives with 2 heads. The disks still only spin in one direction. You still face the problem of releasing dirt trapped when spinning in the original direction. I've been using the flip side of single sided disks on a single head drive for several years with no problems on either side of the disk, even though it spins both ways. ************************************************* * Jeff Miller * * Multimate International Corp. * * 52 Oakland Avenue * * East Hartford, CT 06108-9911 * * UUCP: * * ...!seismo!utah-cs!utah-gr!pwa-b!mmintl!jeffm * ************************************************* 24-Jul-85 09:00:05-MDT,1138;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 24 Jul 85 08:58:58-MDT Received: from brl-sem.arpa by AMSAA.ARPA id a009792; 24 Jul 85 9:44 EDT Received: from brl-tgr.arpa by BRL.ARPA id ge18539; 22 Jul 85 9:42 EDT Received: from usenet by TGR.BRL.ARPA id a010922; 21 Jul 85 5:51 EDT From: "James A. Jokl" Newsgroups: net.unix,net.micro.cpm,net.wanted Subject: 8085 Assembler Wanted Message-ID: <380@uvaee.UUCP> Date: 18 Jul 85 19:40:12 GMT Xref: seismo net.unix:5400 net.micro.cpm:4658 net.wanted:7227 To: info-cpm@AMSAA.ARPA We need an 8085 assembler for use in an undergraduate laboratory course this fall. The actual code will have to run on a Prime, however pointers to source in any language for any OS will be greatly appreciated. Thanx in advance James Jokl University of Virginia, EE CSNET: jaj@virginia ARPANET: jaj.virginia@csnet-relay USENET: ....!decvax!mcnc!ncsu!uvacs!uvaee!jaj Ma Bell (and relatives) 804-924-6101 24-Jul-85 09:04:39-MDT,1229;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 24 Jul 85 09:01:13-MDT Received: from brl-sem.arpa by AMSAA.ARPA id aa09792; 24 Jul 85 9:44 EDT Received: from brl-tgr.arpa by BRL.ARPA id gf18539; 22 Jul 85 9:42 EDT Received: from usenet by TGR.BRL.ARPA id a011085; 21 Jul 85 5:56 EDT From: HaymakerLL Newsgroups: net.micro.cpm Subject: Re: RE: --- Otrona Attache --- Message-ID: <3294@drutx.UUCP> Date: 19 Jul 85 21:19:06 GMT To: info-cpm@AMSAA.ARPA Attache a bummer ??? Think we all need more information than this to go by. Do you own one ? have you used one ?? What is wrong with it ?? Give us some details.. I own two, and am pleased, although the company is defunct, and I purchased then at a good deal less than what they were going for new. The only problem that I can see is Otrona put some inferior drives on it's earlier machines, and these have caused some problems and some of the earlier keyboards were trash. Also there isn't much software support, but most of the MSDOS and CPM stuff will run on them. Lets here the gripes but back them up !!! Linc Haymaker K0ZCO AT&T ISL Denver ihnp4!drutx!llh 24-Jul-85 12:53:40-MDT,869;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 24 Jul 85 12:53:33-MDT Received: from ames-vmsb.arpa by AMSAA.ARPA id a021276; 24 Jul 85 14:07 EDT Date: 24 Jul 85 10:46:00 PDT From: nep.pgelhausen@AMES-VMSB.ARPA Subject: --- Otrona (summary) --- To: info-cpm@AMSAA.ARPA Reply-To: nep.pgelhausen@AMES-VMSB.ARPA Since I seem to have started this whole thing, some people may have send some comments to me that did not get to the net. To sum up, the only gripes I have heard about the Attache seems to be when it is serving as an MS-DOS machine (specifics about MS-DOS problems, I don't know, but I have heard it is just generally slow & poor in performance...). NO-ONE who has clarified his view to me seems to think it is bad as a CP/M machine. -Richard Hartman max.hartman@ames-vmsb ------ 25-Jul-85 07:24:24-MDT,555;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 25 Jul 85 07:22:53-MDT Received: from crdc.arpa by AMSAA.ARPA id a026650; 24 Jul 85 16:06 EDT Date: Fri, 19 Jul 85 7:42:14 EDT From: George R Famini To: info-cpm@AMSAA.ARPA Subject: termcap for Osborne I We have an Osborne I running the public domain terminal emulator package OTERM, and I was wondering if anyone out there has the termcap for this particular configuration? Thanks George Famini 25-Jul-85 08:04:58-MDT,887;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 25 Jul 85 08:03:18-MDT Received: from sdcsvax.arpa by AMSAA.ARPA id a007097; 25 Jul 85 8:59 EDT Received: by sdcsvax.ARPA (4.24/4.41) id AA08848; Wed, 24 Jul 85 20:58:24 pdt From: crash!ihom@sdcsvax.ARPA Message-Id: <8507250358.AA08848@sdcsvax.ARPA> Date: Wed, 24 Jul 85 18:09:01 PDT To: info-cpm@AMSAA.ARPA Subject: Turbo free space query (error) Cc: info-pascal@brl.ARPA Yesterday, I left a message and algorithm about the problem I was having in finding the free space on a drive. Well, in less than twenty-four hours, I discovered my error -- I forgot to take the block size into consideration. Nevertheless, the algorithm works now. Disregard the previous sample program. I'll post the results if anyone is interested. --Irwin Hom ...crash!ihom@ucsd 25-Jul-85 08:23:28-MDT,1447;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 25 Jul 85 08:21:15-MDT Received: from brl-aos.arpa by AMSAA.ARPA id a007710; 25 Jul 85 9:14 EDT Received: from mit-multics.arpa by AOS.BRL.ARPA id a017253; 24 Jul 85 22:10 EDT Acknowledge-To: "Eric J. Swenson" Date: Wed, 24 Jul 85 22:03 EDT From: "Eric J. Swenson" Subject: Kaypro II File Transfer Program To: info-micro@BRL-VGR.ARPA, info-cpm@BRL.ARPA cc: ejs@MIT-MULTICS.ARPA, ejs@CISL-SERVICE-MULTICS.ARPA Message-ID: <850725020315.163903@MIT-MULTICS.ARPA> My wife has just gotten a Kaypro computer at work and needs a file transfer program of some sort. Can anyone give me pointers as to the best way to get a file transfer program (preferably Kermit or MODEM) onto that system? I suspect the 5 1/4 disk format is incompatible with other 5 1/4 disk formats (although I know nothing about Kaypros). Perhaps someone in the Boston area could provide me with a diskette or someone outside the area could mail me one. I'd pay postage and diskette charge. Any other help or pointers to help would be appreciated. Please send mail to me directly, at Swenson@MIT-Multics, not this list, as I do not read this list as a matter of course. Additionally, I'm sure members of this list have read countless such requests and would rather never hear one again. Sorry. 25-Jul-85 08:43:25-MDT,665;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 25 Jul 85 08:41:09-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id aa07680; 25 Jul 85 9:14 EDT Received: from usenet by TGR.BRL.ARPA id a016172; 25 Jul 85 4:41 EDT From: Henry Schaffer Newsgroups: net.micro.cpm Subject: Re: using both side of disks Message-ID: <1733@ecsvax.UUCP> Date: 24 Jul 85 01:32:53 GMT To: info-cpm@AMSAA.ARPA The people I know who use both sides of the disk in a single side drive (and call the disks "flippies") use a hole punch to punch the extra holes in the diskette jacket (*only*). --henry 25-Jul-85 11:04:33-MDT,739;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 25 Jul 85 11:01:24-MDT Received: from lll-mfe.arpa by AMSAA.ARPA id aa16026; 25 Jul 85 12:33 EDT Date: Thu, 25 Jul 85 12:20 EDT From: SECRIST%OAK.SAINET.MFENET@LLL-MFE.ARPA Subject: CP/M <--> VAX/VMS Floppy Utility To: INFO-CPM@AMSAA.ARPA Does anyone have a copy of the source code to a utility to read standard 8" SSSD CP/M floppies on a VAX under VMS (with an RX01/2) ? I got something from MIT-MC many moons ago, but have had little luck with it. I will be happy to make my findings available to the net. Thanks, Richard Secrist Science Applications Int'l. Corp. SECRIST%OAK.SAInet.MFEnet@LLL-MFE.Arpa 25-Jul-85 11:12:26-MDT,1158;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 25 Jul 85 11:08:42-MDT Received: from lll-mfe.arpa by AMSAA.ARPA id a016039; 25 Jul 85 12:33 EDT Date: Thu, 25 Jul 85 12:19 EDT From: SECRIST%OAK.SAINET.MFENET@LLL-MFE.ARPA Subject: IBM Document Interchange Standard To: INFO-CPM@AMSAA.ARPA In recent history IBM created a document interchange standard in order to share documents with embedded formatting and presentation information between different products. If I can believe InfoWorld (April 29, 1985, page 33) vendors like Micropro (Wordstar) and Microsoft have committed to supporting this standard, called "Document Interchange Architecture / Document Content Architecture" (DIA/DCA), and promise to incorporate into their products Real Soon Now. Does anybody know the name of the document that defines this standard, and/or has anyone heard of this before ?! Adoption of this standard could have interesting implications in microland. Thanks, Richard Secrist Science Applications Int'l. Corp. SECRIST%OAK.SAInet.MFEnet@LLL-MFE.Arpa 29-Jul-85 06:17:38-MDT,592;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 29 Jul 85 06:14:08-MDT Received: from usc-ecl.arpa by AMSAA.ARPA id a005903; 26 Jul 85 8:54 EDT Date: Thu 25 Jul 85 12:20:10-PDT From: Ted Shapin Subject: HP terminal emulator for CP/M? To: info-cpm@AMSAA.ARPA Postal-address: Beckman Instruments, Inc. Postal-address: 2500 Harbor X-11, Fullerton, CA 92634 Phone: (714)961-3393 Does anyone know of an HP block mode terminal emulation program for CP/M-80 that emulates for example an HP2622? Ted. ------- 29-Jul-85 06:33:53-MDT,8486;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 29 Jul 85 06:28:30-MDT Received: from simtel20.arpa by AMSAA.ARPA id a004669; 29 Jul 85 7:10 EDT Date: Sat, 27 Jul 1985 21:56 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: BYE337 remote console program available BYE337 is now available from SIMTEL20. Here is an except from the source code comments (a complete list of files follows): This program allows modem callers to use a CP/M system just as if they were seated at the system console. Special assembly-time options al- low limiting the caller's access by password and/or access to only a message-service program. A number of external inserts are available to adapt this program to various computers, clocks and modems. It may be assembled with ASM, LASM, MAC or M80. If the ZCPR3 equate is set YES, a macro assembler such as MAC or M80 will be required. If the program will not assemble correctly with M80, check the insert that was added, it likely is not configured properly. There was a program called BYE5 that was released recently. This is a spin-off on BYE335 and has no advantages over the current release of BYE. If you have BYE5, please understand that this is newer and is the "proper" continuation of the BYE family. BYE3 is placed in the public domain. It may be updated or altered for your personal use. I'd like to try and consolodate any new releases, so we can avoid another MODEM7 fiasco. If you have changes that you feel should be included in future releases, please forward them to Saratoga OxGate 408/354-5934 (pst) v337 - 07/24/85 - *All BYE dependant routines may be accessed through BDOS calls now. BYE intercepted the BDOS vector anyway, so I figured we might as well do something with it. BYEBDOS calls start at 80 decimal. See BYE337.DOC for more information. *Striped out many comments, because I've written and included a comprehensive BYE manual. *Added fixes for: Anchor modems, MBBS disconnect, and function keys generating nulls. *Removed BYELOW equate...you MUST to run BYE low now. Sorry. *If you're not using the NO25TH option, the LCDATA buffer will be a single entry (a 0) so your BBS can sense you're not using the NO25TH deal and not overrwrite BYE. *Removed manditory NO25TH when using OxGate, as OxGate's now smart enough to sense that you don't have the buffer (see above). *Added NEEDLC. If yes, then will include code to read lastcaller. *If you have your own modem overlay, please remove the "ANI 7FH" or "ANI 127"'s that are in it. This will allow 8-bit I/O for programs like XMODEM. *Removed low-memory bytes LHOUR/LMIN-- XModem and BBS can access them by looking at RTCBUF+7 and RTCBUF+8 *Made the two subroutines: BCDBIN and BINBCD deleteable. If you need them, then set BIN2BCD and/or BCD2BIN to "YES", otherwise they won't be assembled into the code. *If TIMEON is y