1-Feb-84 11:42:47-MST,961;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 1 Feb 84 11:42:42-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 1 Feb 84 3:42 EST Received: From Sri-Unix.ARPA by BRL via smtp; 1 Feb 84 3:31 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 1 Feb 84 0:23-PST Date: 30 Jan 84 19:42:26-PST (Mon) To: info-cpm@brl From: hplabs!hao!kpno!grandi@ucb-vax Subject: How does a VT180 send break? Article-I.D.: kpno.291 I'm trying to get my DEC VT180 to send out a break under program control. In other words, has anyone a working modem7 SENDBRK routine for the VT180? I know the machine is capable of it since it nicely breaks in terminal, but my ignorant attempts to make the 8251 do my bidding have been dismal failures. -- Steve Grandi, Kitt Peak National Observatory, Tucson, AZ, (602) 325-9228 {arizona,decvax,hao,ihnp4,astrovax,utastronomy,amd70} !kpno!grandi 1-Feb-84 13:14:36-MST,793;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 1 Feb 84 13:14:32-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 1 Feb 84 13:48 EST Received: From Sri-Unix.ARPA by BRL via smtp; 1 Feb 84 8:58 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 1 Feb 84 5:54-PST Date: 28 Jan 84 0:46:05-PST (Sat) To: info-cpm@brl From: pur-ee!uiucdcs!parsec!graham@ucb-vax Subject: Re: MDM719 now available - (nf) Article-I.D.: uiucdcs.5221 #R:sri-arpa:-1585500:parsec:48000006:000:193 parsec!graham Jan 27 18:42:00 1984 How do those of us not on the ARPANET get stuff from this wondrous SIMTEL20?? Marv Graham; ConVex Computer Corp. {allegra,ihnp4,uiucdcs,ctvax}!parsec!graham O: (214)669-3700 H: (214)931-7924 2-Feb-84 08:46:22-MST,614;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 08:46:17-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Feb 84 3:18 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 1 Feb 84 22:33 EST Date: Wed 1 Feb 84 19:40:32-PST From: Leslie Zatz Subject: MDM??? To: INFO-CPM@BRL.ARPA Can someone let us know what is going on with the MDM series? It looks like MDM720 has come out from I. Hoff but there had been a previous posting indicating that R. Fowler was putting out MDM720. Are these the same? ------- 2-Feb-84 08:49:07-MST,1064;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 08:49:03-MST Received: From Sri-Kl.ARPA by BRL-VGR via smtp; 2 Feb 84 7:32 EST Date: Thu 2 Feb 84 04:34:28-PST From: Jon L. Spear Subject: Z-80, CP/M Emulator for Macintosh? To: Info-CPM@BRL-VGR.ARPA, info-micro@MIT-MC.ARPA I am not sure what possessed me to do it, but I just bought an Apple Macintosh. Nifty machine, but a dirth of software -- no programming language available yet (to users). Has anyone done Z80 or 8080 emulators for the 68000 so that they could run the thousands of CP/M programs in the world? I am not too concerned with the obvious media problems. The question is whether it is feasible to write an emulator that would fit in the 128K RAM, allow a reasonable size TPA, and run CP/M programs at a speed close to that of a 2MHZ Z-80. (emulated on the 8MHZ 68000). With a Z-80 costing only a few bucks, a hardware solution might be much more reasonable. Comments? --Jon ------- 2-Feb-84 08:49:15-MST,569;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 08:49:12-MST Received: From Sumex-Aim.ARPA by BRL-VGR via smtp; 2 Feb 84 7:58 EST Date: Thu 2 Feb 84 05:00:26-PST From: Sam Hahn Subject: Re: Z-80, CP/M Emulator for Macintosh? To: OTHB@SRI-KL.ARPA cc: Info-CPM@BRL-VGR.ARPA, info-micro@MIT-MC.ARPA In-Reply-To: Message from "Jon L. Spear " of Thu 2 Feb 84 04:58:33-PST Are you sure the 68k is actually running at 8Mhz, and not 5 Mhz, as I thought? ------- 2-Feb-84 08:53:35-MST,1467;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 08:53:31-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Feb 84 9:41 EST Received: From Radc-Tops20.ARPA by BRL via smtp; 2 Feb 84 9:35 EST Date: Thu 2 Feb 84 09:37:30-EST From: Gern Subject: New MAILING-LIST: INFO-HZ100 To: zellich@OFFICE-3.ARPA cc: INFO-HZ100@RADC-TOPS20.ARPA, INFO-MICRO@BRL.ARPA, INFO-CPM@BRL.ARPA To whom it may concern, The INFO-HZ100 mailing list is now a reality. INFO-HZ100 is a forum for discussion concerning topics related to the Zenith Z-100 (Heath H-100) family of professional desktop computers. Messages are collected into digests and distributed as the volume of mail dictates. Periodically, useful knowledge and items generated from the digests and other random sources will be edited into a newsletter for distribution to both network and non-network interested groups. Any comments, suggestions, help, knowledge, software, ideas, file space, etc., would be greatly appreciated. Future plans are to have a library of Z-100 software, and digest & newsletter archives. All requests to this list should be directed to: INFO-HZ100-REQUEST@RADC-TOPS20 Submissions to the digest should be directed to: INFO-HZ100@RADC-TOPS20 Coordinator: Dave Gubbins (Gern) ------- 2-Feb-84 10:22:24-MST,647;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 10:22:14-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Feb 84 11:28 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 2 Feb 84 11:20 EST Date: Thu, 2 Feb 84 08:23 PST From: DHead.es@PARC-MAXC.ARPA Subject: Public domain for -86 To: INFO-CPM@BRL.ARPA Does anyone know if much is being done in the area of RCPM systems and public domain software for CP/M-86? I saw a couple of SIG/M disks with translations of stuff like Vfiler, but are there any more sources? Any pointers would be appreciated. ~~Dave~~ 2-Feb-84 10:22:37-MST,898;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 10:22:31-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Feb 84 11:27 EST Date: Thu, 2 Feb 84 11:19:50 EST From: Rick Conn To: info-cpm@brl Subject: SYSLIB 3.0 The first step in the creation of ZCPR3 is now complete (at least for the time being). This is the creation of SYSLIB 3.0 from SYSLIB 2.7. The following message is a rather complete documentation of the differences between these two. If anyone knows of any bugs I have not corrected or has any ideas as to what additional features should go into SYSLIB 3.0, please drop me a message. Note that Z3LIB, which contains the ZCPR3-specific utilities, is now a separate library from SYSLIB 3.0. Z3LIB is still evolving and details will be released later on it. Rick 2-Feb-84 10:48:20-MST,11371;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 10:47:50-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Feb 84 11:28 EST Date: Thu, 2 Feb 84 11:21:19 EST From: Rick Conn To: info-cpm@brl Subject: SYSLIB 2.7 and SYSLIB 3.0 differences SYSLIB 3.0 Upgrade Notes Notes on Changes in SYSLIB From SYSLIB 2.7 to SYSLIB 3.0 Richard Conn February 1, 1984 This document summarizes the changes made to SYSLIB under Version 3.0 from the previous version, 2.7. SYSLIB 3.0 consists of over 210 routines in over 150 modules, each module residing in a separate file. A. Changes Made to Existing Routines and Modules 1. All of the ZCPR2-specific routines have been removed from SYSLIB. These are now placed in a separate library and have been updated to reflect ZCPR3 rather than ZCPR2. SYSLIB 2.7 is still to be used to support ZCPR2, while SYSLIB 3.0 and Z3LIB are to be used to support ZCPR3. 2. Disk-Based Named Directories are not supported in Z3LIB. The ZDNAME routine has been omitted, and ZCPRQ2, ZFNINIT, ZDNFIND, and ZFNAME have been changed to remove any features relating to disk-based named directories. Memory-based named directories are still supported. Modules: SZFNAME.MAC and SZGPINS.MAC changed and now named Z3FNAME.MAC and Z3GPINS.MAC. Also, to test the value of this change, XD was reassembled, and the new COM file is 11 blocks (almost 1.5K) smaller than the old version. 3. All math routines have been broken out into separate modules as appropriate. There are now 12 math modules in SYSLIB. Modules: SMATH.MAC removed, SMTHnn (01 <= nn <= 12) added. 4. A bug has been corrected in EVAL10 which prohibited accurate processing of numbers greater than 8 bits. Module: SEVAL1.MAC. 5. Version Number is now 3.0. Module: SVERSION.MAC. 6. A bug has been corrected in DIRF and DIRFS in which the proper return code was not returned in A/PSW. Internal documentation was also cleaned up. Also, the SDIR.MAC module was broken up into a set of independent modules, named SDIRxx.MAC (00 <= xx <= 10), SDIR.MAC, SDIRHDR.LIB, and SDIRBF.MAC. 7. The SUD module was broken up into SUD1.MAC, SUD2.MAC, and SUD3.MAC. 8. The routines F$MAKE, F$READ, and F$WRITE were changed to return proper PSW flag settings. Now return codes can be examined without an ORA A after the routine call. Modules: SFMAKE.MAC, SFREAD.MAC, SFWRIT.MAC. Page 1 SYSLIB 3.0 Upgrade Notes 9. The following SYSLIB routines have been modified or improved: Routine Module Routine Module ------- ------ ------- ------ PADC SPADC PA2HC SPA2HC PHL4HC SPHL4HC PHL5DC SPHL5DC PHLDC SPHL5DC LADC SLADC LA2HC SLA2HC LHL4HC SLHL4HC LHL5DC SLHL5DC LHLDC SLHLDC B. New SYSLIB Routines and Modules 1. The following numeric output routines have been added: Routine Module Function ------- ------ -------- LAFDC SLAFDC Print A as Floating Decimal to LST: LHLFDC SLHLFDC Print HL as Floating Decimal to LST: MAFDC SMAFDC Print A as Floating Decimal to Memory MHLFDC SMHLFDC Print HL as Floating Dec to Memory PAFDC SPAFDC Print A as Floating Decimal to CON: PHLFDC SPHLFDC Print HL as Floating Decimal to CON: SA2HC SSA2HC Print A as 2 Hex Chars to S Output* SA3DC SSADC Print A as 3 Dec Chars to S Output SADC SSADC Print A as Decimal Chars to S Output SAFDC SSAFDC Print A as Floating Dec to S Output SHL4HC SSHL4HC Print HL as 4 Hex Chars to S Output SHL5DC SSHL5DC Print HL as 5 Dec Chars to S Output SHLDC SSHL5DC Print HL as Dec Chars to S Output SHLFDC SSHLFDC Print HL as Floating Dec to S Output * S Output is the new SYSLIB Switched Output feature, where output can be selected to go to any one of four combinations of CON: or LST: dynamically. 2. The following S-Output Routines have been added: Routine Module Function ------- ------ -------- SCOUT SSCOUT Print Char A with Ctrl Char Processing to S Output SCRLF SSCRLF Print New Line to S Output SCTLFL SSCTLFL Switch Control Flag SOUT SSOUT Print Char A to S Output SPRINT SSPRINT Print String at Ret Adr to S Output SPSTR SSPSTR Print String at HL to S Output Page 2 SYSLIB 3.0 Upgrade Notes B. New SYSLIB Routines and Modules, Con't 3. The following Byte-Oriented File I/O routines, which support variable-sized buffers for blocking/deblocking, have been added. All are in the SFXIO.MAC Module. Routine Function ------- -------- FXI$OPEN Open File for Input FXI$CLOSE Close Input File FXO$OPEN Open File for Output FXO$CLOSE Close Output File FX$GET Get Byte from Input File FX$PUT Put Byte to Output File 4. An F$SIZE routine has been added which computes the file size of a file to the nearest K, ignoring grouping factors. Just the first 12 bytes of the FCB are passed to F$SIZE. Module: SFSIZE.MAC. 5. A set of routines have been added for character testing and string parsing functions. Each is contained in its own module, which is named after it with an S prefix. These routines are: Routine Function ------- -------- ISALNUM Is Alphanumeric ISALPHA Is Alphabetic ISCTRL Is Control ISDIGIT Is Digit ISGRAPH Is Graphic ISHEX Is Hexadecimal ISPRINT Is Printable ISPUN Is Punctuation ISSP Is Space Char SKNPUN Skip Over Non-Punctuation Chars SKNSP Skip Over Non-Space Chars SKPUN Skip Over Punctuation Chars SKSP Skip Over Space Chars 6. New dynamic buffer allocation routines have been added. Both are in the SALLOC.MAC Module. Routine Function ------- -------- ALLOC Allocate N Bytes from Dynamic Buffer IALLOC Specify Bounds of Dynamic Buffer Page 3 SYSLIB 3.0 Upgrade Notes B. New SYSLIB Routines and Modules, Con't 7. The following character I/O routines have been added: Routine Module Function ------- ------ -------- BIN SBIN Input CON: Char via BDOS BIST SBIST Input CON: Char Status via BDOS BOUT SBOUT Output Char to CON: via BDOS CAPIN SCAPIN Input CON: Char and Capitalize CAPINE SCAPIN CAPIN and Echo 8. There are now eight SYSTEST programs, designed to test the various features of SYSLIB 3.0. These programs are SYSTEST.MAC and SYSTESTn.MAC (1 <= n <= 7). 9. The following FCB File Name and Type Output routines have been added: CON: LST: Switched Memory Function ---- ---- -------- ------ -------- PFN1 LFN1 SFN1 MFN1 12 Chars, Embedded Spaces PFN2 LFN2 SFN2 MFN2 N-Chars, No Spaces PFN3 LFN3 SFN3 MFN3 12 Chars, Trailing Spaces Each routine is in its own module, which is named after the routine but is prefixed with an S (ie, PFN1 is in SPFN1.MAC). 10. The following User Area Manipulation routines have been added: Routine Module Function ------- ------ -------- GUA SGUA.MAC Get Current User Area in A SUA SSUA.MAC Set User Area in A 11. The following file attribute manipulation routines have been added: Routine Module Function ------- ------ -------- GFA SGFA.MAC Return File Attributes SCFA SSCFA.MAC Set and Clear File Attributes SFA SFA.MAC Set File Attributes Page 4 SYSLIB 3.0 Upgrade Notes B. New SYSLIB Routines and Modules, Con't 12. The following random file access routines have been added: Routine Module Function ------- ------ -------- R$READ SRREAD Random Block Read R$WRITE SRWRITE Random Block Write C. Documentation 1. All of the SYSLIB.HLP files have been rewritten, and many new files have been added. These files completely document SYSLIB 3.0. There are 20 SYSLIB 3.0 HLP Files. 2. Realizing the investment some people have in hard copy of the SYSLIB 2.4 documentation, I do not intend to release new SYSLIB 3.0 manuals at this time. This update and the four Z2SYS- n.MOD files will serve to bring your documentation up to date. The SYSLIBx.HLP files should be used as the complete, on-line authoritative reference. Richard Conn Page 5 2-Feb-84 11:27:30-MST,1105;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 11:27:25-MST Date: Thu, 2 Feb 84 12:43:14 EST From: Dave Towson (info-cpm) To: info-cpm@brl-vgr Subject: General interest. I just received a request from Larry Byard to change his address for receiving this list form byard@dca-ems to byard@obl. When I sent him a reply saying that the change had been made, he sent the following message. I haven't studied the list to see who else might be on it from outside of the continental US, but if we didn't have it already, we now have an international list. ----- Forwarded message # 1: Received: From Dca-Ems.ARPA by BRL-VGR via smtp; 2 Feb 84 3:32 EST Date: 2 February 1984 03:12 EST From: Byard @ DCA-EMS To: cpmlist @ brl-vgr Date: February 2, 1984 Re: Re: Address for receiving INFO-CPM Text: Thank you, Dave. As a matter of possible interest, OBL is located in Oberursal, West Germany. Larry ----- End of forwarded messages Dave Towson info-cpm-request@brl-vgr 2-Feb-84 12:30:50-MST,605;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 12:30:43-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 2 Feb 84 14:04 EST Date: Thu 2 Feb 84 12:04:23-MST From: Keith Petersen Subject: MODEM program wanted for C64 CP/M To: Info-Micro@BRL-VGR.ARPA, Info-Cpm@BRL-VGR.ARPA Does anyone have a Ward Christensen protocol MODEM program that works with the Commodore 64 CP/M cartridge? I have several friends who are trying to figure out how to address a modem port for serial I/O while in CP/M. ------- 2-Feb-84 14:12:50-MST,823;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 14:12:45-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Feb 84 15:46 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 2 Feb 84 15:41 EST Delivery-Notice: While sending this message to BRL.ARPA, the SUMEX-AIM.ARPA mailer was obliged to send this message in 50-byte individually Pushed segments because normal TCP stream transmission timed out. This probably indicates a problem with the receiving TCP or SMTP server. See your site's software support if you have any questions. Date: Thu 2 Feb 84 12:32:14-PST From: Dan Kent Subject: what is ZCPR3 ?? To: info-cpm@BRL.ARPA I'm a newcomer to this world of CPM-INFO. Is there a glossary somewhere? ------- 2-Feb-84 19:23:03-MST,1488;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 2 Feb 84 19:22:56-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Feb 84 20:58 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 2 Feb 84 20:49 EST Return-Path: Received: from lanl by SUMEX-AIM.ARPA with TCP; Thu 2 Feb 84 13:23:19-PST Date: 2 Feb 1984 14:15:43 (Thu) From: MAILER-DAEMON@lanl Subject: Undeliverable mail To: KENT@sumex-aim ReSent-date: Thu 2 Feb 84 17:53:49-PST ReSent-from: Dan Kent ReSent-to: INFO-CPM@BRL.ARPA Mail addressed to post-info-cpm at a could not be sent. 421 Mail system botch at LANL-A ------- Unsent message is below ------- Date: 2 Feb 1984 14:05:37-MST From: KENT@SUMEX-AIM Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Feb 84 15:46 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 2 Feb 84 15:41 EST Delivery-Notice: While sending this message to BRL.ARPA, the SUMEX-AIM.ARPA mailer was obliged to send this message in 50-byte individually Pushed segments because normal TCP stream transmission timed out. This probably indicates a problem with the receiving TCP or SMTP server. See your site's software support if you have any questions. Date: Thu 2 Feb 84 12:32:14-PST From: Dan Kent Subject: what is ZCPR3 ?? To: info-cpm@BRL.ARPA I'm a newcomer to this world of CPM-INFO. Is there a glossary somewhere? ------- 3-Feb-84 08:38:48-MST,848;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 08:38:42-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 3 Feb 84 3:30 EST Received: From Sri-Unix.ARPA by BRL via smtp; 3 Feb 84 3:21 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 3 Feb 84 0:08-PST Date: 31 Jan 84 19:59:01-PST (Tue) To: info-cpm@brl From: pur-ee!uiucdcs!ccvaxa!mikel@ucb-vax Subject: squeeze/unsqueeze - (nf) Article-I.D.: uiucdcs.5289 #N:ccvaxa:24000001:000:272 ccvaxa!mikel Jan 17 14:45:00 1984 I need help getting a copy of the squeeze and unsqueeze programs. I have uploaded a cpm disk on the vax and want to unsqueeze some of the files. Does anyone have a copy that i can get? Thanks, Mikel Matthews pur-ee!uiucdcs!ccvaxa!mikel mikel@compion 3-Feb-84 08:39:26-MST,1840;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 08:39:17-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 3 Feb 84 3:54 EST Received: From Sri-Unix.ARPA by BRL via smtp; 3 Feb 84 3:48 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 3 Feb 84 0:40-PST Date: 31 Jan 84 20:22:23-PST (Tue) To: info-cpm@brl From: pur-ee!uiucdcs!parsec!ctvax!uokvax!emjhm@ucb-vax Subject: CONIX for CP/M - (nf) Article-I.D.: uiucdcs.5295 #N:uokvax:7900012:000:1244 uokvax!emjhm Jan 30 17:32:00 1984 Does anyone know anything about the CONIX shell that runs on 32K or greater CP/m systems. I saw a full page advertisement in the Feb. "Computer Shopper" that said it could handle quite a few of the nice things that UNIX has to offer like file pipes/tees and re-direction to name a few. It looks pretty decent for those of us who can't afford full blown UNIX or who are stuck with mere finite spaced, relatively slow floppy disks systems and 8080 or Z-80 processors. Some of the nice things about CONIX seem to be that you can use only the parts that you want or disable functions or frills that you don't need or haven't the capacity for. They also say a few things in their ad which seem to be contradictory. Like for instance they say that the CONIX command processor will run under any CP/M and BIOS on virtually any machine without modification and in the same breath say that it can access 16 disk drives(actual or virtual if they don't exist). How would that be possible without at least fiddling with the BIOS jump vectors? Some folks have their CBIOS in ROM. Will it run on their system? I'd appreciate hearing from anyone that has heard anything or is presently using CONIX. There's got to be a gotcha somewhere. Jim Miller 3-Feb-84 08:39:35-MST,1271;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 08:39:28-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 3 Feb 84 3:54 EST Received: From Sri-Unix.ARPA by BRL via smtp; 3 Feb 84 3:49 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 3 Feb 84 0:39-PST Date: 31 Jan 84 20:22:11-PST (Tue) To: info-cpm@brl From: pur-ee!uiucdcs!parsec!ctvax!uokvax!emjhm@ucb-vax Subject: Re: Zenith 100 - (nf) Article-I.D.: uiucdcs.5294 #R:ut-ngp:-24200:uokvax:7900011:000:670 uokvax!emjhm Jan 30 17:01:00 1984 The Z-100 does indeed hane an IEE-696 S-100 bus in it. The 8085 and 8088 processors work in tandem and appear as a single master cpu on the bus. As for "Standard S-100 single board processors and hard disk controllers" just play like you have a processor and memory board installed in the S-100 bus that can't be removed. The S-100 bus wil tolerate slave processors on the bus but the slave will have to be given the bus by the 8085 or 8088 processors that are always present and must be running to keep the display going. I'm not sure how much trouble you would have in trying to get a single board S-100 processors to play slave to the Z-100 processors. Jim Miller 3-Feb-84 08:41:26-MST,2179;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 08:41:00-MST Received: From Csnet-Cic.ARPA by BRL-VGR via smtp; 3 Feb 84 7:18 EST Date: 3 Feb 1984 01:23:16-EST From: erh%virginia@csnet-relay Return-Path: To: Info-Cpm@brl-vgr Via: Virginia; 3 Feb 84 6:16-EST 1 I have recently obtained MDM716 and I am gratified with its performance. I submit the following suggestions in hope of making the excellent thing better: 1. The overlay method of customizing the program is still too specific. Ideally, there should be two clearly defined overlays: -- an outer one containing all procedures for a given modem or modem setup. There would be one overlay for PMMI, another for Hayes, etc. This overlay should contain well isolated procedures to hang up the modem, send a break, etc. The way it is now, a Hayes user has to wade through all the PMMI stuff to find the relevant code (not mentioning the fact that the code for the other modems just sits there and uses the precious K's). To wit: Hayes can be told to hang up by dropping DTR, which is infinitely faster than sending the #$%! pluses, but the DISCONNECT stuff is buried too well for me to bother. That outer overlay should contain procedures to do all kinds of exotic things, such as change the baud rates, etc. Use flags to indicate which procedures are valid. -- an inner one dealing with the i/o hardware: sending and receiving characters from the modem. And please, have somewhat more general procedures. The functions to mask a status byte are cute, but too primitive. The guys using interrupts and BIOS bufferring of incoming characters would prefer to use a system or BIOS call to get/test for input characters. 2. The dialing procedures could be somewhat smarter. Use some way of separating the decription from the phone number. The way it is now, all digits get dialed out, including things like "Gandalf1, 1200bps...". I also agree with a recent remark about necessity of controlling the pulse/tone dialing mode. ~v~ Ed Howorka, erh@uvacs ~ 3-Feb-84 08:43:22-MST,699;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 08:43:18-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 3 Feb 84 9:07 EST Received: From Sri-Unix.ARPA by BRL via smtp; 3 Feb 84 8:59 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 3 Feb 84 5:55-PST Date: 1 Feb 84 16:57:32-PST (Wed) To: info-cpm@brl From: ihnp4!houxm!mhuxl!aluxp!wrbull@ucb-vax Subject: Access to SIMTEL Article-I.D.: aluxp.1179 Can ATT Bell Laboratories access SIMTEL and if yes, how? Any help is greatly appreciated. Thanks in Advance... W.R.Bullman (215)439-5550 Path:(I'm new on the net but...) ...aluxp!wrbull (???) 3-Feb-84 09:51:16-MST,464;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 09:51:12-MST Date: Fri, 3 Feb 84 11:29:11 EST From: Dave Towson (info-cpm) To: info-cpm@brl-vgr Subject: Burton, where are you? I had a request to add AMD70!FORTUNE!BURTON@BERKELEY to this list. The mailer won't accept that address. Got another address, Burton? Dave Towson info-cpm-request@brl-vgr 3-Feb-84 10:27:04-MST,682;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 10:26:59-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 3 Feb 84 11:54 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 3 Feb 84 11:43 EST Date: Fri, 3 Feb 84 08:45 PST From: MMOON.ES@PARC-MAXC.ARPA Subject: Re: Public domain for -86 In-reply-to: "DHead's message of Thu, 2 Feb 84 08:23 PST" To: DHead.ES@PARC-MAXC.ARPA cc: INFO-CPM@BRL.ARPA The only CP/M-86 related PD software I have seen was on Sigi Kluger's system in El Paso, Texas, but then I do very littlte long-haul searching or downloading due to 300 baud limits. MMoon.es 3-Feb-84 11:27:36-MST,1035;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 11:27:32-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 3 Feb 84 12:55 EST Received: From Rochester.ARPA by BRL via smtp; 3 Feb 84 12:40 EST Received: by sen.rochester (3.327.3N) id AA10011; 3 Feb 84 12:41:16 EST (Fri) Received: by cay.Rochester (3.327.3N+) id AA05568; 3 Feb 84 12:37:57 EST (Fri) Message-Id: <8402031741.10011@sen.rochester> Date: 3 Feb 84 12:41:16 EST (Fri) From: Mike Ciaraldi Subject: Re: PD programs to do file compares... To: LIN@mit-ml.ARPA, info-cpm@brl.ARPA There are BDS C programs in the public domain to do file compartisons. These are avaialble on one of the CPMUG volumes. The set includes DIF2, which is like the Unix DIFF (it finds the differences), and SSED, which is a stream editor that can use the difference files to turn one text into another. I have used them on CP/M-80, and they work OK. Mike Ciaraldi ciaraldi@rochester 3-Feb-84 11:30:02-MST,1082;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 11:29:58-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 3 Feb 84 12:54 EST Received: From Rochester.ARPA by BRL via smtp; 3 Feb 84 12:38 EST Received: by sen.rochester (3.327.3N) id AA09926; 3 Feb 84 12:38:48 EST (Fri) Received: by cay.Rochester (3.327.3N+) id AA05558; 3 Feb 84 12:35:44 EST (Fri) Message-Id: <8402031738.9926@sen.rochester> Date: 3 Feb 84 12:38:48 EST (Fri) From: Mike Ciaraldi Subject: Floppies on VAX To: allegra!fortune!burton@Rochester.ARPA, allegra!rochester!ciaraldi@Rochester.ARPA Cc: info-cpm@brl.ARPA There is a program called CPMUTL.C on the SIMTEL archives in MICRO:. This is supposed to run on a 780 and let you read and write CP/M floppies under Unix. I have not tried it, so I don't know if 1) it works, and 2) it would work on a 750. But, you might try. This message is in response to a question from allegra!fortune!burton. Mike Ciaraldi ciaraldi@rochester 3-Feb-84 14:26:40-MST,1269;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 14:26:35-MST Received: From Usc-Ecl.ARPA by BRL-VGR via smtp; 3 Feb 84 15:50 EST Date: 3 Feb 1984 1240-PST From: Ted Shapin Subject: The problem with LISTST To: wancho@SIMTEL20.ARPA cc: info-cpm@BRL-VGR.ARPA Postal-address: Beckman Instruments, Inc. Postal-address: 2500 Harbor X-11, Fullerton, CA 92634 Phone: (714)961-3393 Digital Research made an error in their manual in describing what LISTST should do. "The value 00 is returned in A if the list device in not ready to accept a character and 0FFH if a character can be sent to the printer. A 00 [!] value should be returned if LISTST is not implemented." An application program cannot know whether the BIOS implemented LISTST or not. If the application program uses this BIOS entry point and assumes it is implemented according to DRI's instructions, it will loop forever waiting for a 0FFH if tha BIOS doesn't implement LISTST and returns a 00. I do my checking for printer ready in the LIST code which outputs a character. It sounds like Lifeboaat may have done a similar thing and perhaps there is a bug in the LIST routine. Ted. ------- 3-Feb-84 19:21:07-MST,471;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 3 Feb 84 19:21:04-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 3 Feb 84 20:53 EST Received: From Mit-Mc.ARPA by BRL via smtp; 3 Feb 84 20:40 EST Date: 3 February 1984 20:42 EST From: Herb Lin Subject: getting KERMIT - where is it? To: info-cpm@brl I remember it is at columbia somewhere, but what are the pathnames etc... tnx. 6-Feb-84 08:34:06-MST,712;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 08:34:00-MST Received: From Brl-Bmd.ARPA by BRL-VGR via smtp; 5 Feb 84 9:07 EST Date: Sun, 5 Feb 84 8:55:43 EST From: Charlie Strom (NYU) To: INFO-CPM@brl-vgr Subject: Standard needed I have been asked to poll the user community on siuggestions as ti a naming convention for CP/M-86 object code files. Calling them .CMD (on an RCPM) will cause confusion with DBASE command files; needless to say if the RCPM is running CP/M-86, it would be disastrous to have all these .CMD files sitting there as well. One suggestion is .O86. I would appreciate your input. 6-Feb-84 08:35:10-MST,980;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 08:34:46-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 5 Feb 84 9:56 EST Date: Sun, 5 Feb 84 9:44:11 EST From: Keith Petersen To: Info-Cpm@brl-vgr Subject: Changes to Royal Oak RCPM The Royal Oak (Michigan) RCPM no longer requires "callback". It now answers on your first call and accepts 110, 300, 450, 600 and 710 baud (using 103 tones). The floppy drives are no longer in service. The 10 megabyte hard disk has been replaced with a 26 megabyte hard disk partitioned into four logical drives. Info-Cpm readers who do not have access to SIMTEL20 will find many of the same files are available on the Royal Oak RCPM. Sometime in the near future a 300/1200 baud modem may be added. I will announce it on Info-Cpm if/when it happens. The phone number for the Royal Oak RCPM is (313) 759-6569. --Keith 6-Feb-84 08:35:14-MST,605;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 08:35:03-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 5 Feb 84 13:29 EST Received: From Amsaa.ARPA by BRL via smtp; 5 Feb 84 13:20 EST Date: Sun, 5 Feb 84 13:15:57 EST From: David Towson (CSD) To: Herb Lin cc: info-cpm@brl Subject: Re: getting KERMIT - where is it? Herb - Kermit is on Columbia-20 in directory PS:. Using FTP, do "dir ps:" to see what's there. Dave towson@amsaa 6-Feb-84 08:38:28-MST,1374;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 08:38:16-MST Received: From Usc-Eclb.ARPA by BRL-VGR via smtp; 6 Feb 84 0:57 EST Date: 5 February 1984 21:55-PST (Sunday) Sender: TLI@usc-eclb From: Tony Li To: Info-Micro@brl-vgr, Info-CPM@brl-vgr Subject: CP/M 80 programs on a 68K... Reply-to: Tli@usc-eclb Home: 1275 W. 29th #211, Los Angeles, Ca. 90007 (213) 737-8168 For all of you who are just dying to run your 68K as a souped up 8080... EM80 - an 8080 & CP/M-80 emulator for CP/M-68K Empirical Research Group, Inc. P.O. Box 1176 Milton WA 98354 From the spec sheet... "This emulator requires a minimum of 128K of memory be available. This does, however, also include the space occupied by CP/M-68K itself.... All normal BDOS calls are supported by the software emulation. All direct BIOS calls, except for the disk related ones, are also correctly handled by EM80... At present, only 8080 opcodes are supported by the emulator. A future release will support all Z80 opcodes..." Example of usage: A> EM80 PIP A:=B:TEST.DAT[V] Cheers, Tony ;-) P.S. Before you go running this on you Mac, though, you first have to get CP/M-68K up and running. If anyone has or is working on a BIOS for the Mac, how about dropping the list a line? 6-Feb-84 08:40:13-MST,811;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 08:39:34-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 4 Feb 84 5:53 EST Received: From Sri-Unix.ARPA by BRL via smtp; 4 Feb 84 5:47 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 4 Feb 84 2:39-PST Date: 25 Jan 84 9:19:30-PST (Wed) To: info-cpm@brl From: harpo!seismo!rlgvax!plunkett@ucb-vax Subject: Gordon "CBASIC" Eubanks Article-I.D.: rlgvax.1615 Gordon Eubanks, Jr., a true pioneer in the microcomputer field with his E-BASIC, CBASIC, and later CB-80, etc., is listed in the SOFTCON notice as no longer at Digital Research, Inc. Now a so-called "Independent Consultant". Does anyone know anything more about this? ..{allegra|seismo}!rlgvax!plunkett 6-Feb-84 08:42:10-MST,549;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 08:42:03-MST Received: From Rand-Relay.ARPA by BRL-VGR via smtp; 4 Feb 84 18:42 EST Date: 4 Feb 1984 09:36:40-EST From: goldfarb.ucf-cs@rand-relay Return-Path: Subject: squeeze/unsqueeze for Unix To: info-cpm@brl-vgr, purdue!pur-ee!uiucdcs!ccvaxa!mikel.ucf-cs@rand-relay Via: UCF-CS; 4 Feb 84 15:30-PST I am sending them to you via Unix mail. Ben Goldfarb {duke,decvax}!ucf-cs!goldfarb 6-Feb-84 08:43:14-MST,841;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 08:43:03-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 5 Feb 84 1:14 EST Received: From Usc-Isid.ARPA by BRL via smtp; 5 Feb 84 1:03 EST Date: 4 Feb 1984 09:53-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: getting KERMIT - where is it? From: ABN.ISCAMS@usc-isid To: LIN@mit-mc Cc: info-cpm@brl Message-ID: <[USC-ISID] 4-Feb-84 09:53:11.ABN.ISCAMS> In-Reply-To: The message of 3 February 1984 20:42 EST from Herb Lin Herb, KERMIT is at (via FTP) COLUMBIA20 (can't remember if the 20 should be -20; try both) DIR will get you the listing GET -README.TXT (I think that's the title) will get you the latest update on goings on. Regards, David Kirschbaum Toad Hall 6-Feb-84 11:10:11-MST,937;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 11:09:59-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 6 Feb 84 12:28 EST Received: From Mit-Multics.ARPA by BRL via smtp; 6 Feb 84 12:09 EST Date: Mon, 6 Feb 84 12:04 EST From: Woodie@MIT-MULTICS.ARPA Subject: SID/ZSID To: info-cpm@BRL.ARPA Message-ID: <840206170454.575774@MIT-MULTICS.ARPA> When I try to use the "assemble" mode of SID to assemble code directly into memory, I find that any references to memory addresses in BIOS are rejected. I can assemble code which references the "Transient Program Area" (e.g., STA 105h) but not that same code if it references BIOS (maybe BDOS as well), e.g., STA EF00 (Which is in my Osborne 1's BIOS). Can anyone tell me if this "feature" was put there on purpose, or how to get around it? Paul Woodie (Woodie.DODCSC at MIT-MULTICS) 6-Feb-84 11:10:44-MST,1004;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 6 Feb 84 11:10:32-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 6 Feb 84 12:47 EST Received: From Mit-Multics.ARPA by BRL via smtp; 6 Feb 84 12:34 EST Posted-Date: 6 Feb 84 12:23 EST Date: Mon, 6 Feb 84 12:22 EST From: Woodie@MIT-MULTICS.ARPA Subject: ddd.asm To: info-cpm@BRL.ARPA Message-ID: <840206172242.019832@MIT-MULTICS.ARPA> Has any one used the ddd.asm program ( which is in the simtel20 collection) on the Osborne 1? (That is, or is supposed to be, the program that should allow disk head alignment with out the use of a dual-trace oscilloscope). I know that the 8080 assembly language program was meant to be customized to the particular host machine, and I have done some of that for my Osborne 1, but I would like to communicate with anyone who has completed that process and used to program. Paul Woodie (Woodie.DODCSC at mit-multics) 7-Feb-84 08:20:17-MST,925;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 08:20:10-MST Received: From Rand-Relay.ARPA by BRL-VGR via smtp; 7 Feb 84 0:57 EST Date: 6 Feb 1984 09:33:40-EST From: goldfarb.ucf-cs@rand-relay Return-Path: Subject: Re: Changes to Royal Oak RCPM To: w8sdz@brl Cc: info-cpm@brl-vgr Via: UCF-CS; 6 Feb 84 19:46-PST congratulations, Keith! Sounds like you're moving ahead nicely. One question. Sigi Kluger seems to be leading the pack toward charging set fees for "membership" in RCP/M's around the country. One system here has decided to go that way, stating that "the best systems" around the country are doing it. I really have no objection to his doing whatever he wants with his system, but I am interested in what the "Father of RCP/M" has to say on the subject in general. Can you comment? Ben 7-Feb-84 08:20:27-MST,665;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 08:20:20-MST Received: From Csnet-Cic.ARPA by BRL-VGR via smtp; 7 Feb 84 1:38 EST Date: 6 Feb 1984 10:39:17-EST From: erh%virginia@csnet-relay Return-Path: Subject: Standard needed To: INFO-CPM@brl-vgr, mmdf%virginia@csnet-relay Via: Virginia; 7 Feb 84 0:17-EST About the naming of RCPM CP/M86 files: how about ".B86" (for Binary or oBject), or "86J" (this would allow looking at all object files using "DIR *.??J"). I am against ".O86", since it is easy to confuse with ".086". ~v~ Ed Howorka, erh@uvacs ~ 7-Feb-84 08:22:31-MST,2667;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 08:22:14-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Feb 84 4:10 EST Received: From Sri-Unix.ARPA by BRL via smtp; 7 Feb 84 4:04 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 7 Feb 84 0:56-PST Date: 1 Feb 84 13:25:38-PST (Wed) To: info-cpm@brl From: ihnp4!alberta!ubc-vision!uw-beaver!ssc-vax!fluke!ipspec@ucb-vax Subject: List of Kaypro ports and baud codes Article-I.D.: vax1.489 This is the complete list (I think) of port addresses for the Kaypro 2, and older 4's. The newer 4's will use some of the unused ports for the new added standard features such as the real time clock and modem (hope you have heard about that). The 10 I think falls same way, basically same as below but some of extras like the light use some of the 'unused' ports. Ports are selected in groups of 4 by U57, then individually by A0 and A1 of the address bus. (Baud rates ports dont't bother with the individule select.) 0 RS-232 serial baud rate, W (write only) BAUD RATE CODES 1-3 Unused (actually will perform same as port 0) 0 50 4 RS-232 serial data, R/W (read/write) 1 75 5 Keyboard serial data, R/W 2 110 6 RS-232 status, R/W 3 134.5 7 Keyboard status, R/W 4 150 8 Parallel printer data, R/W 5 300 9 Unused PIO (port B of U54), R/W 6 600 A Parallel printer status, R/W 7 1200 B Status for unused port 9, R/W 8 1800 C Keyboard baud rate, W. (but don't change it) 9 2000 D-F Unused (actually will perform same as port C) A 2400 10-13 Disk I/O functions, R/W B 3600 14-17 Unconnected. Pin 10 of U57 decodes this block of 4 C 4800 18-1B Unconnected. Pin 9 of U57 decodes this block of 4 D 7200 1C System port, R/W. (disk select, motor control, E 9600 & printer handshakes) F 19,200 1D Unused PIO (port B of U72), R/W 1E Status of port 1C, R/W 1F Status of unused port 1D, R/W This is actually my first pass this and hasn't all been verified. If someone would add in the info the new 4's and 10's and repost it, I'm sure that all interested would thankful. Regards, Al Weiss 7-Feb-84 08:24:07-MST,485;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 08:23:56-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Feb 84 6:17 EST Received: From Mit-Mc.ARPA by BRL via smtp; 7 Feb 84 6:12 EST Date: 7 February 1984 06:14 EST From: Jerry E. Pournelle Subject: BYTE arrived... To: INFO-CPM@mit-mc Saturday 4 February in Hollywood (second class; I've had the Fed Expressed copy for some time.) 7-Feb-84 08:35:33-MST,683;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 08:35:29-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Feb 84 8:20 EST Received: From Mit-Mc.ARPA by BRL via smtp; 7 Feb 84 7:52 EST Date: 7 Feb 1984 0450-PST From: Crede Edens Subject: MODEMS WANTED To: INFO-CPM@mit-mc cc: EDENS@BRL.ARPA Some time last year I saw a message that someone posted concerning some U.S. Robotics modems for sale for a very reasonable price. Are there some of these still available? Or does someone know of another brand for sale reasonable? Reply to EDENS@OFFICE-3 THANKS ------- 7-Feb-84 08:48:58-MST,1037;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 08:48:52-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Feb 84 9:59 EST Received: From Sri-Unix.ARPA by BRL via smtp; 7 Feb 84 9:51 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 7 Feb 84 6:38-PST Date: 6 Feb 84 16:09:43-PST (Mon) To: info-cpm@brl From: hplabs!zehntel!dual!fortune!burton@ucb-vax Subject: Re: Siemens Floppy Drives - Parts & Serv - (nf) Article-I.D.: fortune.2452 #R:linus:-64200:fortune:25500005:000:414 fortune!burton Feb 6 12:12:00 1984 Since this is a public net, and the libel laws apply, I won't say more about Siemens, and believe me, I don't believe in paying retail [I was born and raised in NYC], but it's not worth it for Siemens. Philip Burton 101 Twin Dolphin Drive Fortune Systems Redwood City, CA 94065 (415) 595-8444 x 526 - - - {allegra,[decvax!decwrl,ucbvax]!amd70,cbosgd,harpo,hpda,ihnp4,sri-unix} !fortune!burton 7-Feb-84 11:31:39-MST,11370;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 11:31:14-MST Date: Tue, 7 Feb 84 12:36:02 EST From: Dave Towson (info-cpm) To: info-cpm@brl-vgr Subject: [phil%euler: Sorry...] [phil%euler: MODEM7 for the C64] ----- Forwarded message # 1: Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 6 Feb 84 18:37 EST Received: From Ucb-Vax.ARPA by BRL via smtp; 6 Feb 84 18:29 EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA02030; Mon, 6 Feb 84 15:22:34 pst Received: from ucbruby.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.13/4.13) id AA11835; Mon, 6 Feb 84 15:29:37 pst Received: by ucbruby.CC.Berkeley.ARPA (4.13/4.13) id AA10364; Mon, 6 Feb 84 14:51:29 pst Date: Mon, 6 Feb 84 14:51:29 pst From: phil%euler@BRL.ARPA Message-Id: <8402062251.AA10364@ucbruby.CC.Berkeley.ARPA> To: ruby.info-cpm-request@brl Subject: Sorry... It seems I may have sent a rather lengthy file to info-cpm-request instead of to info-cpm as was intended; if you could send it out to info-cpm I would appreciate it. If I didn't screw up, then disregard this notice. Phil (jlapsley%D.CC@Berkeley, NOT %ucbeuler) ----- Forwarded message # 2: Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 6 Feb 84 18:38 EST Received: From Ucb-Vax.ARPA by BRL via smtp; 6 Feb 84 18:30 EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.21) id AA02059; Mon, 6 Feb 84 15:23:32 pst Received: from ucbruby.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.13/4.13) id AA11846; Mon, 6 Feb 84 15:30:39 pst Received: by ucbruby.CC.Berkeley.ARPA (4.13/4.13) id AA10208; Mon, 6 Feb 84 14:37:58 pst Date: Mon, 6 Feb 84 14:37:58 pst From: phil%euler@BRL.ARPA Message-Id: <8402062237.AA10208@ucbruby.CC.Berkeley.ARPA> To: ruby.info-cpm-request@brl Subject: MODEM7 for the C64 I recall someone recently asking about the availability of modem7 or xmodem programs for the C64 under CP/M. As it happened, fairly randomly, someone just sent me this -- I have not used it and I know nothing about it (I don't even have a C64), but I thought I might send it to the net. Phil (contrary to the "From" field, I am still at "jlapsley%D.CC@Berkeley") ------------ Date: Mon, 6 Feb 84 12:44:55 pst From: jmrubin@ucbcoral (Joel Rubin) To: jlapsley@D Subject: xmodem for C'64 I don't know if you're still looking for an xmodem protocol program for the C'64, but here is one. I haven't tried it yet. (Documentation+Hexfile) MODEM64: DOCUMENTATION BY CHRIS LAMPTON, 75275,1373 01/29/84 MODEM64 IS A SIMPLE TERMINAL EMULATOR WITH XMODEM DOWNLOAD FACILI- TIES, DESIGNED TO RUN UNDER COMMODORE 64 CP/M. IT WILL NOT RUN UNDER OTHER VERSIONS OF CP/M; IN FACT, IT WILL ONLY RUN UNDER THE CP/M PACKAGE OFFERED BY COMMODORE BUSINESS MACHINES. WHEN FIRST RUN, MODEM64 IS IN NORMAL TERMINAL MODE. ASCII DATA RE- CEIVED THROUGH THE RS-232 PORT IS DIS- PLAYED ON THE SCREEN. DATA TYPED ON THE KEYBOARD IS TRANSMITTED. PARITY IS IGNORED. MOST STANDARD ASCII CONTROL CODES ARE IMPLEMENTED. TO EXIT MODEM64 PRESS FUNCTION KEY F2 (SHIFT-F1). XMODEM DOWNLOADS ARE INITIATED BY PRESSING FUNCTION KEY F8 (SHIFT-F7). USING MODEM64 WITH AN RCP/M (REMOTE CP/M DATABASE) THE STANDARD RCP/M COMMAND FOR XMODEM TRANSMISSION IS: XMODEM S FILENAME.EXT IF THE SPECIFIED FILE IS AVAILABLE, THE RCP/M WILL RESPOND WITH THE NUMBER OF 128 BYTE BLOCKS IN THE FILE AND THE APPROXIMATE DOWNLOAD TIME. IF YOU SHOULD DECIDE AT THIS POINT THAT YOU WISH TO ABORT THE DOWNLOAD, PRESS CTRL-'X' TO SEND AN ASCII CANCEL SIGNAL TO THE SENDING COMPUTER. TO BEGIN THE DOWNLOAD, PRESS F8, AND MODEM64 WILL AUTOMATICALLY REQUEST THE RCP/M TO START TRANS- MITTING. THE MESSAGE 'XMODEM TRANSMIS- SION INITIATED' WILL APPEAR ON THE SCREEN. IF FOR ANY REASON THE TRANS- MISSION IS NOT RECEIVED, MODEM64 WILL CONTINUE BROADCASTING THE REQUEST FOR APPROXIMATELY 100 SECONDS BEFORE ABORTING THE DOWNLOAD AND RETURNING TO TERMINAL MODE. SHOULD THIS OCCUR, THE MESSAGE 'BLOCK NOT RECEIVED, XMODEM TRANSMISSION ABORTED' WILL BE DIS- PLAYED. THE DOWNLOAD MAY BE MANUALLY ABORTED BY PRESSING THE RUN-STOP KEY. ONCE TRANSMISSION HAS BEGUN, THE DOWNLOADED BLOCKS WILL BE AUTOMATICALLY SAVED TO THE DISK IN CP/M FORMAT. AS EACH BLOCK IS RECEIVED, THE MESSAGE 'BLOCK #NN RECEIVED' WILL BE DISPLAYED, WHERE NN IS THE BLOCK NUMBER IN HEXA- DECIMAL. IF MORE THAN 255 (FF HEX) BLOCKS ARE TRANSMITTED, THE BLOCK NUMBER WILL ROLL OVER TO 00. CHECKSUMS ARE USED TO VERIFY THE ACCURACY OF THE TRANSMITTED DATA. AT THE END OF TRANS- MISSION, MODEM64 WILL INFORM THE SENDING COMPUTER OF THE SUCCESSFUL RECEIPT OF THE FILE AND WILL DISPLAY THE MESSAGE 'XMODEM TRANSMISSION COM- PLETED' BEFORE RETURNING TO TERMINAL MODE. FILES WILL BE SAVED TO THE DISK UNDER THE FILENAME 'NEWFILE,' WITH THE EXTENSION '.XMD'. FILES DOWNLOADED DURING A SINGLE SESSION WILL BE SEQUEN- TIALLY NUMBERED, WITH THE FIRST FILE GIVEN THE NAME 'NEWFILE1.XMD,' THE SECOND FILE THE NAME 'NEWFILE2.XMD,' AND SO FORTH. LETTERS OF THE ALPHABET WILL BE USED ONCE THE TEN NUMERALS ARE EXHAUSTED. GIVEN THE OBVIOUS LIMITATION ON FILE NAMES, IT IS RECOMMENDED THAT YOU NOT DOWNLOAD MORE THAN 35 FILES IN ONE SESSION, OR YOU MAY FIND UNTYPABLE ASCII CHARACTERS IN THE NAMES. IT IS ALSO RECOMMENDED THAT YOU RENAME ALL DOWNLOADED FILES IMMEDIATELY AFTER THE SESSION, USING THE CP/M REN COMMAND, BECAUSE EXISTING NEWFILES ON THE DISK WILL BE DELETED BY MODEM64 DURING LATER SESSIONS TO MAKE ROOM FOR FRESHLY DOWNLOADED FILES WITH THE SAME SEQUENCE NUMBERS. IN THE EVENT THAT YOU ATTEMPT TO DOWNLOAD TO A FULL DISK (OR A FULL DISK DIRECTORY), AN ERROR MESSAGE WILL BE PRINTED AND THE DOWNLOAD ABORTED. ANY DATA DOWNLOADED TO THE CURRENT FILE BEFORE THE DISK LIMIT WAS REACHED WILL BE PRESERVED. THIS IMPLEMENTATION OF XMODEM IS NOT BULLET PROOF. IT IS POSSIBLE FOR THE SENDING COMPUTER AND THE RECEIVING COMPUTER TO FALL OUT OF SYNC AND NOT RECOVER, THOUGH THIS IS NOT A VERY LIKELY EVENT. SHOULD IT OCCUR, THE DOWNLOAD WILL MORE THAN LIKELY ABORT BY ITSELF. HOWEVER, SHOULD YOU NOTICE AN UNUSUALLY LONG PAUSE BETWEEN BLOCKS -- SAY 20 SECONDS OR MORE -- YOU SHOULD ABORT MANUALLY WITH THE RUN-STOP KEY. THE SENDING COMPUTER MAY CONTINUE BROADCASTING DATA, BUT WILL NOTICE WITHIN A FEW SECONDS THAT NO ACKNOW- LEDGING SIGNAL IS BEING RECEIVED AND WILL CANCEL THE DOWNLOAD. YOU MAY THEN INITIATE THE DOWNLOAD AGAIN. THIS HAS HAPPENED TO ME ONCE IN ROUGHLY 40 DOWNLOADS. SECURITY WILL BE TIGHTENED IN SUBSEQUENT VERSIONS. SUGGESTIONS FOR FUTURE IMPROVEMENTS AND REPORTS OF CURRENT BUGS SHOULD BE CONVEYED TO THE AUTHOR VIA COMPU- SERVE INFORMATION SERVICE EMAIL OR THE CIS COMMODORE-64 SIG. :10010000010B0021D601115D00EDB03E093200F96E :100110002103122206F93E013200CE003A00F95FB7 :100120001600213901195E2356EBCD38013E093204 :1001300000F9210012C31301E9410180018E0197EA :10014000013A64003CFE3AC24C013E413264003E3A :1001500000327C00326800326900326A000E0F11F2 :100160005C00CD0500FEFFCA72010E13115C00CDCC :1001700005000E16115C00CD0500FEFFCA9B01C9EB :100180000E15115C00CD0500FEFFCAA601C90E10B8 :10019000115C00CD0500C9E1C3000011B4010E09D6 :1001A000CD0500C3AE0111CA010E09CD05003E0107 :1001B000320EF0C94449534B204449524543544FF1 :1001C00052592046554C4C0D0A244449534B204665 :1001D000554C4C0D0A244E455746494C4530584D18 :1001E00044000000000000000000000000000000CB :1001F00000000000000000000000000000000000FF :100200004CBC1358AD8602851320F512A99320AB80 :1002100012A200A0031820F0FFA27FA0142029142E :10022000A201A00C1820F0FFA2A2A014202914A261 :1002300002A0051820F0FFA2B3A014202914A205E3 :10024000A0001820F0FF20F51220CD1220E312A903 :100250000E20AB12207612208F12C98090F62064F7 :10026000124C5412297F0AA8B9D9168504C8B9D9E5 :100270001685056C0400A20520C6FF20E4FFC90016 :10028000F00C297FA8B9591620AB124C7B1260A242 :100290000620C6FFA00084CC20E4FFC900F00BA814 :1002A000B95915C980B00320BE1260A2074820C901 :1002B000FF2072146820D2FFA5138D860260A2056C :1002C0004820C9FF68A8B9591520D2FF60A905A226 :1002D00002A00320BAFFA904A255A01520BDFF204B :1002E000C0FF60A906A200A0FF20BAFFA90020BDA0 :1002F000FF20C0FF60A907A203A0FF20BAFFA9004A :1003000020BDFF20C0FF60A2D3A01420291420A389 :1003100013A915850AA20520C6FFA9808504A91086 :100320008505A901850BA90A8506A50A20BE12A983 :10033000FF85078508A903851220E4FF850DA59197 :100340002980D0034CDA13A50DC900F00BC901F0C8 :100350001AC904D0034CEA13C607D0DDC608D0D9A9 :10036000C612D0D5C606D0C24CD313A906850A2022 :100370004514205F148509204514205F14A9808549 :100380000CA000204514205F149104C8C60CD0F3C3 :10039000204514C50BF0034C111320AD1320FA13A4 :1003A0004C1513A9004CAF13A9044CAF13A9028D2F :1003B0000009A900850E20E7FF4C000A686820CDDF :1003C0001220F51220E312A50EC900F00568684C52 :1003D000DA1360A2F3A014202914A207A015202983 :1003E00014A91820BE1220A81360A90620BE12A2CC :1003F00024A01520291420A81360A242A0152029AA :1004000014A5094A4A4A4A186930C93A900318693A :100410000720AB12A509290F186930C93A900318B3 :10042000690720AB12A24AA01586108411A20720EA :10043000C9FF207214A000B110C900F00720D2FF3C :10044000C84C37146020E4FF850D20B7FF2908D081 :10045000F4A5912980D00568684CDA13A50D6018C1 :10046000650B850BA50D602072146868A9068D00C8 :100470000960A00184CCA4D3B1D1297F91D1602A95 :100480002A2A20584D4F44454D20363420425920C9 :100490004348524953204C414D50544F4E202A2A34 :1004A0002A004A414E554152592032392C203139C7 :1004B0003834004E4F5420464F5220434F4D4D4547 :1004C000524349414C20444953545249425554499E :1004D0004F4E000D584D4F44454D205452414E5300 :1004E0004D495353494F4E20494E49544941544573 :1004F000440D00424C4F434B204E4F542052454335 :1005000045495645440D00584D4F44454D205452E1 :10051000414E534D495353494F4E2041424F52543F :1005200045440D00584D4F44454D205452414E53C3 :100530004D495353494F4E20434F4D504C45544520 :100540000D00424C4F434B20230020524543454968 :100550005645440D00060000000001020304050694 :100560000708090A0B0C0D0E0F100A1213081516B6 :100570001718191A1B1C0C1E1F20212223242526A4 :100580002728292A2B2C2D2E2F3031323334353683 :100590003738393A3B3C3D3E3F40616263646566B3 :1005A0006768696A6B6C6D6E6F7071727374757663 :1005B0007778797A5B5C5D5E5F6041424344454693 :1005C0004748494A4B4C4D4E4F5051525354555643 :1005D0005758595A7B7C7D7E7F0000000000000048 :1005E000000081000080000000000000000000000A :1005F00000000000000000000000000000000000FB :1006000000000000000000000000000000000000EA :1006100000000000000000000000000000000000DA :1006200000000000000000000000000000000000CA :1006300000000000000000000000000000000000BA :1006400000000000000000000000000000000000AA :100650000000000000000000000001020304050685 :100660000714090A0B930D0E0F100A121308151622 :100670001718191A1B1C0C1E1F20212223242526A3 :100680002728292A2B2C2D2E2F3031323334353682 :100690003738393A3B3C3D3E3F40616263646566B2 :1006A0006768696A6B6C6D6E6F7071727374757662 :1006B0007778797A5B5C5D5E5F6041424344454692 :1006C0004748494A4B4C4D4E4F5051525354555642 :1006D0005758595A7B7C7D7E7F07136714FD02FFB4 :1006E00002FD02FD02FF02FD02FD02FD02FD82F994 :1006F00002FF02FD02FD02F902FF02F90B8B82FFED :0000000000 ----- End of forwarded messages 7-Feb-84 12:13:02-MST,515;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 7 Feb 84 12:12:59-MST Received: From Nosc-Cc.ARPA by BRL-VGR via smtp; 7 Feb 84 12:53 EST Received: by Nosc.ARPA (4.12/4.7) id AA03585; Tue, 7 Feb 84 09:53:22 pst Date: Tue, 7 Feb 84 09:53:22 pst From: James F. Jperry Message-Id: <8402071753.AA03585@Nosc.ARPA> To: info-cpm%brl=vgr@nosc Cc: jperry@nosc Subject: release ------- please remove my name kfrom the info cpm list ------- 9-Feb-84 18:16:33-MST,796;000000000000 Return-Path: Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 9 Feb 84 18:16:27-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Feb 84 14:55 EST Received: From Mit-Mc.ARPA by BRL via smtp; 7 Feb 84 14:34 EST Date: 7 Feb 84 09:49:57 PST (Tuesday) From: Veizades.PA@PARC-MAXC.ARPA Subject: CRC error checking in XModem To: INFO-MODEM7@mit-mc.ARPA, INFO-CPM@mit-mc.ARPA cc: Veizades.PA@PARC-MAXC.ARPA I am implementing the XModem protocol on a non CP/M system and I am interested in the exact method by which the CRC value is generated, what portion of the XModem packet is used to compute the CRC and the differences in the protocol when the CRC option is used. Can anyone out there help? John Veizades - Veizades@PARC-MAXC 9-Feb-84 18:16:39-MST,1249;000000000000 Return-Path: Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 9 Feb 84 18:16:34-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Feb 84 16:50 EST Received: From Mit-Multics.ARPA by BRL via smtp; 7 Feb 84 16:34 EST Received: from CISL-SERVICE-MULTICS.ARPA by MIT-MULTICS.ARPA TCP; 07-Feb-1984 16:16:01-est Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 07-Feb-1984 16:13:01-est Date: Tue, 7 Feb 84 14:09 MST From: Brzozowski%his-phoenix-multics.arpa@BRL.ARPA Subject: Turbo Pascal To: info-cpm@BRL.ARPA Message-ID: <840207210928.530621@HIS-PHOENIX-MULTICS.ARPA> Does anyone out there in netland have a copy of the "Turbo Pascal" by Borland International as advertized in BYTE? For the price, it seems like a good deal to learn Pascal ($49.95), but if it's not standard it 'aint much of a lesson (Except how NOT to buy a compiler). Is Boralnd International a reputable company to deal with? Forgive me if I seem skeptical, but I am wary about great claims and small prices... Any information would be helpful (Diskette formats for CPM-80, 8087 support, etc.). Thanks in advance! Gary Brz... 9-Feb-84 18:17:00-MST,730;000000000000 Return-Path: Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 9 Feb 84 18:16:56-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Feb 84 18:50 EST Received: From Cmu-Cs-A.ARPA by BRL via smtp; 7 Feb 84 18:39 EST Date: 7 Feb 84 1739 EST (Tuesday) From: George.Wood@cmu-cs-a To: info-cpm@brl, info-micro@brl Subject: forth for trs-80/100 wanted Message-Id: <07Feb84.173934.GW90@CMU-CS-A> A visitor from Holland would like to get forth for his trs-80 model 100. He's heard there's one available, but is having trouble finding a source/vendor, and will only be in the U.S. for a week. I'd appreciate assistance in helping him find it. George.Wood@CMU-CS-A.ARPA 9-Feb-84 18:19:14-MST,655;000000000000 Return-Path: Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 9 Feb 84 18:19:08-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Feb 84 20:07 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 7 Feb 84 20:00 EST Date: Tue, 7 Feb 84 17:00 PST From: SSalzman.ES@PARC-MAXC.ARPA Subject: Re: Turbo Pascal In-reply-to: <840207210928.530621@HIS-PHOENIX-MULTICS.ARPA> To: Brzozowski%his-phoenix-multics.arpa@BRL.ARPA cc: info-cpm@BRL.ARPA Read Microsystems magazine, Feb issue. They have a review of Turbo Pascal. According to them it's quite a nice system. I'd look into it. Isaac Salzman. 9-Feb-84 18:30:29-MST,8475;000000000000 Return-Path: Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 9 Feb 84 18:30:10-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Feb 84 20:20 EST Date: Tue, 7 Feb 84 20:05:04 EST From: Keith Petersen To: Info-Cpm@brl-vgr, Info-Micro@brl-vgr Subject: Definition of CP/M MODEM protocol I guess it's time to re-send this file to the mailing list. I've recently received numerous requests for the exact definition of the Ward Christensen MODEM protocol. The original uses CHECKSUM error checking. MODEM7 introduced CRC error checking but as far as I know, no one has ever issued a DOC file explaing how that works. The source code is well commented and should serve as a guide. ---from the author of MODEM, Ward Christensen--- MODEM PROTOCOL OVERVIEW 178 lines, 7.5K 1/1/82 by Ward Christensen. I will maintain a master copy of this. Please pass on changes or suggestions via CBBS/Chicago at (312) 545-8086, or by voice at (312) 849-6279. NOTE this does not include things which I am not familiar with, such as the CRC option implemented by John Mahr. Last Rev: (none) At the request of Rick Mallinak on behalf of the guys at Standard Oil with IBM P.C.s, as well as several previous requests, I finally decided to put my modem protocol into writing. It had been previously formally published only in the AMRAD newsletter. Table of Contents 1. DEFINITIONS 2. TRANSMISSION MEDIUM LEVEL PROTOCOL 3. MESSAGE BLOCK LEVEL PROTOCOL 4. FILE LEVEL PROTOCOL 5. DATA FLOW EXAMPLE INCLUDING ERROR RECOVERY 6. PROGRAMMING TIPS. -------- 1. DEFINITIONS. 01H 04H 06H 15H 18H -------- 2. TRANSMISSION MEDIUM LEVEL PROTOCOL Asynchronous, 8 data bits, no parity, one stop bit. The protocol imposes no restrictions on the contents of the data being transmitted. No control characters are looked for in the 128-byte data messages. Absolutely any kind of data may be sent - binary, ASCII, etc. The protocol has not formally been adopted to a 7-bit environment for the transmission of ASCII-only (or unpacked-hex) data , although it could be simply by having both ends agree to AND the protocol-dependent data with 7F hex before validating it. I specifically am referring to the checksum, and the block numbers and their ones- complement. Those wishing to maintain compatibility of the CP/M file structure, i.e. to allow modemming ASCII files to or from CP/M systems should follow this data format: * ASCII tabs used (09H); tabs set every 8. * Lines terminated by CR/LF (0DH 0AH) * End-of-file indicated by ^Z, 1AH. (one or more) * Data is variable length, i.e. should be considered a continuous stream of data bytes, broken into 128-byte chunks purely for the purpose of transmission. * A CP/M "peculiarity": If the data ends exactly on a 128-byte boundary, i.e. CR in 127, and LF in 128, a subsequent sector containing the ^Z EOF character(s) is optional, but is preferred. Some utilities or user programs still do not handle EOF without ^Zs. * The last block sent is no different from others, i.e. there is no "short block". -------- 3. MESSAGE BLOCK LEVEL PROTOCOL Each block of the transfer looks like: <255-blk #><--128 data bytes--> in which: = 01 hex = binary number, starts at 01 increments by 1, and wraps 0FFH to 00H (not to 01) <255-blk #> = blk # after going thru 8080 "CMA" instr, i.e. each bit complemented in the 8-bit block number. Formally, this is the "ones complement". = the sum of the data bytes only. Toss any carry. -------- 4. FILE LEVEL PROTOCOL ---- 4A. COMMON TO BOTH SENDER AND RECEIVER: All errors are retried 10 times. For versions running with an operator (i.e. NOT with XMODEM), a message is typed after 10 errors asking the operator whether to "retry or quit". Some versions of the protocol use , ASCII ^X, to cancel transmission. This was never adopted as a standard, as having a single "abort" character makes the transmission susceptible to false termination due to an or being corrupted into a and canceling transmission. The protocol may be considered "receiver driven", that is, the sender need not automatically re-transmit, although it does in the current implementations. ---- 4B. RECEIVE PROGRAM CONSIDERATIONS: The receiver has a 10-second timeout. It sends a every time it times out. The receiver's first timeout, which sends a , signals the transmitter to start. Optionally, the receiver could send a immediately, in case the sender was ready. This would save the initial 10 second timeout. However, the receiver MUST continue to timeout every 10 seconds in case the sender wasn't ready. Once into a receiving a block, the receiver goes into a one-second timeout for each character and the checksum. If the receiver wishes to a block for any reason (invalid header, timeout receiving data), it must wait for the line to clear. See "programming tips" for ideas Synchronizing: If a valid block number is received, it will be: 1) the expected one, in which case everything is fine; or 2) a repeat of the previously received block. This should be considered OK, and only indicates that the receivers got glitched, and the sender re-transmitted; 3) any other block number indicates a fatal loss of synchronization, such as the rare case of the sender getting a line-glitch that looked like an . Abort the transmission, sending a ---- 4C. SENDING PROGRAM CONSIDERATIONS. While waiting for transmission to begin, the sender has only a single very long timeout, say one minute. In the current protocol, the sender has a 10 second timeout before retrying. I suggest NOT doing this, and letting the protocol be completely receiver-driven. This will be compatible with existing programs. When the sender has no more data, it sends an , and awaits an , resending the if it doesn't get one. Again, the protocol could be receiver-driven, with the sender only having the high-level 1-minute timeout to abort. -------- 5. DATA FLOW EXAMPLE INCLUDING ERROR RECOVERY Here is a sample of the data flow, sending a 3-block message. It includes the two most common line hits - a garbaged block, and an reply getting garbaged. represents the checksum byte. SENDER RECEIVER times out after 10 seconds, <--- 01 FE -data- ---> <--- 02 FD -data- xx ---> (data gets line hit) <--- 02 FD -data- xx ---> <--- 03 FC -data- xx ---> (ack gets garbaged) <--- 03 FC -data- xx ---> ---> <--- -------- 6. PROGRAMMING TIPS. * The character-receive subroutine should be called with a parameter specifying the number of seconds to wait. The receiver should first call it with a time of 10, then and try again, 10 times. After receiving the , the receiver should call the character receive subroutine with a 1-second timeout, for the remainder of the message and the . Since they are sent as a continuous stream, timing out of this implies a serious like glitch that caused, say, 127 characters to be seen instead of 128. * When the receiver wishes to , it should call a "PURGE" subroutine, to wait for the line to clear. Recall the sender tosses any characters in its UART buffer immediately upon completing sending a block, to ensure no glitches were mis- interpreted. The most common technique is for "PURGE" to call the character receive subroutine, specifying a 1-second timeout, and looping back to PURGE until a timeout occurs. The is then sent, ensuring the other end will see it. * You may wish to add code recommended by Jonh Mahr to your character receive routine - to set an error flag if the UART shows framing error, or overrun. This will help catch a few more glitches - the most common of which is a hit in the high bits of the byte in two consecutive bytes. The comes out OK since counting in 1-byte produces the same result of adding 80H + 80H as with adding 00H + 00H. 9-Feb-84 18:39:11-MST,711;000000000000 Return-Path: Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 9 Feb 84 18:39:08-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Feb 84 20:40 EST Received: From Mit-Mc.ARPA by BRL via smtp; 7 Feb 84 20:30 EST Date: Tue, 7 Feb 84 20:25:02 EST From: BRINT To: Mike Ciaraldi cc: INFO-CPM@mit-mc.arpa, POURNE@mit-mc.arpa Subject: Re: BYTE arrived... IEEE Spectrum arrived yesterday; I saw someone with a copy last week. You can't get it on the newsstands. (Who cares? Who cares when your BYTE arrived? Is that the most interesting thing that happened to you today? What a pity!) 9-Feb-84 20:46:37-MST,584;000000000000 Return-Path: Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 9 Feb 84 20:46:34-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 8 Feb 84 3:58 EST Received: From Mit-Mc.ARPA by BRL via smtp; 8 Feb 84 3:46 EST Date: 8 February 1984 03:32 EST From: Jerry E. Pournelle Subject: Turbo Pascal To: Brzozowski%his-phoenix-multics.arpa@brl cc: info-cpm@brl In-reply-to: Msg of Tue 7 Feb 84 14:09 MST from Brzozowski%his-phoenix-multics.arpa at BRL.ARPA it gets delivered in reaqsonable time and it's good stuff. 14-Feb-84 08:17:29-MST,1124;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 08:17:21-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 9 Feb 84 9:48 EST Received: From Sri-Unix.ARPA by BRL via smtp; 9 Feb 84 9:34 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Feb 84 6:25-PST Date: 8 Feb 84 8:28:41-PST (Wed) To: info-cpm@brl From: hplabs!hao!seismo!rochester!rocksvax!dave@ucb-vax Subject: Re: Floppies on VAX Article-I.D.: rocksvax.1643 In-Reply-To: Article <16380@sri-arpa.UUCP> We got that here, woork great... Probably won't work on a 750, they have no floppy disk drive built in. The thing is painfully slow however, no fault of the program, just the RX01 interface in the VAX, which is basically connected via RS232 to the PDP11 which talks through a byte or something in the VAX. Hokey but it was only intended to boot the machine and run diagnostics. We use MODEM7 on an 820 now, because it goes a bit faster.... -- Dave Arpa: Sewhuk.HENR@PARC-MAXC.ARPA uucp: {allegra, rochester, ritcv, ritvp, amd70, sunybcs}!rocksvax!dave 14-Feb-84 08:18:39-MST,1067;000000000000 Return-Path: Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 08:18:32-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 8 Feb 84 10:13 EST Received: From Ucb-Vax.ARPA by BRL via smtp; 8 Feb 84 10:07 EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.22) id AA20267; Wed, 8 Feb 84 07:00:58 pst Received: from ucbruby.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.13/4.13.1) id AA10495; Wed, 8 Feb 84 07:07:50 pst Received: by ucbruby.CC.Berkeley.ARPA (4.14/4.13) id AA26032; Wed, 8 Feb 84 07:07:46 pst Date: Wed, 8 Feb 84 07:07:46 pst From: phil%euler@BRL.ARPA Message-Id: <8402081507.AA26032@ucbruby.CC.Berkeley.ARPA> To: ruby.info-cpm@brl Subject: FORTH for the TRS-80 Model 100 In the February Byte (yes, a subscription copy), the "Microbytes" column mentions that American Micro Products has introduced a $99.95 MVP FORTH for the model 100. Hope this helps -- I don't have an address for AMP. Phil (still jlapsley%D.CC@Berkeley) 14-Feb-84 09:39:20-MST,1265;000000000000 Return-Path: Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 09:39:13-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 8 Feb 84 16:13 EST Received: From Rochester.ARPA by BRL via smtp; 8 Feb 84 15:45 EST Received: by sen.rochester (3.327.3N) id AA06883; 8 Feb 84 15:45:42 EST (Wed) Received: by cay.Rochester (3.327.3N+) id AA14096; 8 Feb 84 15:42:24 EST (Wed) Message-Id: <8402082045.6883@sen.rochester> Date: 8 Feb 84 15:45:42 EST (Wed) From: Mike Ciaraldi Subject: Z-100 Terminal emulation To: info-cpm@brl.ARPA I have encountered a problem trying to run Emacs on a VAX/Unix system using a Z-100 as a terminal. I am running MODEM712 under CP/M-85, with the flag set which allows control characters to get through to the screen (rather than being filtered out, which is the default). The Unix system (BSD 4.1c) thinks the terminal is an H-19. When I start up Emacs, everything is correct except that a "Y6" appears in the upper left corner of the screen. The cursor controls, etc. work all right. Does anyone know if there is a bug in the Z-100's emulation of the H-19, or maybe a problem in the standard Termcap? Mike Ciaraldi ciaraldi@rochester 14-Feb-84 09:48:50-MST,617;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 09:48:47-MST Date: Tue, 14 Feb 84 2:35:29 EST From: Michael John Muuss To: INFO-CPM@amsaa Subject: Change of Distribution Machine To more evenly distribute the load of transmitting all the mailing lists, the INFO-CPM list is now being transmitted by host AMSAA, rather than host BRL-VGR. Contributions to the list should still be mailed to < INFO-CPM @ BRL > and requests of the moderator should be mailed to < INFO-CPM-REQUEST @ BRL > Best, -Mike Muuss 14-Feb-84 09:55:52-MST,661;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 09:55:48-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 9 Feb 84 5:19 EST Received: From Sri-Unix.ARPA by BRL via smtp; 9 Feb 84 5:13 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Feb 84 1:55-PST Date: 28 Jan 84 20:03:26-PST (Sat) To: info-cpm@brl From: decvax!duke!phs!jtb@ucb-vax Subject: Re: ut-ngp.241: SIMTEL CP/M ARCHIVES Article-I.D.: phs.2186 I would also like a copy of any instructions on ftping files from SIMTEL perhaps someone could post them to the news.? Jose Torre-Bueno decvax!duke!phs!jtb 14-Feb-84 10:01:44-MST,1382;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 10:01:39-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 9 Feb 84 9:30 EST Received: From Sri-Unix.ARPA by BRL via smtp; 9 Feb 84 8:59 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Feb 84 5:56-PST Date: 29 Jan 84 16:40:36-PST (Sun) To: info-cpm@brl From: hplabs!intelca!proper!forcm5!jr@ucb-vax Subject: Are locations 57H through 59H used? Article-I.D.: forcm5.119 Hi. I'm interested in finding out whether the addresses 57H through 59H in the base page ("System Parameter Area") are used in any variant of CP/M. I'm especially interested in whether CP/M Plus uses these addresses. (They're listed as "reserved" in the CP/M 2.2 and MP/M II manuals). If anyone's interested in what I want to do with these addresses, think about argv[0] (that's the way the command name is passed to the program, for those of you who don't recognize that from C and UNIX)... I'd like to propose that those addresses be reserved for that purpose (along the lines of the way MP/M II stores info about the passwords from a command line), but I need to find out if there are any conflicts first... Thanks in advance! -- JR (John Rogers) UUCP: forcm5!jr, fortune!jr, proper!jr CompuServe: 70140,213 MCI Mail: jrhpp 14-Feb-84 10:28:04-MST,633;000000000000 Return-Path: Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 10:28:00-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 8 Feb 84 23:16 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 8 Feb 84 23:08 EST Date: Wed 8 Feb 84 20:09:10-PST From: Leslie Zatz Subject: DEC RAINBOW To: info-cpm@BRL.ARPA I need to transfer an addresss list now on a DEC Rainbow to my out off date system and would like to do via telephone using MDM. Does anyone have a DEC Rainbow who would be willing to load up and permit me to call to transsfer? ------- 14-Feb-84 10:33:00-MST,519;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 10:32:56-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 9 Feb 84 17:22 EST Received: From Aerospace.ARPA by BRL via smtp; 9 Feb 84 17:11 EST Date: Thu, 9 Feb 84 14:10:57 PST From: William T. Overman To: info-cpm@brl Subject: squeeze on tops-20 Does anyone know of a version of SQ (squeeze) running on TOPS-20? Thanks, Bill 14-Feb-84 10:51:25-MST,1079;000000000000 Return-Path: Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 10:51:21-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 9 Feb 84 1:50 EST Received: From Csnet-Cic.ARPA by BRL via smtp; 9 Feb 84 1:35 EST Date: 8 Feb 1984 02:04:25-EST From: erh%virginia@csnet-relay Return-Path: Subject: Turbo Pascal To: info-cpm@brl, mmdf%virginia@csnet-relay Via: Virginia; 9 Feb 84 0:17-EST Read Jerry's comments about Turbo in Feb. Byte. By the way, I disagree with his gripes concerning Borland's policy of charging extra $100 for unlimited object code distribution. Why didn't Jerry complain about Sorcim not letting people distribute freely the PRUN.COM file (i.e. the p-code interpreter that comes with Pascal/M)? In a sense, this would equivalent, as linked object code is made in large part of library procedures. Now, quite possibly the the general trend is toward automatic licensing of compiler's output. I only think that Jerry's flames were exagerated. --Ed Howorka. 14-Feb-84 11:15:09-MST,766;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 11:15:05-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 14 Feb 84 12:45 EST Received: From Rochester.ARPA by BRL via smtp; 14 Feb 84 12:33 EST Received: by sen.rochester (3.327.3N) id AA13612; 14 Feb 84 11:40:05 EST (Tue) Received: by cay.Rochester (3.327.3N+) id AA00389; 14 Feb 84 12:31:34 EST (Tue) Message-Id: <8402141640.13612@sen.rochester> Date: 14 Feb 84 11:40:05 EST (Tue) From: Mike Ciaraldi Subject: Modems Wanted Update To: Mike Ciaraldi , info-cpm@brl.ARPA I found the ad I was looking for-- USRobotics Password for $315 from S-100, inc. in Arizona. see February Byte. 14-Feb-84 11:15:38-MST,801;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 11:15:35-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 9 Feb 84 22:45 EST Received: From Mit-Mc.ARPA by BRL via smtp; 9 Feb 84 22:32 EST Date: 9 February 1984 22:33 EST From: Eric Stork Subject: HELP ON MODEM7XX FOR EAGLE II To: INFO-CPM@brl cc: STORK@mit-mc A friend in Los Angeles has an Eagle 2 and needs a version of MODEM7 to get started on communications. Would appreciate a response to STORK % MIT-MC if someone has this set up, so I can get you together with my LAX friend. Or, if you're in the LAX area, call Ernie Rosenberg at (818)501-0736 evenings, or at the office (213)486-6098. He'll sure appreciate any help getting started. 14-Feb-84 13:37:44-MST,935;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 14 Feb 84 13:37:39-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Feb 84 0:18 EST Received: From Mit-Mc.ARPA by BRL via smtp; 10 Feb 84 0:06 EST Date: 10 February 1984 00:07 EST From: Stephen C. Hill Subject: Making WordStar 3.3 come up faster To: WANCHO@stl-host1 cc: STEVEH@mit-mc, info-cpm@brl In-reply-to: Msg of 29 Jan 1984 10:10 CST (Sun) from WANCHO at STL-HOST1 Upon re-reading my preceeding message, I discovered a typo (Murphy at work again!) The actual instructions that should have been placed at 3CEB are JR 38 and NOP (18 38 00). The last NOP is just placed there for neatness, since I am replacing a three byte instruction with a two byte. Please note that the relative jump is a 38 NOT a 3A, as previously reported. Please correct the WS files at SIMTEL. Thx. 15-Feb-84 08:15:18-MST,856;000000000000 Return-Path: Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 08:15:15-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Feb 84 19:41 EST Received: From Mit-Mc.ARPA by BRL via smtp; 7 Feb 84 19:28 EST Received: by sen.rochester (3.327.3N) id AA17033; 7 Feb 84 19:29:22 EST (Tue) Received: by cay.Rochester (3.327.3N+) id AA12626; 7 Feb 84 19:25:57 EST (Tue) Message-Id: <8402080029.17033@sen.rochester> Date: 7 Feb 84 19:29:22 EST (Tue) From: Mike Ciaraldi Subject: Re: BYTE arrived... To: INFO-CPM@mit-mc.ARPA, POURNE@mit-mc.ARPA Mirabile dictu, my February Byte arrived here in Rochester on Thursday, Feb. 2. Newsstand copies arrived earlier that week. This is a new record for promptness on my subscription copy. Mike Ciaraldi ciaraldi@rochester 15-Feb-84 08:15:44-MST,2304;000000000000 Return-Path: Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 08:15:38-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Feb 84 20:20 EST Received: From Rochester.ARPA by BRL via smtp; 7 Feb 84 20:07 EST Received: by sen.rochester (3.327.3N) id AA17266; 7 Feb 84 20:08:19 EST (Tue) Received: by cay.Rochester (3.327.3N+) id AA12663; 7 Feb 84 20:05:00 EST (Tue) Message-Id: <8402080108.17266@sen.rochester> Date: 7 Feb 84 20:08:19 EST (Tue) From: Mike Ciaraldi Subject: Re: Modems wanted To: info-cpm@brl.ARPA Some prices I have seen: USRobotics Password, $339 from Image Computers, P.O.Box 1164, Cardiff, CA 92007 (619) 942-7373 Hayes Smartmodem 1200 $469 from The Byte General, 3 Sierks Lane, Roslyn Harbor NY 11576 (516) 625-0920 orders; (516) 484-6391 technical. Signalman Mark XII $329 from Aldershot's, 1103 High Vista Dr., Richardson TX 75080 (800) 527-4235 outside Texas, (214) 235-0798 inside Texas. Hayes 1200 $469 from Longwood Computing/Mail Order Heaven, 205 Birch Drive, Roslyn NY 11576 (516) 944-6117. They also have the new Prometheus Modem/Chronograph. No price listed. Rixon R212A (highly reviewed in newest Byte, I think). $455 from Micro Trend, 2001 Kirby, Suite 906, Houston TX 77019. Hayes 1200 $475 from Computers Anonymous, 278 Plandome Rd., Manhasset NY 11030 (516) 365-7982 voice or 625-0160 modem. Hayes 1200 $485 from Computer Connection, 12841 S. Hawthorne Blvd, No. 585, Hawthorne CA 90250 (213) 514-9019. US Robotics Password $340, Hayes 1200 $493 from Knowledge Systems, (213) 344-4455, 19707 Ventura Blvd., Woodland Hills Ca 91354. Rixon $469, Hayes $499 from CFX Disk Systems, POBox 90152, Norcross GA 30092 (800) 241-4783 or (404) 255-3377. These prices are fram ads in either January Byte or February Computer Shopper. ******* In addition to this, here in Rochester we arranged a group buy through Marchese Enterprises for Passwords at $325 each in blocks of at least five. And, I remember seeing the Password at $315, I think somewhere in December or January Byte, but now I can't find the ad. Hope this helps. I have no connection with any of these companies. Mike Ciaraldi ciaraldi@rochester 15-Feb-84 08:17:28-MST,1192;000000000000 Return-Path: Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 08:17:23-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 8 Feb 84 10:13 EST Received: From Sri-Unix.ARPA by BRL via smtp; 8 Feb 84 10:10 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 8 Feb 84 6:57-PST Date: 6 Feb 84 10:08:03-PST (Mon) To: info-cpm@brl From: ihnp4!afinitc!rbm@ucb-vax Subject: DRI C Problems Article-I.D.: afinitc.171 The CP/M-86 version of the Digital Research C compiler is full of floating-point bugs. Since we are planning to do a good amount of floating- point computations the Digital Research compiler is unacceptable to us. We are thus shopping for a compiler once again. If anyone knows of any other compilers which meet the following requirements I would appreciate hearing from you: - is a full C implementation (i.e. Kernighan and Ritchie) - runs in a CP/M-86 environment - has more than 64K of data space Rick Moll ..!ihnp4!afinitc Affinitec 2252 Welsch Ind. Ct. St. Louis, MO 63146 15-Feb-84 08:26:00-MST,564;000000000000 Return-Path: Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 08:25:57-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 9 Feb 84 1:50 EST Received: From Mit-Mc.ARPA by BRL via smtp; 9 Feb 84 1:38 EST Date: 8 Feb 1984 01:49:37-EST From: erh%virginia@csnet-relay Return-Path: Subject: BYTE arrived... To: INFO-CPM@mit-mc, mmdf%virginia@csnet-relay Via: Virginia; 9 Feb 84 0:17-EST Tuesday 7 February in Charlottesville VA (only two weeks after the January copy). 15-Feb-84 09:10:03-MST,831;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 09:09:48-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Feb 84 10:42 EST Received: From Radc-Tops20.ARPA by BRL via smtp; 10 Feb 84 9:39 EST Date: Fri 10 Feb 84 09:30:03-EST From: Gern Subject: INFO-HZ100 birth pains To: HZ100-Lovers: ; cc: INFO-MICRO@BRL.ARPA, INFO-CPM@BRL.ARPA Birth Pains: I am working on our mailer. The following people have been dropped off the list due to mailer problems, their mailboxes, or my own folly with this systems editor. Please resubmit your address: UMICH Z-00_people Brahms Elder WPAFB (no mailbox) NYU-INFO-HZ100 hutchinson All unix addresses (with ! in them) who did not receive this. Thanx. Gern ------- 15-Feb-84 11:09:58-MST,688;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 11:09:55-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Feb 84 12:33 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 10 Feb 84 12:13 EST Date: Fri, 10 Feb 84 08:54 PST From: Eldridge.es@PARC-MAXC.ARPA Subject: Random number generator wanted To: info-cpm@brl.ARPA cc: es820ug^.es@PARC-MAXC.ARPA, Eldridge.es@PARC-MAXC.ARPA Reply-To: Eldridge.es@PARC-MAXC.ARPA Does anyone have a linear congruential random number generator implemented in C using 32-bit words (long)? I would appreciate hearing about it. George (Eldridge.es@PARC-MAXC.ARPA) 15-Feb-84 13:32:55-MST,638;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 13:32:51-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 14 Feb 84 17:04 EST Received: From Rand-Relay.ARPA by BRL via smtp; 14 Feb 84 16:58 EST Date: 14 Feb 1984 11:45:58-PST (Tuesday) From: Jim moore Return-Path: Subject: suggest new mailing list To: info-cpm@brl Via: IBM-SJ; 14 Feb 84 13:10-PST For the obvious reasons, why don't the interested parties initiate a new mailing list: INFO-WHEN-MY-BYTE-ARRIVES Thanks, Jim 15-Feb-84 13:33:54-MST,870;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 13:33:51-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 14 Feb 84 23:53 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 14 Feb 84 23:50 EST Date: Tue 14 Feb 84 20:44:14-PST From: Leslie Zatz Subject: David Ragozin To: info-cpm@BRL.ARPA Thanks for your offer of help. I can not reach you from SUMEX at entropy!rag@uw-beaver. I get a message of no such local user. I will try again. What I want to do is to send you diskettes with a mailing list, then at your convenience, call you and receive them over the phone. If agreeable, please give me you address and phone number. Leslie M. Zatz, MD, Radiology Dept (114) VAMC, Palo Alto, CA 94304 I am going to try sending message to you direct again. ------- 15-Feb-84 13:34:00-MST,488;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 13:33:57-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 14 Feb 84 23:53 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 14 Feb 84 23:50 EST Date: Tue 14 Feb 84 20:39:22-PST From: Leslie Zatz Subject: Re: DEC RAINBOW To: info-cpm@BRL.ARPA In-Reply-To: Message from "ENTROPY!rag (David Ragozin)" of Tue 14 Feb 84 09:56:39-PST ------- 15-Feb-84 13:57:30-MST,1865;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 13:57:24-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Feb 84 20:47 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 10 Feb 84 20:43 EST From: DGILBERT.ES@PARC-MAXC.ARPA Date: 10 Feb 84 17:37:34 PST Subject: WordStar with ZCPR2 To: BURTON@BERKELEY.ARPA cc: INFO-CPM@BRL.ARPA, DGILBERT.ES@PARC-MAXC.ARPA USING WORDSTAR UNDER ZCPR2 Programs like WordStar are a problem, in that one would like to keep only 1 set of files and be able to use tham from any USER area. WordStar always looks for its overlay files on drive A, if not on the default drive. Unfortunately, there is no provision for specifying the USER area, so if your in drive G, user 7, WordStar will only check drive A, user 7 for the overlays if not on drive F, user 7. There is a solution. A public domain program called 'DUPUSR' will create a duplicate directory entry on your CP/M disk, but a new User Number. So put the WordStar files on Drive A, User 0 (physical drive E). Create duplicate entries for the overlay files for A1, A2, A3, ... to your highest user number used. Each directory entry actually points to the same allocation numbers, so there is only one actual copy of the file. This system works fine. I can be in any user number, on any disk, and run WordStar without a problem. There is only one danger. If you ever erase one of the directory entries that are duplicated in another user area, CP/M will assume it can reuse the allocation groups thus 'freed', unless you do a disk reset by 'Warm Boot'. By always doing a 'warm boot' after erasing an entry, no problem occurs. It's better than having duplicate files in every user area and wasting lots of good ol' disk space. Doug. 15-Feb-84 14:12:47-MST,908;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 14:12:42-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 15 Feb 84 15:38 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 15 Feb 84 11:25 EST Date: Wed, 15 Feb 84 08:20 PST From: Eldridge.es@PARC-MAXC.ARPA Subject: L80 patches To: info-cpm@brl.ARPA cc: es820ug^.es@PARC-MAXC.ARPA Reply-To: Eldridge.es@PARC-MAXC.ARPA I am using Link-80 3.44 09-Dec-81. It appears that L80 does a disk reset and relogs the disk every time it accesses a new REL file. This becomes very time consuming when you have a hard disk with a large directory since it must regenerate the allocation map every time it resets the disk. Is there a patch to modify this behavior? It seems that all the disk relogging is unnecessary and could be patched out. George (Eldridge.es@PARC-MAXC.ARPA) 15-Feb-84 14:18:53-MST,2094;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 14:18:46-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Feb 84 21:33 EST Received: From Ucb-Vax.ARPA by BRL via smtp; 10 Feb 84 21:26 EST Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.22/4.22) id AA08621; Fri, 10 Feb 84 18:26:49 pst Received: from ucbpopuli.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14/4.13.1) id AA14535; Fri, 10 Feb 84 18:22:53 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.14/4.13) id AA00571; Fri, 10 Feb 84 15:48:55 pst Date: Fri, 10 Feb 84 15:48:55 pst From: cgr%ucbpopuli.CC@berkeley Message-Id: <8402102348.AA00571@ucbpopuli.CC.Berkeley.ARPA> To: info-cpm@brl Subject: SUBMIT and lowercase I have a question concerning SUBMIT and XSUB. My application involves creating text files on a KayPro II (running CP/M v. 2.2) and uploading them to a Unix system. I would like to create a variety of SUBMIT files to do various kinds of error correction automatically (remove spaces at beginning and end of lines, merge multiple spaces between words, etc., etc.). Unfortunately, SUBMIT seems to automatically transform my lowercase patterns into uppercase before passing them on to ED (which can handle lowercase patterns); thus, the following script will change "AFRICA" to "ASIA" but will not change "AFrica" to "Africa". XSUB ED TEXT.MSS #A B #SAFRICA^ZASIA^Z B #SAFrica^ZAfrica^Z E Words fail me. Am I missing something? Surely serious programmers wouldn't write a major system program that can't handle lowercase?... Is there any way to circumvent this "feature"? I'm no CP/M wizard, but I'm willing to get my hands dirty if there's any kind of kludge that will let me do what I want. All suggestions gratefully considered. If there's sufficient interest, I'll summarize responses for the net. John Hevelin ucbvax!cgrucbpopuli 15-Feb-84 15:16:56-MST,2558;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 15:16:47-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 11 Feb 84 2:09 EST Received: From Mit-Mc.ARPA by BRL via smtp; 11 Feb 84 1:56 EST Date: 10 Feb 84 22:31:17 PST (Fri) To: info-cpm@mit-mc cc: young@uci-750b Subject: Turbo Pascal-- first impressions From: Michal Young Turbo Pascal arrived yesterday. I'll share some first impressions now and give a better review when I've used it for a while. First-- it is very near standard. Get and Put are not implemented, the IO primitives are instead Read and Write. The heap is really a stack and storage is returned by using mark and release instead of dispose. Goto may not leave a block (this may be a problem for error recovery). Functions and procedures may not be passed as parameters. 'Packed' is allowed but meaningless, and pack and unpack are not provided. There are numerous extensions, but they are well thought out mostly and do not screw up the syntax or semantics of the standard portion of the language. For instance, initializers are provided by an extension to the const declaration. Structures and arrays can be initialized this way. Strings up to 255 characters are allowed. A real attempt has been made to provide a programming environment rather than just a compiler. Provided the program and pascal system both fit in memory, you can edit a program, compile and run it, and edit again to fix an error without leaving the environment. And no annoying waits for overlays to load from disk, either-- compiler, editor, and program somehow fit in memory all at once. When either a syntax error or a run-time error is detected, you wind up back in the editor with the cursor at the error. If you have to run your program from outside the pascal system (because it is too big to fit with everything else in memory), you can still find the source line in error. You reenter the pascal system and tell it the program counter address, and it re-compiles until it comes to that address. Pretty slick. There are a few rough edges, but I haven't ever seen a compiler (not interpreter) this nice to work with. The documentation is good. 250+ pages in a paperback book, reasonably well written but not outstanding. This same manual covers CP/M-80, CP/M-86, and MS-DOS versions. Except for BIOS level diddling (which turbo will allow), it looks to be portable. Michal Young young@uci 15-Feb-84 15:34:42-MST,1531;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 15:34:34-MST Received: From Brl-Bmd.ARPA by BRL-VGR via smtp; 11 Feb 84 8:10 EST Date: Sat, 11 Feb 84 8:01:11 EST From: Charlie Strom (NYU) To: DGILBERT.ES@parc-maxc.arpa cc: INFO-CPM@brl-vgr Subject: SETDRU Another solution to the problem of multiple overlays is a program called SETDRU, authored by Mike Rubenstein. SETDRU is a BDOS filter which allows remapping of up to 8 file specifications (unambiguous or ambiguous) so that a program can access any other files on any drive/user. This works very well with Wordstar, and allows me to have a small (<1K) program called EDIT.COM on my ZCPR2 root du. Invoking EDIT will call Wordstar which could be on any other du as well as its overlays which could be on the same or yet another du. If ZCPR is not installed, one must have multiple copies of EDIT.COM, but not of WS or its overlays. SETDRU actually consists of a user interface and two filters, one that allows the filter to be bound to the .COM program of interest and another which calls the program. The latter is required for programs such as WS that test its integrity after re-entry from the R command. SETDRU is in Z80 code. I will be completing an 8080 conversion in a few days and will upload relevant files to Simtel at that time and will post a notice to the list. I have run this program successfully under CP/M Plus as well as 2.2. 15-Feb-84 15:57:56-MST,1755;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 15:57:49-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 15 Feb 84 15:58 EST Received: From Rochester.ARPA by BRL via smtp; 15 Feb 84 15:51 EST Received: by sen.rochester (3.327.3N) id AA15602; 15 Feb 84 15:51:01 EST (Wed) Received: by cay.Rochester (3.327.3N+) id AA03199; 15 Feb 84 15:48:25 EST (Wed) Message-Id: <8402152051.15602@sen.rochester> Date: 15 Feb 84 15:51:01 EST (Wed) From: Mike Ciaraldi Subject: Re: Need help designing homebrew system To: info-cpm@brl.ARPA, menlo70!nsc!nessus@ucb-vax.ARPA I would recommend some good books on designing digital and computer hardware. Don Lancaster's "TTL Cookbook" covers the basics, and I think he has one for microprocessors now. Sol Libes and someone whose name I forgot have a book on interfacing to the S-100 bus. I realize you are using the Multibus, but the principles are similar. You might also get the books Godbout publsihes which collect all the technical manuals of their products. Intel makes several Multibus CPU, memory, and peripheral boards. I think they will send you tech manuals, including schematics, for free. In addition, if you want to run CP/M 3.0 you will need bank switching so the CPU can address more than 64K of memory. Just having a latch for hig-order address lines may not be enough. finally, for bringing up the software, look at the sample BIOS's in the SIMTEL archives. It is much easier to produce a working CP/M operating systemif you have access to another CP/M system with assembler, editor, and compatible disk drives. Good luck! Mike Ciaraldi ciaraldi@rochester 15-Feb-84 18:05:03-MST,1763;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 18:04:57-MST Date: Wed, 15 Feb 84 19:50:11 EST From: Dave Towson (info-cpm) To: info-cpm@amsaa Subject: Mail problems at BRL. ----- Forwarded message # 1: Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 13 Feb 84 19:42 EST Received: From Rand-Unix.ARPA by BRL via smtp; 13 Feb 84 19:28 EST From: vortex!lauren@rand-unix Date: Mon, 13-Feb-84 15:34:06-PST Sender: Lauren Weinstein Subject: lists Message-ID: <8402131534.8779.2.VT2.2@vortex.UUCP> To: UNIX-WIZARDS-REQUEST@brl, INFO-MICRO-REQUEST@brl, INFO-CPM-REQUEST@brl Are these lists all healthy? I got virtually no traffic over the weekend, including messages I sent myself to all three lists. I continue to get copies of messages from people talking about their damn Byte subscriptions, however... Thanks much for any info. --Lauren-- ----- End of forwarded messages Lauren and all others on info-cpm - It has just been discovered that a mailer bug was being triggered by mail rejected from Rand-Unix due to an upper/lower case switch in the mailing list. This has been fixed with a band-aid, and the local mail people think things should be working okay now. Also, to relieve a serious mail-handling load on BRL-VGR, the list has been moved to my home machine (yay!) AMSAA. Mail to the list should now be addressed to info-cpm@brl or info-cpm@amsaa (take your pick). Likewise, mail having to do with list changes, additions, deletions or other such matters should go to info-cpm-request@brl or @amsaa. Sorry for the past inconvenience. Dave Towson info-cpm-request@amsaa 15-Feb-84 18:51:45-MST,1657;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 15 Feb 84 18:51:39-MST Date: Wed, 15 Feb 84 20:36:34 EST From: Dave Towson (info-cpm) To: info-cpm@amsaa Subject: [knutson: Re: Z-100 Terminal emulation] ----- Forwarded message # 1: Received: From Brl-Vgr.ARPA by AMSAA via smtp; 15 Feb 84 15:37 EST Received: From Ut-Ngp.ARPA by BRL-VGR via smtp; 15 Feb 84 10:03 EST Date: Wed, 15 Feb 84 09:05:18 cst From: knutson@ut-ngp.ARPA Posted-Date: Wed, 15 Feb 84 09:05:18 cst Message-Id: <8402151505.AA19163@ut-ngp.ARPA> Received: by ut-ngp.ARPA (4.22/3.14) id AA19163; Wed, 15 Feb 84 09:05:18 cst To: info-cpm-request@BRL-VGR.ARPA Subject: Re: Z-100 Terminal emulation Cc: ciaraldi@rochester.ARPA I have set up a Z100 termcap entry that seems to work rather well. It has been run on a line at upto 2400 baud without problems. # the following are termcap entries that have been modified # from /etc/termcap or are terminals that are used besides the # ones that were modified. zc|z100c|h100c|z-100c|h-100c|heath/zenith z-100 pc with color monitor:\ :vs=\Ex4\Em71:ve=\Ey4\Em70:tc=z100: z1|z100|h100|z-100|h-100|heath/zenith z-100 pc:\ :al=5*\EL:bs:cd=\EJ:ce=\EK:cl=5*\EE:cm=1*\EY%+ %+ :co#80:dc=1*\EN:\ :dl=5*\EM:do=\EB:ei=\EO:ho=\EH:im=\E@:li#24:mi:nd=\EC:as=\EF:ae=\EG:\ :ms:pt:sr=\EI:se=\Eq:so=\Ep:up=\EA:vs=\Ex4:ve=\Ey4:\ :kb=^h:ku=\EA:kd=\EB:kl=\ED:kr=\EC:kh=\EH:kn#10:\ :k0=\EJ:k1=\ES:k2=\ET:k3=\EU:k4=\EV:k5=\EW:\k6=\EP:k7=\EQ:\ :k8=\ER:k9=\EOI: Jim Knutson knutson@ut-ngp ----- End of forwarded messages 16-Feb-84 08:00:17-MST,933;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 08:00:12-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 15 Feb 84 23:14 EST Received: From Ut-Ngp.ARPA by BRL via smtp; 15 Feb 84 23:03 EST From: mknox@ut-ngp.ARPA Posted-Date: Wed, 15 Feb 84 22:01:30 CST Message-Id: <8402160404.AA04631@ut-ngp.ARPA> Received: by ut-ngp.ARPA (4.22/3.14) id AA04631; Wed, 15 Feb 84 22:04:59 cst Date: Wed, 15 Feb 84 22:01:30 CST To: info-cpm@brl.ARPA Subject: IBM-PC CP/M-86 Kermit needed I fear my first msg fell into a week long 'bit-bucket' which existed. So now I will ask again: Does anyone have an implementation of KERMIT for the IBM-PC under CP/M-86? The only ones at Columbia seem to be for the RAINBOW and NEC-APC. A crude job would still be useful to me, as long as it can send and receive binary files. thanks; MKNOX at UT-NGP 16-Feb-84 09:18:03-MST,687;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:17:59-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 16 Feb 84 4:30 EST Received: From Mit-Mc.ARPA by BRL via smtp; 16 Feb 84 4:21 EST Date: 16 February 1984 04:21 EST From: Jerry E. Pournelle Subject: Turbo Pascal-- first impressions To: young@uci-750a cc: INFO-CPM@mit-mc, young@uci-750b In-reply-to: Msg of 10 Feb 84 22:31:17 PST (Fri) from Michal Young Turbo, most tell me, is pretty good, BUT: do this foo := 1.23 * 100 now take frac of foo. It won't be zero. They say they'll fix that real soon now 16-Feb-84 09:18:52-MST,1138;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:18:44-MST Received: From Brl-Vgr.ARPA by AMSAA via smtp; 16 Feb 84 4:59 EST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 16 Feb 84 4:52 EST Date: 16 February 1984 04:53 EST From: Jerry E. Pournelle Subject: writing w/o opening To: ciaraldi@rochester cc: w8sdz@brl, Info-Cpm@brl-vgr In-reply-to: Msg of 24 Jan 84 15:06:00 EST (Tue) from Mike Ciaraldi it's not. sigh Date: 24 Jan 84 15:06:00 EST (Tue) From: Mike Ciaraldi To: Info-Cpm at brl-vgr.ARPA, w8sdz at brl.ARPA Re: writing w/o opening Under MP/M, there is a checksum in the FCB. This gets set when you open the file, and you cannot read or write on the file unless this checksum is correct. So, the problem of wiping out your directory by not opening the file first should not occur. I don't know if this technique is used in newer products such as CP/M-86 or CP/M-Plus Mike Ciaraldi ciaraldi@rochester 16-Feb-84 09:31:06-MST,611;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:31:01-MST Received: From Brl-Vgr.ARPA by AMSAA via smtp; 16 Feb 84 9:47 EST Date: Thu, 16 Feb 84 9:42:33 EST From: Mike Muuss To: info-cpm@brl-vgr Subject: VAX UNIX <-> CPM program needed I know that a VAX UNIX (4.2 BSD) program to read/write 8" CPM floppies on the VAX 780 console floppy drive exists. I find myself in the embarrassing position of needing a copy for one of our users. Can somebody please provide a copy, or pointers? Best, -Mike Muuss 16-Feb-84 09:35:25-MST,985;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:35:16-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Feb 84 3:36 EST Received: From Sri-Unix.ARPA by BRL via smtp; 10 Feb 84 3:28 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 10 Feb 84 0:24-PST Date: 9 Feb 84 11:18:13-PST (Thu) To: info-cpm@brl From: menlo70!nsc!nessus@ucb-vax Subject: Need help designing homebrew system Article-I.D.: nsc.623 I am considering building a homebrew computer system and would like to make it CP/M compatible. Anyone have any ideas about designing such a thing{hardware and software}? The system will be using Multibus(tm) boards and card cage. Please do not advise me to go and buy XYZ system. My budget cannot afford buying a computer. I collected the necessary components{disks, RAM, and such from my company electronics club. Kchula-Rrit !menlo70!nsc!nessus 16-Feb-84 09:36:09-MST,416;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:36:03-MST Received: From Minet-Obl-Em.ARPA by BRL-VGR via smtp; 10 Feb 84 3:51 EST Date: 10 February 1984 08:48 GMT From: byard@minet-obl-em Subject: 8 Mhz Engine To: info-cpm@brl-vgr Date: 10 Feb 1984 08:44:52 Z Text: According to the latest issue of InfoWorld that's what Mac has. Larry 16-Feb-84 09:43:13-MST,5218;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:42:58-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 12 Feb 84 5:44 EST Received: From Rand-Unix.ARPA by BRL via smtp; 12 Feb 84 5:28 EST From: vortex!lauren@rand-unix Date: Sun, 12-Feb-84 00:40:50-PST Sender: Lauren Weinstein Subject: Cure for Vadic Triple Modem Problem... Message-ID: <8402120040.04737dVT2.1@vortex.UUCP> To: INFO-MICRO@brl, INFO-CPM@brl, UNIX-WIZARDS@brl, TELECOM@mc So bunky, you say you got yourself a Racal-Vadic triple modem (3451-series) and you have some problems with it? You say that sometimes in auto-answer mode it seems to hang offhook, making it impossible for any new calls to arrive? You say that when this happens it refuses to respond to DTR and only resets if you cycle the power or fiddle with the mode toggle switch (if you have one, that is)? Is that what's bothering you, bunky? WELLLLL! Lift up your head and greet the sun, 'cause a solution does exist -- and it doesn't even involve hydrochloric acid or jackhammers! Seriously, though, many persons have reported problems with triple modems getting into a strange wedged condition from which it is difficult to escape. Both manual dial and autodial triples have shown this behavior, which is characterized by the modem being offhook, sending a 212 carrier, and having both the HS and DSR lights lit. Only cycling the power or performing a software reset (by flipping the toggle switch between auto and manual on the autodial modems) will clear this condition; the modem is oblivious to DTR. After having this occur repeatedly on the main Vortex dialup line, I started harassing the engineers up at Racal. Actually, they were quite helpful, once they realized that I knew what I was talking about and hadn't plugged the RJ-11C phone plug into an AC wall outlet! After talking with three different engineers and having them duplicate the problem on their test benches, we arrived at the cause of the problem and a (simple) solution. The problem is caused by a "hole" in the triple modem protocol select algorithm. Under certain random timing conditions, the modem may be "fooled" into entering a pseudo-originate mode during its answer-mode operations. The exact reasons are too complex to go into here, but the cure is straightforward: Inside the modem, option dip switch A1 is described by the manual as: "Attended/Unattended Disconnect -- Set to Attended [ON] for Auto Dial modems. (Unattended setting relates to manual originate operation only.)" DON'T YOU BELIEVE IT! This switch also affects the handling of DTR during answer mode processing. The "normal" setting of this option (as set by the "standard-options" switch A6) is ON (Attended). This is WRONG for almost all operations. For both auto-dial and non-autodial triple modems, this option should normally be set to OFF (Unattended). The only side effect of this is that if you attempt to use the modem in a MANUAL originate mode, you will probably have to supply DTR at the RS232 interface (big deal!) If you leave A1 OFF, the answer mode wedging problem should vanish! Auto-dial operations on auto-dial modems should work as always. NOTE: If your triple has switch A6 OFF, then "standard-options" mode is ENABLED and the remaining A and B switches are ignored. In order to change the state of A1 to OFF, you must also turn switch A6 ON to disable "standard-options" and make sure that all other switches are set appropriately. I recommend the following settings (some of these are NOT the default settings): A1 -- OFF (Unattended -- fixes the answer wedge problem) A2 -- OFF (Do NOT respond to remote test) [do you want everyone in the universe "testing" your modem for you?] A3 -- ON (10 bit chars -- this is normal) A4 -- ON 103 operation enabled A5 -- OFF (10 bit chars -- this is normal) A6 -- ON Disable standard-options (enables all other switches) A7 -- ON Auto-disconnect on loss of carrier enabled B1 -- OFF Local digital loopback select (ignored when not testing) B2 -- OFF DTR controlled from RS232 interface B3 -- OFF Originate and Answer modes allowed B4 -- OFF 1204 bps speed (this is normal) B5 -- ON Auto-disconnect/Abort timer enabled B6 -- OFF Asynchronous operation B7 -- ON DSR off in test (ignored when not testing) In addition, I recommend the following two jumper changes on the BOTTOM pc board: Insert jumper "r" -- enable data rate indicator on RS232 pin 12 Remove jumper "ag" -- do not tie carrier detect high (RS232 pin 8) ------ The "wedged" condition mentioned above, being related to a rather random timing window, is more likely to have been seen on modems that have a high volume of calls than on low volume incoming lines. However, it occurs frequently enough that I recommend the option change for all triple modems being used for incoming calls. Be sure to let me know if you have any questions about or problems with this info. I hope it's of some use, bunky... --Lauren-- 16-Feb-84 09:45:21-MST,683;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:45:17-MST Received: From Ut-Ngp.ARPA by BRL-VGR via smtp; 12 Feb 84 21:17 EST From: mknox@ut-ngp.ARPA Posted-Date: Sun, 12 Feb 84 20:16:31 CST Message-Id: <8402130218.AA02725@ut-ngp.ARPA> Received: by ut-ngp.ARPA (4.22/3.14) id AA02725; Sun, 12 Feb 84 20:18:41 cst Date: Sun, 12 Feb 84 20:16:31 CST To: info-cpm@brl-vgr.ARPA Subject: KERMIT :: CP/M-86 Does anyone have a version of KERMIT that runs on the IBM-PC under CP/M-86? Currently I have only found the NECAPC and RAINBOW versions. Or am I going to need to 'pre-invent' the wheel? tnx 16-Feb-84 09:45:42-MST,1173;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:45:37-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 12 Feb 84 11:03 EST Received: From Mit-Mc.ARPA by BRL via smtp; 12 Feb 84 10:45 EST Date: 12 February 1984 10:45 EST From: Allan D. Plehn Subject: WARNING about Micro Design Associates. To: INFO-CPM@mit-mc, INFO-MICRO@mit-mc cc: PLEHN@mit-mc Two friends of mine have purchased the disk controller board offered by Micro Design Associates, Columbia, Mo. Neither has been able to make it work. Efforts to contact the company have been futile; their telephone has been disconnected. The disk controller was advertised in a full page ad on page 19 of the December 1983 issue of Microsystems Magazine. It is a IEEE-696 (S-100) board and is supposed to run 5 1/4 and 8 inch drives simultaneously. The software provided is said to allow writing sixteen specified soft sectored formats "and most others". I'd appreciate hearing from others who may have ordered this board. Did yours work or not? Have you discovered any fixes? Etc. etc. PLEHN%MIT-MC 16-Feb-84 09:48:05-MST,1000;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 09:47:58-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 13 Feb 84 10:16 EST Received: From Radc-Tops20.ARPA by BRL via smtp; 13 Feb 84 9:50 EST Date: Mon 13 Feb 84 09:50:44-EST From: Gern Subject: Mail relay for INFO-HZ100 To: INFO-HZ100@RADC-TOPS20.ARPA cc: INFO-MICRO@BRL.ARPA, INFO-CPM@BRL.ARPA With any luck, my TOPS20 system is patched to relay all INFO-HZ100@RADC-TOPS20 back out to the distribution list of approximately 60 persons. This is a test message. All mailing list submissions are to INFO-HZ100 @RADC-TOPS20 and requests to INFO-HZ100-REQUEST@RADC-TOPS20. Any persons or systems still not getting these messages as requested please rerequest as my mailer choked on several addresses and UNIX addresses (corrected) and you were hacked off the list to allow the system to work at all. Thanx, Gern ------- 16-Feb-84 11:03:23-MST,1396;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 11:03:17-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 13 Feb 84 16:58 EST Received: From Mit-Mc.ARPA by BRL via smtp; 13 Feb 84 15:49 EST Received: from RU-BLUE.ARPA by RUTGERS.ARPA with PUP; 13 Feb 84 15:30:19 EST Date: 13 Feb 84 15:29:37 EST From: Charles Subject: Need microcomputer "C" with UNIX IO To: C-folks: ; Hello, We're implementing a multi-user distributed adventure game here and want to find a C with UNIX IO (as close to Berkely's as possible would be nice). We're soliciting for comments and suggestions on the C compilers available. We are talking mostly about small machines, as in 6502, Z80 or (gag me with advertising hype) 8088, but comments about C that runs on non-unix 68000s would be appreciated. It should be a complete C through to enumeration types. We need to watch two ports at once (keyboard and communications), so some kind of non-blocking IO or interrupt support would be a must. Needed features: fseek non-blocked IO (as in NO_DELAY in ioctl), or better, IO interrupt signals as on Berkely. Desired features: enumeration types reasonably fast code (always a help, eh?) Please send recommendations and comments to MCGREW@RU-BLUE. Thanks, Charles ------- 16-Feb-84 11:14:29-MST,644;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 11:14:25-MST Received: From Brl-Vgr.ARPA by AMSAA via smtp; 16 Feb 84 12:57 EST Received: From Uw-Beaver.ARPA by BRL-VGR via smtp; 16 Feb 84 12:44 EST Date: 16 Feb 84 09:36:04 PST (Thu) From: David Ragozin Received: by ENTROPY.UUCP (3.320/4.2) id AA17521; 16 Feb 84 09:36:04 PST (Thu) Subject: Re: VAX UNIX <-> CPM program needed Message-Id: <8402161736.AA17521@ENTROPY.UUCP> To: info-cpm@brl-vgr, uw-beaver!mike@brl-vgr I think its in SIMTEL20 under micro: with a name like cpmutl. 16-Feb-84 11:15:09-MST,1326;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 11:15:00-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 13 Feb 84 19:42 EST Received: From Ucb-Vax.ARPA by BRL via smtp; 13 Feb 84 19:22 EST Received: from ucbjade.CC.Berkeley.ARPA (19002080) by UCB-VAX.ARPA (4.22/4.22) id AA29992; Mon, 13 Feb 84 13:32:15 pst Received: from ucbruby.CC.Berkeley.ARPA by ucbjade.CC.Berkeley.ARPA (4.14/4.13.1) id AA12265; Mon, 13 Feb 84 13:27:46 pst Received: by ucbruby.CC.Berkeley.ARPA (4.14/4.13) id AA10447; Mon, 13 Feb 84 13:22:33 pst Date: Mon, 13 Feb 84 13:22:33 pst From: phil%euler@BRL.ARPA Message-Id: <8402132122.AA10447@ucbruby.CC.Berkeley.ARPA> To: ruby.info-cpm@brl Subject: Minor gripe about advertisements It really irritates me when a company has what looks to be a nice product (e.g, Turbo Pascal) and they claim it runs on "CP/M-80", but they don't bother to mention that it's Z-80 only. At the risk of starting a general flame ("Anyone who wouldn't use a Z-80 is an idiot"), anyone have any ideas on what percentage of the CP/M-80 market is Z-80? Mail to me, I will summarize if it is of general interest or if there is a great response. Both are unlikely. Phil (jlapsley%D.CC@Berkeley, ignore the headers) 16-Feb-84 16:40:09-MST,566;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 16 Feb 84 16:40:05-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 13 Feb 84 23:28 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 13 Feb 84 23:16 EST Date: Mon 13 Feb 84 20:12:53-PST From: Leslie Zatz Subject: dec RAINBOW To: info-cpm@BRL.ARPA Would someone with a DEC RAINBOW be able to load in a mailing address list from a diskette and let me down- load it using MDM via phone? Leslie M. Zatz, Stanford ------- 17-Feb-84 08:46:55-MST,568;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 17 Feb 84 08:46:50-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Feb 84 2:27 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 14 Feb 84 2:16 EST From: ssalzman.es@PARC-MAXC.ARPA Date: 14 Feb 84 2:15:08 EST Subject: morrow md-3 & bye3 To: info-cpm@brl.ARPA cc: ssalzman.es@PARC-MAXC.ARPA Does anyone know of someone who is running BYE3 on a Morrow MD-3??? I need to get info on how to initialize the baud rate for it. Thanks. -Isaac. 17-Feb-84 18:42:04-MST,3147;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 17 Feb 84 18:41:56-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 17 Feb 84 20:17 EST Received: From Mit-Mc.ARPA by BRL via smtp; 17 Feb 84 20:14 EST Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 17-Feb-1984 20:06:12-est Date: Fri, 17 Feb 84 18:05 MST From: Kevin Kenny Subject: Turbo Pascal--first impressions Reply-To: Kenny%PCO@CISL-SERVICE-MULTICS.ARPA To: "Dr Jerry E. Pournelle" cc: INFO-CPM@MIT-MC.ARPA Message-ID: <840218010529.999942@HIS-PHOENIX-MULTICS.ARPA> The problem that you're describing (where frac (1.23 * 100) isn't zero) is the usual truncation error in binary arithmetic. If they say that they'll fix it Real Soon Now, they either are lying, or mean that they intend to foul things up further; to someone who's doing numerical analysis, the result is CORRECT (if it's very close to 0 or 1; you didn't say what the result is, just what it isn't). [flame on] I am getting awfully tired of people who say that decimal arithmetic is "inherently more accurate" than binary. This claim is absolute rubbish. [blowtorch valve off again]. The problem, of course, is that there is no exact binary representation for 1.23; the expansion is a repeating string beginning 1.0011101011100001010001 with the last twenty digits repeating. The fact that 1.23 can be represented as a finite-length string in decimal leads people to claim that "decimal is more accurate." But, try representing 1/3 in either system. It doesn't go, does it? Does this say that we should all switch to the ancient Babylonian (base sixty) system, where 1/3 can be represented exactly as <00>.<20>? I don't think so. The point is, that any number can be represented to any level of precision (short of exact) in any radix. No radix can represent all numbers exactly; Georg Cantor proved that a long time ago. I concede that there is a problem in dealing with bankers and other people who expect dollars and cents to come out even. But a dollar amount isn't a floating point number at all: it's an integer number of cents! In COBOL and PL/1, there are facilities to deal with the idea that an integer might have a "decimal point" in its displayed representation. In most other languages, you just have to remember that a variable contains an amount in cents and convert it before displaying. It's not that tough. Really it isn't. The floating point implementations that "don't have this problem" use "fuzzy comparisons". What this means is that if the difference between two numbers is less than some arbitrary constant times the smaller one, they are considered equal. This keeps the bankers happy, but drives the engineers up a wall; there's an implicit loss of (real) precision to gain the (perceived) accuracy. Enough said. Just a one sentence summary: COMPARING TWO FLOATING POINT NUMBERS FOR EXACT EQUALITY IS NEARLY ALWAYS A MISTAKE, WHATEVER BASE THE MACHINE USES. /k**2 20-Feb-84 09:55:03-MST,1166;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 09:54:57-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 18 Feb 84 5:19 EST Received: From Mit-Mc.ARPA by BRL via smtp; 18 Feb 84 5:06 EST Date: 18 February 1984 05:06 EST From: Jerry E. Pournelle Subject: Turbo Pascal--first impressions To: Kenny%PCO@cisl-service-multics cc: INFO-CPM@mit-mc In-reply-to: Msg of Fri 17 Feb 84 18:05 MST from Kevin Kenny 1. My mistake: I repeated something I was told. 2. Turbo is going to DOCUMENT the fact that frac of a floating point number is close to ONE, not close to ZERO; apparently this representation scheme is in use in other machines, and they're staying compatible. 3. Computer science is wonderful, but I'm glad you don't do my taxes or take care of my bank account. 4. I don't much care about the subjects of your flame, but I do care about ease of use and just getting the job done; and I don't think I want to train MBA candidates to think about numerical representations, merely to be able to use the machines. 20-Feb-84 09:55:34-MST,1442;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 09:55:28-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 18 Feb 84 15:05 EST Received: From Mit-Xx.ARPA by BRL via smtp; 18 Feb 84 14:58 EST Date: Sat 18 Feb 84 14:58:35-EST From: Larry Seiler Subject: Floating point money To: POURNE@MIT-MC.ARPA cc: Seiler@MIT-XX.ARPA, Info-CPM@BRL.ARPA FLoating point numbers are the wrong thing to use in what is essentially an integral application (integral numbers of pennies). Although there are ways around this - such as rounding values to the nearest penny before comparing them. If you want ease of use for those MBA's (a worthy goal, certainly), then print out numbers and let them type numbers with two digits past the decimal point, but store all numbers internally as numbers of pennies (the MBA's won't be writing programs, just using them). And keep those MBA's away from Multiplan. While I love Multiplan dearly, don't expect it to work any better than Turbo Pascal on floating point comparisons. In fact, my copy of Multiplan (for the VT180) can't even round zero to two decimal places and get something that is equal to zero (details on request). Number representation is a tricky problem, I'm sorry to say, and I'd hate to use a tax program w