CP/M

home *** CD-ROM | disk | FTP | other *** search

/ CP/M / CPM_CDROM.iso / simtel / archives / cpm / 8402-1.txt < prev next >

Wrap

Text File | 1993-02-12 | 208KB | 5,058 lines

1-Feb-84 11:42:47-MST,961;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <ZATZ@SUMEX-AIM.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <OTHB@SRI-KL.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <SHahn@SUMEX-AIM.ARPA> 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 <OTHB@SRI-KL.ARPA>" 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: <info-cpm-request@BRL-VGR.ARPA> 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 <GUBBINS@RADC-TOPS20.ARPA> 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) <GUBBINS@RADC-TOPS20> ------- 2-Feb-84 10:22:24-MST,647;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <rconn@brl> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <rconn@brl> 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: <info-cpm-request@BRL-VGR.ARPA> 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) <cpmlist@brl-vgr> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <KPETERSEN@SIMTEL20.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <KENT@SUMEX-AIM.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <MAILER-DAEMON@LANL> 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 <KENT@SUMEX-AIM.ARPA> 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 <KENT@SUMEX-AIM.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <erh%Virginia@CSNet-Relay> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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) <cpmlist@brl-vgr> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <ciaraldi@Rochester.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <ciaraldi@Rochester.ARPA> 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:<UNIX.CPM>. 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: <info-cpm-request@BRL-VGR.ARPA> 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 <BEC.SHAPIN@USC-ECL.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <LIN@mit-mc> 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: <info-cpm-request@BRL-VGR.ARPA> 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) <strom@brl-bmd> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <w8sdz@brl> 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: <info-cpm-request@BRL-VGR.ARPA> 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) <towson@amsaa> To: Herb Lin <LIN@mit-mc> cc: info-cpm@brl Subject: Re: getting KERMIT - where is it? Herb - Kermit is on Columbia-20 in directory PS:<KERMIT>. Using FTP, do "dir ps:<kermit>" to see what's there. Dave towson@amsaa 6-Feb-84 08:38:28-MST,1374;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> 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 <Tli@usc-eclb> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <goldfarb.UCF-CS@Rand-Relay> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <LIN@mit-mc> Herb, KERMIT is at (via FTP) COLUMBIA20 (can't remember if the 20 should be -20; try both) DIR <KERMIT> will get you the listing GET <KERMIT>-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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <goldfarb.UCF-CS@Rand-Relay> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <erh%Virginia@CSNet-Relay> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <POURNE@mit-mc> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <Edens@office-3> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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) <cpmlist@brl-vgr> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <jperry@nosc> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <w8sdz@brl> 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. <soh> 01H <eot> 04H <ack> 06H <nak> 15H <can> 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: <SOH><blk #><255-blk #><--128 data bytes--><cksum> in which: <SOH> = 01 hex <blk #> = 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". <cksum> = 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 <can>, 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 <ack> <nak> or <soh> being corrupted into a <can> 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 <nak> every time it times out. The receiver's first timeout, which sends a <nak>, signals the transmitter to start. Optionally, the receiver could send a <nak> 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 <nak> 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 <ack> 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 <ack>. Abort the transmission, sending a <can> ---- 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 <eot>, and awaits an <ack>, resending the <eot> 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 <ack> reply getting garbaged. <xx> represents the checksum byte. SENDER RECEIVER times out after 10 seconds, <--- <nak> <soh> 01 FE -data- <xx> ---> <--- <ack> <soh> 02 FD -data- xx ---> (data gets line hit) <--- <nak> <soh> 02 FD -data- xx ---> <--- <ack> <soh> 03 FC -data- xx ---> (ack gets garbaged) <--- <ack> <soh> 03 FC -data- xx ---> <ack> <eot> ---> <--- <ack> -------- 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 <nak> and try again, 10 times. After receiving the <soh>, the receiver should call the character receive subroutine with a 1-second timeout, for the remainder of the message and the <cksum>. 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 <nak>, 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 <nak> 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 <cksum> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <abc@brl-bmd> To: Mike Ciaraldi <ciaraldi@rochester.arpa> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <POURNE@mit-mc> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <ciaraldi@Rochester.ARPA> 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: <info-cpm-request@AMSAA.ARPA> 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 <mike@amsaa> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <ZATZ@SUMEX-AIM.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <overman@aerospace> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <erh%Virginia@CSNet-Relay> 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: <info-cpm-request@AMSAA.ARPA> 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 <ciaraldi@Rochester.ARPA> Subject: Modems Wanted Update To: Mike Ciaraldi <ciaraldi@Rochester.ARPA>, 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: <info-cpm-request@BRL-VGR.ARPA> 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 <STORK@mit-mc> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <STEVEH@mit-mc> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <ciaraldi@Rochester.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <ciaraldi@Rochester.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <erh%Virginia@CSNet-Relay> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <GUBBINS@RADC-TOPS20.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@AMSAA.ARPA> 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 <MOORE.LOSANGEL.IBM@rand-relay> Return-Path: <MOORE.LOSANGEL.IBM-SJ@Rand-Relay> 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: <info-cpm-request@AMSAA.ARPA> 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 <ZATZ@SUMEX-AIM.ARPA> 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: <info-cpm-request@AMSAA.ARPA> 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 <ZATZ@SUMEX-AIM.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@AMSAA.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <young@uci-750a> 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: <info-cpm-request@BRL-VGR.ARPA> 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) <strom@brl-bmd> 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: <info-cpm-request@AMSAA.ARPA> 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 <ciaraldi@Rochester.ARPA> 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: <info-cpm-request@AMSAA.ARPA> 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) <cpmlist@amsaa> 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 <vortex!lauren@rand-unix> 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: <info-cpm-request@AMSAA.ARPA> 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) <cpmlist@amsaa> 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: <info-cpm-request@AMSAA.ARPA> 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: <info-cpm-request@AMSAA.ARPA> 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 <POURNE@mit-mc> 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 <young at uci-750a> 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: <info-cpm-request@AMSAA.ARPA> 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 <POURNE@mit-mc> 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 <ciaraldi at Rochester.ARPA> it's not. sigh Date: 24 Jan 84 15:06:00 EST (Tue) From: Mike Ciaraldi <ciaraldi at Rochester.ARPA> 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: <info-cpm-request@AMSAA.ARPA> 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 <mike@brl-vgr> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <vortex!lauren@rand-unix> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <PLEHN@mit-mc> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <GUBBINS@RADC-TOPS20.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <MCGREW@RU-BLUE.ARPA> 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: <info-cpm-request@AMSAA.ARPA> 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 <ENTROPY!rag@BRL-VGR.ARPA> 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:<unix.cpm> with a name like cpmutl. 16-Feb-84 11:15:09-MST,1326;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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 <ZATZ@SUMEX-AIM.ARPA> 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: <info-cpm-request@BRL-VGR.ARPA> 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: <info-cpm-request@AMSAA.ARPA> 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 <Kenny%his-phoenix-multics.arpa@BRL.ARPA> Subject: Turbo Pascal--first impressions Reply-To: Kenny%PCO@CISL-SERVICE-MULTICS.ARPA To: "Dr Jerry E. Pournelle" <POURNE@MIT-MC.ARPA> 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: <info-cpm-request@AMSAA.ARPA> 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 <POURNE@mit-mc> 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 <Kenny%his-phoenix-multics.arpa at BRL.ARPA> 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: <info-cpm-request@AMSAA.ARPA> 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 <Seiler@MIT-XX.ARPA> 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 written by someone who couldn't see what the problem is. Larry ------- 20-Feb-84 09:56:26-MST,883;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 09:56:22-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 18 Feb 84 21:26 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 18 Feb 84 21:15 EST From: DGILBERT.ES@PARC-MAXC.ARPA Date: 18 Feb 84 17:55:43 PST Subject: WHERE IS DUPUSR? To: INFO-CPM@BRL.ARPA Sorry for the large distribution, but I can't successfully send this message to BURTON@UCB-VAX.ARPA directly. In answer to your question..... ================================================ where is this wonderful DUPUSR program located? tnx. ================================================ Well, Just about any fairly well stocked RCPM system will have DUPUSR. I downloaded mine from Pete Mack Simi Valley RCPM 805 - 527 - 2219 Was on drive F1: DUPUSR21.AQM Doug. 20-Feb-84 09:56:39-MST,1205;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 09:56:34-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 18 Feb 84 23:03 EST Received: From Mit-Mc.ARPA by BRL via smtp; 18 Feb 84 22:49 EST Date: Sat 18 Feb 84 22:50:48-EST From: Mark Becker <CENT.MBECK%MIT-OZ@MIT-MC.ARPA> Subject: Re: In support... To: Pourne@mit-mc cc: Seiler@MIT-XX.ARPA, Info-CPM@BRL.ARPA In-Reply-To: Message from "Larry Seiler <Seiler@MIT-XX.ARPA>" of Sat 18 Feb 84 16:39:08-EST Oh brother... Jerry, I was able to duplicate the silly bug in Turbo. And IT IS a bug - It DOES NOT do what the book says it ought to do, despite what all the mathematicians say. On the other hand, just for kicks I tried defining my own frac function and THAT worked per the manual description. What I used was the expansion they give in the book for frac on page 131. What a pain - why didn't Borland do it that way to begin with? I wonder what Borland's update policy is? I remember asking them about that when I ordered the compiler. Never did get a reply. Well, as they say, caveat emptor... Mark ------- 20-Feb-84 10:18:47-MST,1507;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 10:18:42-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 20 Feb 84 11:56 EST Received: From Ut-Ngp.ARPA by BRL via smtp; 19 Feb 84 14:44 EST From: mknox@ut-ngp.ARPA Posted-Date: Sun, 19 Feb 84 13:36:43 CST Message-Id: <8402191946.AA21195@ut-ngp.ARPA> Received: by ut-ngp.ARPA (4.22/3.14) id AA21195; Sun, 19 Feb 84 13:46:13 cst Date: Sun, 19 Feb 84 13:36:43 CST To: info-cpm@brl.ARPA Subject: SELDSK bug in CP/M-86 I just encountered a rather interesting bug in the IBM-PC BIOS implementation of CP/M-86 (found it the hard way, of course). Perform a SELDSK BIOS call (BIOS call number 9) to a disk (it doesn't matter what one), specifying that it is a 'new disk'. It will work correctly. Without doing any disk READ or WRITE functions, now do another SELDSK call for the same disk (again specifying that it is a 'new disk'). The DISK parameter block returned will UNCONDITIONALLY specify that the disk is SINGLE DENSITY!!! ----- Why would anyone do two disk selects in a row to the same drive? One case is an application program that selects a disk upon startup, and is then instructed by the user to 'log in a new diskette in that drive'. Since the density and allocation map may have changed a fresh SELDSK is necessary. Curiously, any read/write between the SELDSK function fixes the problem. Other BIOS calls do not. 20-Feb-84 10:22:22-MST,1052;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 10:22:17-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 20 Feb 84 11:56 EST Received: From Mit-Mc.ARPA by BRL via smtp; 20 Feb 84 3:33 EST Date: 20 February 1984 03:33 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: In support... To: CENT.MBECK%mit-oz@BRL.ARPA cc: Seiler@mit-xx, Info-CPM@brl In-reply-to: Msg of Sat 18 Feb 84 22:50:48-EST from Mark Becker <CENT.MBECK%MIT-OZ at MIT-MC.ARPA> It's still a prety good compiler (and they are rescinding their "extra hundred" for unlimit ed license so the price is right.) Try writing Borland, ATTN: PHILLIPPE KAHN, describe what you said to me, and put CC:J. E. Pournelle BYTE on the letter (and do send me a cc). I suspect they will (1) tellyou about update policies, and (2) at least discuss the "feature" (bug?) with youy. Then tell me what happened, because I get conflicting stories, and I am tired of having my jugular chewed over this issue. jep 20-Feb-84 10:22:36-MST,655;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 10:22:33-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 20 Feb 84 11:56 EST Received: From Usc-Isid.ARPA by BRL via smtp; 19 Feb 84 20:04 EST Date: 19 Feb 1984 17:00-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: WHERE IS DUPUSR? From: ABN.ISCAMS@usc-isid To: DGILBERT.ES@parc-maxc Cc: INFO-CPM@brl Message-ID: <[USC-ISID]19-Feb-84 17:00:56.ABN.ISCAMS> In-Reply-To: The message of 18 Feb 84 17:55:43 PST from DGILBERT.ES@PARC-MAXC.ARPA Also via FTP from SIMTEL20 MICRO:<CPM.DIRUTL>DUPUSR2.ASM.1 David Kirschbaum Toad Hall 20-Feb-84 11:03:25-MST,1819;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 11:03:17-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 20 Feb 84 11:56 EST Received: From Mit-Mc.ARPA by BRL via smtp; 20 Feb 84 8:16 EST Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 20-Feb-1984 07:52:45-est Date: Sat, 18 Feb 84 14:11 MST From: Kevin Kenny <Kenny%his-phoenix-multics.arpa@BRL.ARPA> Subject: Re: Turbo Pascal--first impressions Reply-To: Kenny%PCO@CISL-SERVICE-MULTICS.ARPA To: "Jerry E. Pournelle" <POURNE@MIT-MC.ARPA> cc: INFO-CPM@MIT-MC.ARPA In-Reply-To: Message of 18 Feb 84 03:06 MST from "Jerry E. Pournelle" Message-ID: <840218211139.394998@HIS-PHOENIX-MULTICS.ARPA> My apologies for flaming; my last message was written fairly late on a very bad day. I, too, am primarily interested in getting the job done, which involves selecting the right tool to do it. For doing taxes or balancing bank accounts I'd use scaled fixed-point arithmetic, which gets the pennies right, and not worry about whether it's decimal or binary internally. Funny, do you suppose that's why COBOL was designed that way? For engineering work, I want floating point sometimes (although the more you use it, the less you trust it), and (by preference, not necessity) binary arithmetic. On nearly all machines, binary is faster; the analysis of computation errors is easier, too. For systems programming, I don't give a damn, since it's non-numeric anyway. A language trying to serve every application's needs can't do them all right without falling into the trap of gigantism (_vide_ PL\1). I think Turbo has made the right decision, though I recognize that I'm personally biased toward engineering and away from finance. 20-Feb-84 11:04:58-MST,810;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 20 Feb 84 11:04:54-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 20 Feb 84 11:57 EST Received: From Utexas-20.ARPA by BRL via smtp; 20 Feb 84 10:43 EST Date: Mon 20 Feb 84 09:44:33-CST From: Aaron Temin <CS.Temin@UTEXAS-20.ARPA> Subject: dysan head alignment program/disk To: info-cpm@BRL.ARPA I recall there being a program in the CPM directories from Dysan that is reputed to aid in aligning disk drive heads. I FTP'ed to Simtel-20, but it was being very uncooperative about allowing me to peruse the directories. Could someone give me a full pathname to the file (I think its root name is DDD)? Also, has anyone actually used the program successfully? Thanks, -aaron ------- 21-Feb-84 09:41:05-MST,1281;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 09:40:55-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 20 Feb 84 18:37 EST Received: From Usc-Isid.ARPA by BRL via smtp; 20 Feb 84 18:26 EST Date: 20 Feb 1984 13:47-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: dysan head alignment program/disk From: ABN.ISCAMS@usc-isid To: CS.Temin@utexas-20 Cc: info-cpm@brl Message-ID: <[USC-ISID]20-Feb-84 13:47:26.ABN.ISCAMS> In-Reply-To: The message of Mon 20 Feb 84 09:44:33-CST from Aaron Temin <CS.Temin@UTEXAS-20.ARPA> Aaron (et al) Pathname to the Dysan DDD program for disk drive head alignment: (FTP from SIMTEL20, ANONYMOUS login, of course) MICRO:<CPM.DSKUTL>DDD.ASM.1 DDD.DOC.1 DDD1.ASM.1 Nope, haven't used it myself (don't have the special Dysan disk). Incidentally, if you want to see a directory (a SINGLE directory), DIR MICRO:<CPM.directoryname><ESC><ESC> works pretty good -- IF you know the directory name. Else...you gotta download (or set up the FTP transfer to 7 bit ASCII so you can send it to TTY:) MICRO:<CPM>CPM.CRCLST.nn You can get the latest CPM.CRCLST by DIR MICRO:<CPM><ESC><ESC>. Regards, David Kirschbaum Toad Hall 21-Feb-84 09:41:18-MST,1301;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 09:41:10-MST Received: From Sri-Kl.ARPA by AMSAA via smtp; 20 Feb 84 21:46 EST Date: 20 Feb 1984 18:45-PST Sender: BILLW@sri-kl Subject: Re: dysan head alignment program/disk From: BILLW@sri-kl To: towson@amsaa Cc: ABN.ISCAMS@usc-isid, info-cpm@amsaa Message-ID: <[SRI-KL]20-Feb-84 18:45:05.BILLW> In-Reply-To: The message of Mon, 20 Feb 84 21:17:12 EST from David Towson (CSD) <towson@amsaa> Yes, it depends on the FTP user program. The TOPS20 ftp server defaults unspecified parts of the filename to *, so just a DIR FILENAME will actually find FILENAME.*. By the way, the tops20 filename format is <directory>filename.extension.version, its only a sometime used cpm convention that the extension contain the program version number. directory, filename, and extension can all be up to 39 characters long, and version is a number less than some large decimal number. The tops20 FTP code also contains a check so that an wildcard directorys cannot be used (presumably, this is to prevent people from using large amounts of CPU time doing a directory of the entire file system). Perhaps this restriction should be removed from the SIMTEL system ? BillW 21-Feb-84 09:41:26-MST,696;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 09:41:22-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 20 Feb 84 22:18 EST Received: From Sri-Kl.ARPA by BRL via smtp; 20 Feb 84 21:50 EST Date: 20 Feb 1984 18:47-PST Sender: BILLW@sri-kl From: William "Chops" Westfield <BillW@sri-kl> To: info-micro@brl, info-cpm@brl Message-ID: <[SRI-KL]20-Feb-84 18:47:53.BILLW> SRI-UNIX, which is the gateway to usenet for INFO-MICRO and INFO-CPM (amoung other mailing lists), has a broken IMP11 interface, and so no net.micro* netnews will be gatewayed to the arpanet until we manage to find spare parts someplace... BillW 21-Feb-84 09:42:31-MST,1067;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 09:42:25-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 21 Feb 84 8:31 EST Received: From Dca-Ems.ARPA by BRL via smtp; 21 Feb 84 8:05 EST Date: 21 Feb 1984 7:57:50 EST (Tuesday) From: Maj Bower (HQ USEUCOM) <bower@dca-ems> Subject: disk drive/controller problem To: info-cpm@brl Cc: byard@dca-ems Has anyone successfully interfaced the Compu/time UFDC-1 controller (which may be the same as QT Systems) with the Siemens Fdd-221-5 80 track double-sided drive? I have two such drives which work with the Versafloppy II and Jade Double-D, but will do NOTHING on the UFDC-1. Various things such as adjusting terminating resistor packs have had no effect. The only difference I have been able to find is that the UFDC-1 uses a special data seperator chip where others use op-amp based designs. Losing the use of a 784K drive on my portable system is painful. Can anyone help? Hal Bower Bower at DCA-EMS 21-Feb-84 09:43:29-MST,660;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 09:43:25-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 21 Feb 84 8:54 EST Date: Tue, 21 Feb 84 8:31:05 EST From: Keith Petersen <w8sdz@brl> To: Aaron Temin <CS.Temin@utexas-20.arpa> cc: Info-Cpm@brl Subject: Re: dysan head alignment program/disk Try MICRO:<CPM.DSKUTL> as the directory on SIMTEL20. You'll find the original generic DDD.ASM and a new one DDD1.ASM which I believe is for a CCS disk controller. You'll find DDDTAR.LBR on TCBBS Dearborn, MI (313) 846-6127, which is for the Tarbel controller. 21-Feb-84 09:43:34-MST,921;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 09:43:28-MST Date: Mon, 20 Feb 84 21:17:12 EST From: David Towson (CSD) <towson@amsaa> To: ABN.ISCAMS@usc-isid cc: info-cpm@amsaa Subject: Re: dysan head alignment program/disk David - A couple things in your note concerning the whereabouts of the Dysan DDD program caught my eye: What are the escapes in the FTP sequences for ? Our UNIX FTP doesn't use them. Our syntax is: ftp "micro:<cpm.dirname>filename" local_filename The quotes are there to keep UNIX happy, since the < and > characters are special in UNIX. Second, I don't think you need to append the version number to the filename (as in filename.nn). I have never been refused by a TOPS-20 system, and I have never used the version number. Have you had difficulties if you didn't use it ? Dave 21-Feb-84 09:44:00-MST,682;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 09:43:56-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 21 Feb 84 9:14 EST Received: From Mit-Mc.ARPA by BRL via smtp; 21 Feb 84 8:51 EST Date: 21 February 1984 08:52-EST From: Keith Petersen <W8SDZ@mit-mc> Subject: SIMTEL20 CP/M directory list To: EJS@mit-mc cc: Info-Cpm@brl In-reply-to: Msg of 20 Feb 1984 14:15-EST from Eric J. Swenson <EJS> A complete list of all directories containg CP/M files on SIMTEL20 is available on MIT-MC as ARMTE;CPM DIRLST. This is a copy of MICRO:<CPM>CPM.CRCLST from SIMTEL20 and is updated frequently. --Keith 21-Feb-84 18:10:36-MST,768;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 21 Feb 84 18:10:31-MST Date: Tue, 21 Feb 84 19:56:40 EST From: David Towson (CSD) <towson@amsaa> To: Earnie Boyd DRSTE-CM-F 4377 <eboyd@apg-1> cc: info-cpm@amsaa Subject: Quotes around filenames in FTP command lines. Ernie - Thanks for your note saying that quotes are not needed around filenames in FTP command lines sent from UNIX unless there is a SPACE in the filename. Sure enough; I tried it without the quotes and it worked fine on Simtel20. You are also right about where I got into the habit of using quotes. I got it from FTPing from Mit-mc, which does have two-part filenames with the parts separated by a space. Dave 22-Feb-84 10:24:03-MST,1117;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:23:43-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 21 Feb 84 21:12 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 21 Feb 84 21:07 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 20 Feb 84 0:10-PST Date: 19 Feb 84 6:03:12-PST (Sun) To: info-cpm@brl From: decvax!decwrl!lipman@ucb-vax Subject: id AA04376; Sun, 19 Feb 84 06:02:59 pst Article-I.D.: decwrl.5690 Message-Id: <8402191402.AA04376@decwrl.uucp> Date: Sunday, 19 Feb 1984 06:05:21-PST From: dosadi::binder (Wanted: A good five-cent nickel) To: net.micro.apple, net.micro.cpm, net.micro, applenet, cpmnet, micronet Subject: Want KERMIT Is anyone out there willing to provide copies of KERMIT-65 for the Apple ][ and KERMIT-80 for Apple ][ CP/M on disk? I will happily pay your costs for the disks and mailing. I already have the documentation. Please contact me directly by netmail or telephone. Thanks. - Dick Binder decvax!decwrl!rhea!dosadi!binder (617) 486-6363 (0815-1700 weekdays) 22-Feb-84 10:24:07-MST,1634;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:23:49-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 22 Feb 84 1:21 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 22 Feb 84 1:11 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 17 Feb 84 4:19-PST Date: 15 Feb 84 12:44:40-PST (Wed) To: info-cpm@brl From: decvax!genrad!rick@ucb-vax Subject: cpm 2.2 bios Article-I.D.: genrad.3855 Has anyone every successfully modified their bios to handle xon/xoff protocol for the console in a non-interrupt polled system. This would probably require some sort of buffer arrangement, but characters would only be noticed if some program or the ccp was polling the status port. I am also interested in handling a terminal (vt100) where the special function keys send out three characters one after the other. This is particularly nasty when using them for an editor as characters are often lost. right now, i have my cns$ot routine sending out 10 nulls when it detects a line feed so that the terminal has time to scroll. ( i have another terminal which also requires this because of the xon/xoff problem). I have an S-100 system built with assorted boards (including Ithaca Audio z80 board and Jade Double D Disk Controller. Am I going to have to add an interrupt controller to resolve the above mentioned problems? I forgot to mention that this is for cp/m version 2.2 I would very much appreciate any information that anyone has. Thank you, Rick Frerichs uucp: decvax!genrad!rick tel: 617-779-2811 x6435 22-Feb-84 10:24:33-MST,1515;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:24:08-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 22 Feb 84 5:30 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 22 Feb 84 5:23 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 22 Feb 84 0:25-PST Date: 20 Feb 84 7:05:11-PST (Mon) To: info-cpm@brl From: harpo!ulysses!burl!clyde!akgua!mcnc!ecsvax!emigh@ucb-vax Subject: Re: WordStar with ZCPR2 Article-I.D.: ecsvax.2034 In-Reply-To: Article sri-arpa.16735 [] There are two other ways to fix this: 1) WSUFIX5.ASM: This is a patch to WS.COM and WSOVLY1.OVR that will have WordStar search a default user area for COM and OVR files. Therefore, you need only one copy of the WS files (thereby saving you directory entries). 2) SUPUSER.COM: This program resides just below the BDOS and has a list of files and where (drive/user) they are to be found. The program must be initialized for a particular set, and for many programs it can be integrated into the COM file (not WordStar, however). For WordStar, I prefer to use WSUFIX5, since it merely changes the user area, and does not defeat the drive searching feature of WordStar (look on default, then on A: (or wherever)). I have several copies of WS.COM in my DU areas, each configured for a different application. I use SUPUSER for most other programs with overlays, etc. --Ted Emigh-- decvax!mcnc!ecsvax!emigh 22-Feb-84 10:24:39-MST,664;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:24:24-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 22 Feb 84 5:30 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 22 Feb 84 5:27 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 22 Feb 84 0:38-PST Date: 20 Feb 84 7:53:43-PST (Mon) To: info-cpm@brl From: harpo!ulysses!burl!clyde!akgua!mcnc!ecsvax!emigh@ucb-vax Subject: Re: WordStar with ZCPR2 Article-I.D.: ecsvax.2036 In-Reply-To: Article ecsvax.2034 sri-arpa.16735 [] Please replace all SUPUSER with SETDRU. Sorry. --Ted Emigh-- decvax!mcnc!ecsvax!emigh 22-Feb-84 10:24:53-MST,1057;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:24:33-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 22 Feb 84 6:06 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 22 Feb 84 5:59 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 18 Feb 84 5:44-PST Date: 16 Feb 84 13:54:51-PST (Thu) To: info-cpm@brl From: ihnp4!ihuxf!vej@ucb-vax Subject: Blow out deal on Verbatim head cleaning kits Article-I.D.: ihuxf.2027 I have a few brand new Verbatim 8 inch disk head cleaning kits and am willing to let them go at ANY reasonable price. These babys were selling for $11.95 from Verbatim. I bought these with a group purchase of some equipment and I am willing to make a deal to clear them out. First come first serve so call or write soon. NO REASONABLE OFFER REFUSED!! work phone: 312-979-2890 home phone: 312-961-1207 or send mail to ihuxf!vej Dwight Yackley office 6L313 x2890 AT&T Bell Labratories Naperville, Illinois 22-Feb-84 10:25:03-MST,1337;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:24:46-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 22 Feb 84 6:07 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 22 Feb 84 6:01 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 18 Feb 84 5:57-PST Date: 16 Feb 84 7:05:03-PST (Thu) To: info-cpm@brl From: harpo!ulysses!burl!clyde!akgua!itm!danny@ucb-vax Subject: Need info on uc.c transfer stuff Article-I.D.: itm.1055 [What brings you here?] <-- Virtual Line. Well "Push has come to shove", "The time is now", and "Jean Kirkpatrick is nobody's baby." Anyway, I now have great need to transfer [stdout/file] to (specifically) a Xerox 820 II (which runs CP/[yuk]M) printer. Seemingly, I have 1/2 of the interface: uc.c which was posted/mailed about 2 weeks ago. Well, I didn't receive the man page, or any other documentation with it. So: *Anything* *anyone* has will be appreciated. Like, what do I need on the CP/M side? UMODEM? Naked CP/M? Any experiences, opinions, or sources would be appreciated. (From the heart) Thanks in advance... Expectingly, Danny akgua!itm!danny 22-Feb-84 10:25:24-MST,1384;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:25:03-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 22 Feb 84 6:20 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 22 Feb 84 6:09 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 18 Feb 84 10:57-PST Date: 17 Feb 84 6:23:31-PST (Fri) To: info-cpm@brl From: ihnp4!ihlts!w9skd@ucb-vax Subject: RBBS Message Transfer Article-I.D.: ihlts.366 I have heard rumors of CP/M RBBS late nite, automatic message exchange networks (like UUCP?). I am interested in using this technique to exchange mail between my Packet Radio RBBS and other packet LAN's. If anyone has any information on protocols, people doing this, please let me know. If such systems don't exist, I have a draft for an inter-lan message protocol and would be interested in sharing my ideas. Comment in passing. I have modified BYE.ASM into several versions. One allows access from a normal VHF-FM Amateur RTTY station, and the other from a Amateur Packet Radio station though my TNC. I am currently using RBBS.BAS for the bulletin board, but am in the process of writing a system that is specially tailored to Amateur Packet Radio (using ideas stolen from Frank Wancho's RBBS4.C). -- +++++ F. R. "Dick" George ihnp4!ihlts!w9skd 312/979-4390 22-Feb-84 10:25:33-MST,941;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:25:21-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 22 Feb 84 6:32 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 22 Feb 84 6:21 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 19 Feb 84 6:39-PST Date: 18 Feb 84 6:31:03-PST (Sat) To: info-cpm@brl From: decvax!decwrl!lipman@ucb-vax Subject: id AA26208; Sat, 18 Feb 84 06:30:53 pst Article-I.D.: decwrl.5681 Message-Id: <8402181430.AA26208@decwrl.uucp> Date: Saturday, 18 Feb 1984 06:31:31-PST From: dosadi::binder (Wanted: A good five-cent nickel) To: net.micro.cpm, cpmnet Subject: Apple CP/M question Does anybody know how I can tell my Apple Microsoft CP/M V2.23 that the disks connected are 40-track drives? I'd like to get that extra 20KB of storage... Thanks in advance. - Dick Binder decvax!decwrl!rhea!dosadi!binder 22-Feb-84 10:25:55-MST,5223;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:25:34-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 22 Feb 84 7:30 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 22 Feb 84 7:23 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 22 Feb 84 3:25-PST Date: 21 Feb 84 3:25:06-PST (Tue) To: info-cpm@brl From: decvax!vortex!lauren@ucb-vax Subject: Cure for Vadic Triple Modem Problem Article-I.D.: vortex.262 Reposting due to failure of SRI-UNIX gateway... --- 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-- 22-Feb-84 10:26:07-MST,1685;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:26:00-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 22 Feb 84 7:31 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 22 Feb 84 7:25 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 22 Feb 84 4:13-PST Date: 21 Feb 84 9:00:44-PST (Tue) To: info-cpm@brl From: ihnp4!ihuxx!ignatz@ucb-vax Subject: Re: Turbo Pascal Article-I.D.: ihuxx.677 In-Reply-To: Article <16676@sri-arpa.UUCP> 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. Excuse me, but I *thoroughly* agree with Jerry's complaints about the $100 fee. A compiler or interpreter is a tool. If I can't use it as one without forking over extra money to the providers of the tool, it's totuse such a tool for production work. (Never mind that I wouldn't produce a marketable product in PASCAL in the first place...) And often such a charge is added on a per-unit distribution basis! I refuse to encourage practices in any way whatsoever, and I encourage others to do likewise. Dave Ihnat ihuxx!ignatz 22-Feb-84 10:31:54-MST,1691;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 10:31:40-MST Received: From Rochester.ARPA by AMSAA via smtp; 22 Feb 84 11:25 EST Received: by sen.rochester (3.327.3N) id AA01174; 22 Feb 84 11:24:45 EST (Wed) Received: by cay.Rochester (3.327.3N+) id AA00479; 22 Feb 84 11:22:21 EST (Wed) Message-Id: <8402221624.1174@sen.rochester> Date: 22 Feb 84 11:24:45 EST (Wed) From: Mike Ciaraldi <ciaraldi@Rochester.ARPA> Subject: Uc.c To: info-cpm@amsaa.ARPA I have been using umodem.c (version 3.6) for Unix to CP/M file transfers, and wanted to upgrade to uc.c, since it has CRC checksumming. I fetched it from SIMTEL, and it compiled OK, but when I run it I immediately get a segmentation fault, before it even prints the sing-on message (the printf is the FIRST executable statement!). I contacted Rick Conn and he said he wrote this for System V. We are running BSD 4.1c (soon to convert to 4.2). For comparison, umodem has conditional-compile flags for JHU (Johns Hopkins), VER7 (Version 7, also good for Berkeley), and SYS3 (for System III, and V also, I suppose). Does anyone know how to fix up uc.c? The differences on umodem have to do with how you tell the system to kill echo, go to 8-bit transmission, etc. But all these calls are after the printf, so why don't we even see the sign-on message? (last-minute thought: maybe the output buffer is not getting flushed). I suppose I could hack up uc.c and put in the same things umodem has, but if someone else has already done it, I would appreciate a copy. Also, it should be added to the archives. Mike Ciaraldi ciaraldi@rochester 22-Feb-84 11:33:23-MST,1740;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 22 Feb 84 11:33:16-MST Received: From Brl-Voc.ARPA by AMSAA via smtp; 22 Feb 84 13:16 EST Date: Wed, 22 Feb 84 13:01:03 EST From: "Ferd Brundick (LTTB)" <fsbrn@brl-voc> To: Mike Ciaraldi <ciaraldi@rochester.arpa> cc: info-cpm@amsaa.arpa Subject: Re: Uc.c Haaah, Out of curiosity, I grabbed a copy of uc.c and tried to compile it under 4.2 bsd. So far, so good. Then I executed it and got the help screen. I executed it a second time with the '-z' option and played around with the menu (I'm a umodem user and have never used uc before). Everything worked fine except for the 'd' command. It tried to execute the system command 'dir' which we don't have; I renamed it 'ls -l', recompiled, and now 'd' works the way it should. I couldn't test the file transfer commands because my micro is at home (and doesn't work thru the TAC anyway). The bottom line is that everything looks ok to me. Did you try a simple test like this, or were you only attempting file transfers ?? PS. I also applaud umodem.c for checking for various OS flags, but I spent my entire lunch break recently trying to get it to compile under 4.2. I had to try every flag because there was not an entry for it. If there is a help file available -- not how to USE the program, but how to COMPILE it -- I would appreciate a pointer to it. If there isn't, I think one should be written. dsw, fferd Fred S. Brundick USABRL, APG, MD. <fsbrn@brl-voc> 23-Feb-84 08:08:29-MST,963;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 23 Feb 84 08:08:22-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 22 Feb 84 22:06 EST Date: Wed, 22 Feb 84 22:03:13 EST From: Bob Bloom (TECOM) <bbloom@brl> To: info-cpm@brl Subject: A fast(er) W* 3.3 start-up According to a Robert P. Van Natta in January's "The Software Magazine" (just received today - but no comment needed on that!) in a article one can speed up the start-up by ddt patches: 02b2 - 40 --> 00 3f1d - 20 --> 00 411f - A0 --> 00 The first is the old "DEL4" patch point for lenght of logo display. The other two "will suppress the display of the trade secret notice and logo respectively" One should only do this to purchased, legal copiesW*. ;-) I've tried it and it seems to work. Something is still thrown to the screen but too rapidly to read. (Good 'nough for gov'ment work.) -bob bloom 23-Feb-84 08:18:08-MST,1245;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 23 Feb 84 08:17:58-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 23 Feb 84 4:52 EST Received: From Mit-Mc.ARPA by BRL via smtp; 23 Feb 84 4:47 EST Date: 23 February 1984 04:47-EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: Turbo Pascal To: ihnp4!ihuxx!ignatz@ucb-vax cc: info-cpm@brl In-reply-to: Msg of 21 Feb 84 9:00:44-PST (Tue) from ihnp4!ihuxx!ignatz at ucb-vax 1. Relax. Borland has dropped the "extra charge" for licensing fees. 2. I doubt you actually read what I said, since you ask questions that were answered in the article itself. 3. SORCIM didn't encourage (allow) distribution of PRUN because they didn't want to support it and all the programs that would be written in it; and indeed, they have ceased to sell PASCAL/M entirely, which is a pity, since it was a good teaching language; but they decline to support it. I gather there are some negotiations between Workman and SORCIM that might lead to Workman becoming a source of Pascal/M; but no details. I never heard of a case where SORCIM tried to STOP anyone from distributing PRUN; but they sure wouldn't explictly allow it. 23-Feb-84 08:24:58-MST,1784;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 23 Feb 84 08:24:51-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 23 Feb 84 9:58 EST Received: From Radc-Tops20.ARPA by BRL via smtp; 23 Feb 84 9:46 EST Date: Thu 23 Feb 84 09:45:23-EST From: Gern <GUBBINS@RADC-TOPS20.ARPA> Subject: Mailing List Submit Kickbacks and Control To: INFO-MICRO@BRL.ARPA, INFO-CPM@BRL.ARPA As anyone who has sent a message to this (or any) mailing list knows, bad addresses of persons on the list get kicked back to the sender. This gives the submitter a bunch of rejected mail from persons he has never heard of. There is nothing the maintainer of the list can do to find the bad addresses, except send a test message thru and hack off the rejected kickbacks. Requests for addition to this list is rather good, and many hosts I have never heard from (but work okay). Some sites re-redistribute this list, so that kickback problems may not be related to this master list, but several systems deep somewhere. The first thing I checked into when I got the mailing list to redistribute was this problem, and it goes beyond the scope of control of this system as the rejected messages are sent back to the submitter from the problem site, not back here first. Yesterday, I hacked off 2 more problem addresses, one never gave any trouble before and the other from a new person that had a stable address. The point is, unless I submit something and get the kickbacks, or persons are kind enough to flag me as to the problem addresses, I have no way to find out the problems. If someone knows a way to control and/or monitor this, please flag me. Thanx Gern INFO-HZ100@RADC-TOPS20 Coordinator ------- ------- 23-Feb-84 11:55:10-MST,1288;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 23 Feb 84 11:55:05-MST Received: From Nrl-Aic.ARPA by AMSAA via smtp; 23 Feb 84 13:38 EST Date: 23 Feb 1984 13:12-EST From: Russ Smith <smith@nrl-aic> Subject: THE modem program To: info-cpm@amsaa Message-Id: <84/02/23 1312.533@NRL-AIC> I was just looking over the most recent simtel20 CPM CRCLST copy and noticed that the infamous MDM7** series is up to 724! Good grief!! Is this the ballyhooed (sp?) version that was to replace Irv Hoff's or is this something else? When were the other versions (briefly) put on the system? Is there any reason for someone who seldom uses home remote file transfer to give up on version 712 or so and update to 724 (or is it 725 by now (726?))? If this isn't the new radically altered MDM program will one of these soon be? Pardon the questions but the last reference I remember anyone making to the net specifically about the MDM stuff mentioned that version 720 would be completely different and better (in some way or other) than the stuff originally done by half a dozen people, Irv Hoff in particular. I was rather surprised to see what appeared to be a continuation rather than a jump in the series. Russ <Smith@nrl-aic> 23-Feb-84 13:58:16-MST,998;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 23 Feb 84 13:58:11-MST Date: Thu, 23 Feb 84 15:32:53 EST From: David Towson (CSD) <towson@amsaa> To: Russ Smith <smith@nrl-aic> cc: info-cpm@amsaa Subject: Re: THE modem program Russ - The 724 version of MDM was contributed by Irv Hoff. If you FTP the file "micro:<cpm.modem7>mdm724.msg" you can read a brief version of the update history. No, this is not the promised "super version". That is being done by Ron Fowler. In my opinion, there is no reason for you to switch from MDM712 unless you can benefit from the particular enhancements that have been added since that version. These deal mainly with autodial applications, but there is also a change in the way memory is allocated to receiving buffers. Some folks were having trouble with the 16K file-transfer buffer taking too long to be written to disk, and they needed a smaller buffer. Dave 23-Feb-84 16:47:26-MST,772;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 23 Feb 84 16:47:22-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 23 Feb 84 18:25 EST Received: From Brl-Bmd.ARPA by BRL via smtp; 23 Feb 84 18:23 EST Date: Thu, 23 Feb 84 18:15:57 EST From: Charlie Strom (NYU) <strom@brl-bmd> To: hplabs!hao!kpno!amd70!phil@ucb-vax cc: INFO-CPM@brl Subject: Desoldering techniques Ypu brought up a pet subject of mine - namely the best technique to use to remove IC's from pc boards. I have tried a large number of alternatives and have finally decided that a heated iron with a vacuum source is the best tool for such purposes, but I'm always open to suggestions and new ideas. Any comments? 24-Feb-84 08:08:00-MST,717;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 24 Feb 84 08:07:42-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 24 Feb 84 6:06 EST Received: From Mit-Mc.ARPA by BRL via smtp; 24 Feb 84 5:59 EST Date: 24 February 1984 05:59-EST From: Paul R. Grupp <GRUPP@mit-mc> Subject: Desoldering techniques To: strom@brl-bmd cc: INFO-CPM@mit-mc In-reply-to: Msg of Thu 23 Feb 84 18:15:57 EST from Charlie Strom (NYU) <strom at brl-bmd> I've always found it easier to cut the IC leads one at a time, *THEN* desolder the "stubs". (You wern't planning on putting it back I hope!) An even better way is not to buy boards that don't use sockets. --Paul 24-Feb-84 10:19:45-MST,1253;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 24 Feb 84 10:19:40-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 24 Feb 84 12:02 EST Received: From Mit-Mc.ARPA by BRL via smtp; 24 Feb 84 11:53 EST Date: Fri 24 Feb 84 08:43:12-PST From: Bud Spurgeon <SPURGEON@SUMEX-AIM.ARPA> Subject: Re: Desoldering techniques To: GRUPP@MIT-MC.ARPA cc: strom@BRL-BMD.ARPA, INFO-CPM@MIT-MC.ARPA In-Reply-To: Message from "Paul R. Grupp <GRUPP@mit-mc>" of Fri 24 Feb 84 02:59:00-PST I've found that for something you can carry in your toolbox, a hand-held "solder sucker" used along with a soldering iron works about the best. Carry along some of the "solder braid" stuff for really hard to unsolder items, and maybe a higher temperature tip for your soldering iron to convince the braid to work (the heavier braid really soaks up the heat). For bench use I've found the vacuum pump based machine, specifically those models made by Pace to be better (faster,cleaner,leaves re-usable holes and trace) than anything else. You must fiddle with this equipment more though. It works best only when kept really clean, with clean filters and tips. Then it works real well. -Bud ------- 24-Feb-84 16:03:09-MST,621;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 24 Feb 84 16:03:03-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 24 Feb 84 17:42 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 24 Feb 84 17:31 EST Date: Fri, 24 Feb 84 17:29 EST From: Slade.wbst@PARC-MAXC.ARPA Subject: BDS C & DEC VT180 To: info-cpm@brl.arpa cc: Slade.wbst@PARC-MAXC.ARPA I am porting a BDS C program onto a DEC VT180. Could anyone supply the proper parameters that should be set in the hardware.h file and should anything be changed in bdscio.h? Thank you- Mike Slade 24-Feb-84 18:24:31-MST,657;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 24 Feb 84 18:24:26-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 24 Feb 84 20:04 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 24 Feb 84 19:56 EST Date: Fri, 24 Feb 84 16:54 PST From: MMOON.ES@PARC-MAXC.ARPA Subject: Re: cpm 2.2 bios In-reply-to: "decvax!genrad!rick@ucb-vax.ARPA's message of 15 Feb 84 12:44:40 PST (Wed)" To: decvax!genrad!rick@ucb-vax.ARPA cc: info-cpm@brl.ARPA Message me if you get any ratiional suggestions; L50 can be used to good effect in xon/xoff mode if the 'frame speaks the same. MMoon.es 27-Feb-84 08:16:58-MST,652;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 08:16:49-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 26 Feb 84 16:54 EST Received: From Mit-Mc.ARPA by BRL via smtp; 26 Feb 84 16:48 EST Date: Sun 26 Feb 84 16:47:32-EST From: Clifford A. Lasser <CAL%MIT-OZ@MIT-MC.ARPA> Subject: lost program To: INFO-CPM%MIT-OZ@MIT-MC.ARPA I recently managed to loose all my copies of SID. I originally purchased SID from Lifeboat, but since that was such a long time ago, they will only sell me a new copy at the full price. Is there anything I can do about this? -Cliff ------- 27-Feb-84 08:17:02-MST,721;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 08:16:58-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 26 Feb 84 18:48 EST Received: From Usc-Isi.ARPA by BRL via smtp; 26 Feb 84 18:42 EST Date: 26 Feb 1984 15:41-PST Sender: SCHNUR@usc-isi Subject: Exon 500 From: SCHNUR@usc-isi To: info-cpm@brl Message-ID: <[USC-ISI]26-Feb-84 15:41:42.SCHNUR> The Division where I work at NRL has just pruchased many Exxon 500 for word processing. Does any body out htere have one? Has any body set them up with Bye and mdm7? Exxon has not yet provided us with port maps etc so any help would be of great use. Joel schnur (6510-NRL) Schnur @isia 27-Feb-84 08:17:10-MST,568;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 08:17:06-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 27 Feb 84 4:09 EST Received: From Mit-Mc.ARPA by BRL via smtp; 27 Feb 84 4:08 EST Date: 27 February 1984 04:07-EST From: Frank J. Wancho <FJW@mit-mc> Subject: RBBS 4.0 Edit 21 Available To: INFO-CPM@brl RBBS421.LBR is temporarily available on MC:FJW;RBBS 421LBR. The individual files (and this .LBR) will be available on the SIMTEL20 in MICRO:<CPM.RBBS4> later today. --Frank 27-Feb-84 08:31:48-MST,4316;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 08:31:32-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 24 Feb 84 22:53 EST Date: Fri, 24 Feb 84 22:43:22 EST From: Keith Petersen <w8sdz@brl> To: Russ Smith <smith@nrl-aic> cc: Info-Cpm@brl Subject: Re: MDM724 update Ron Fowler has not released his program. It will have a different name, more features and be easier to configure. I have uploaded MDM724, the latest version in the MDM7xx series, to SIMTEL20 (and also temporarily available on MIT-MC in directory AR100:FJW; ). You asked what was new... here's the information. I see no reason to get upset when people update a program to make it better, if you chose to stay with an older version, that's your decision. I like the new features. --- TOPIC: MDM724.ASM MODEM PROGRAM FROM : IRV HOFF W6FFC DATE : 17 FEB 84 NOTE: This program when assembled is 72 sectors long. Use this figure when merging the appropriate overlay file for your computer via DDT, etc. (Most of the overlays were written when MDM7xx.COM was only 66 sectors and the example included in each says to store 66 sectors.) For MDM724 use: B>SAVE 72 MDM724.COM NOTE: M7LIB.COM is a rapid and surprisingly easy way to quickly change any entries in the phone number library. See M7LIB.DOC if instructions are needed. M7NM-6.ASM is necessary for setting or altering numbers for 'SPRINT', 'MCI', etc. NOTE: If using the phone number overlay to change the phone library numbers, be sure to use: M7NM-6.ASM (Previous versions of M7NM will not work with this new version, as the phone number library now contains 36 numbers (A-Z as usual plus 0-9) rather than the 26 in versions prior to MDM722.) Most users will not need the lengthy (160k) source code at all. Just get MDM724.COM and then check one of the associated over- lay programs to obtain the overlay for your particular computer. Merge that with MDM724.COM according to the instructions near the start of the overlay file, using DDT.COM, etc. (See above note relative to saving 72 sectors. STAT.COM would then show 144 records for 18k.) The following bytes can be changed easily with DDT, then Save 72 0DFEH - HEXSHOW 00 = do not show hex record count FF = show both hex and decimal count 0DFFH - SAVSIZ 20 = 4k file transfer buffer size (see table below for other options) 0E00H - NUMBLIB (start of telephone number library) To change the file transfer buffer size via DDT, change byte 0DFFH: 10 (hex) = 16 records = 2k 20 (hex) = 32 records = 4k 40 (hex) = 64 records = 8K 60 (hex) = 96 records = 12k 80 (hex) = 128 records = 16k - Irv Hoff RECENT CHANGES: -------------- (READ THE UPDATE HISTORY IN MDM723.ASM FOR MORE DETAILED INFORMATION) MDM724 - added 10 function keys for auto-typing preselected messages MDM723 - alphabetizes the phone library vertically for: 'CAL' - used with auto-dial modems including PMMI 'NUM' - used with manually-dialed modems MDM722 - phone number library now has 36 entries rather than 26 (has A-Z as usual plus 0-9). Better supports single-digit result codes for the Anchor Mark XII modem as well as Hayes and USR. MDM721 - makes it easier to abort an auto-dial call with CTL-X. MDM720 - changed from BIOS to BDOS call to run the printer. MDM719 - modest changes, PMMI pulse dialing set faster. MDM718 - now supports the Anchor Mark XII modem. Buffer size for ASCII capture set for 16k. Buffer size for file transfers adjustable from 1 sector to 16k. (Allows for slow floppy disk systems so XMODEM does not show a timeout error.) MDM717 - Log-on now works properly on main frames that echo characters with parity set. CREDITS: ------- MDM724 - Sigi Kluger MDM723 - Irv Hoff with routine developed by Ken Lovett MDM722 - Bill Brehm with routines developed by Fred Viles MDM721 - Bill Brehm MDM720 - Irv Hoff MDM719 - Keith Petersen MDM718 - Irv Hoff with routine developed by Fred Viles MDM717 - Irv Hoff 27-Feb-84 08:31:51-MST,2464;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 08:31:38-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 24 Feb 84 22:53 EST Date: Fri, 24 Feb 84 22:45:02 EST From: Keith Petersen <w8sdz@brl> To: Russ Smith <smith@nrl-aic> cc: Info-Cpm@brl Subject: MDM724 key string info MDM724 update information Sigi Kluger, El Paso TX 02-17-84 Being used to a great non-public modem program with a number of function keys, I decided to add ten function keys to MDM7. Great for things you do most, like DIR *.* $U0AD, or XMODEM S, or you could even save your name in a function key for logon. 1. HOW TO ACCESS (transmit) THE FUNCTION KEYS. You transmit the contents of a function key by typing first the INTERCEPT CHARACTER, then a digit 0..9. The INTERCEPT CHARACTER is a unique control character which tells MDM7 that a function key command follows. The INTERCEPT CHARACTER is set to ^A (CONTROL-A). In the distribution version, the following keys are defined: ^A0 DIR ^A1 DIR *.* $U0AD ^A2 XMODEM S ^A3 XMODEM R ^A4 BYE ^A5 CBBS (Function keys 2 and 3 have no trailing CR). 2. HOW MUCH ROOM? A total of 256 bytes are reserved for the function key definition. Each definition takes up the number of bytes in the string, PLUS 2. Note that you must not enclose any control characters in the definitions (CR is allowed, though, and optional). 3. HOW TO CHANGE THE FUNCTION KEYS In order to not increase the size of MDM7 considerably, I have written the MDMFNK utility. MDMFNK.COM is virtually self-explanatory and covered by its own short DOC file. 4. WHAT WILL NOT WORK Do not attempt to use DDT to modify the function keys. Especially, do not force any control characters into the definitions. There can only be three non-printing characters in each definition, the start byte, an optional CR at the end, and the end byte. 5. DEFINITION FORMAT This is an example of the definition for function key 1: DB 1,'THIS IS A FUNCTION KEY',CR,0 ^ ^ ^ ^ ^ stop character ^ key definition plus CR start character Each key definition string starts with the key number in binary. The function key processor searches for that number. Therefore, those numbers must be unique throughout the key definitions. EMPTY key definitions are encoded thusly: DB 9,0 ;empty function key #9 27-Feb-84 08:32:07-MST,969;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 08:32:01-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 24 Feb 84 23:16 EST Date: Fri, 24 Feb 84 23:07:51 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl Subject: MDM724 file list This is a list of the MDM724 files uploaded to SIMTEL20 and MIT-MC. All .COM files are stored in ITS-binary format on both hosts. On MIT-MC On SIMTEL20 AR100:FJW; MICRO:<CPM.MODEM7> (directory names) M7LIB COM M7LIB.COM (this is version 1.1 on both hosts) M7LIB DOC M7LIB.DOC M7LIB HEX M7LIB.HEX M7NM 6ASM M7NM-6.ASM MDM724 ASM MDM724.ASM MDM724 COM MDM724.COM MDM724 HEX MDM724.HEX MDM724 MSG MDM724.MSG MDM724 UPD MDM724.MSG MDMFNK 11COM MDMFNK11.COM MDMFNK 11HEX MDMFNK11.HEX MDMFNK DOC MDMFNK.DOC --end-- 27-Feb-84 08:32:09-MST,1070;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 08:32:02-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 25 Feb 84 1:26 EST Received: From Mit-Xx.ARPA by BRL via smtp; 25 Feb 84 1:16 EST Date: Sat 25 Feb 84 01:18:06-EST From: Andrew Braunstein <OA.ASB@MIT-XX.ARPA> Subject: Alternate Rainbow printers To: INFO-CPM@BRL.ARPA cc: .@MIT-XX.ARPA According to the Rainbow manual (or what there is of it), the rainbow's printer port should respond to either an XON/XOFF protocol, or a DTR ready signal on pin 6? of the rs232c connector. The rainbow does not seem to respond in any manner to the DTR signal being pulled HIGH or LOW on pin 6 or on pin 20 (where it should be). The owners manual says on the bottom of page 40 that "the printers DTR signal (on pin 6) has a higher priority than XON/XOFF control characters (on pin 3)." If any one knows the fix to this problem, or can help in any other way to make the rainbow respond to a DTR signal, it would appreciate it. ------- 27-Feb-84 09:28:37-MST,960;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 09:28:30-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 27 Feb 84 11:03 EST Received: From Nadc.ARPA by BRL via smtp; 27 Feb 84 10:52 EST Date: 27 Feb 1984 10:49:02-EST From: reece@nadc To: info-cpm@brl Subject: modem7 on Micro Decision I have been trying to get modem7 working on a Morrow Micro-Decision and am having trouble. I was about to give up and out of desperation, tried an older version (711) and it worked! Does anyone know why 711 would work and 720 would not? I have the newest MD3 model with the software setable baud rates and a Centronics port. I made all the setup routines in the overlay file just "return". I use the Morrow-supplied setup program to change the rate and have the modem program assume it's ready to use. I use the same modem720 program on an H89 and it works fine. Jim Reece REECE@NADC 27-Feb-84 14:22:46-MST,825;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 27 Feb 84 14:22:40-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 27 Feb 84 16:01 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 27 Feb 84 15:59 EST Received: from ISL by SUMEX-AIM with Pup; Mon 27 Feb 84 12:58:38-PST Date: Monday, 27 Feb 1984 12:59-PST To: info-cpm@brl Subject: Disk Editor? From: meier%isl@BRL.ARPA Does anyone know of a disk editor available for cpm and the 1791 disk controller chip? The following features are needed: o ability to read a bad sector in order to find out what is wrong or recover as much information as possible o ability to correct a bad sector Please send your response to info-cpm rather than to me personally. Thanks, Bob (isl!meier@shasta) 28-Feb-84 08:10:09-MST,993;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 08:09:54-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 27 Feb 84 21:41 EST Received: From Mit-Mc.ARPA by BRL via smtp; 27 Feb 84 21:39 EST Date: 27 February 1984 21:21-EST From: Eric Stork <STORK@mit-mc> Subject: Problem with MDM720 on MicroDecision To: reece@nadc cc: STORK@mit-mc, info-cpm@brl Your experience with getting MDM711 to work on your machine, but not MDM720, may be related to the overlay. For MDM724 the overlay no longer seems to work beyond the LOGON lable (I got it to work by deleting everything that did not seem to match after examing the first bytes and the overlay with DDT). But I checked the PMMI overlay, which may not be exactly like your MD version. I don;t know if the problem goes back to 720. If you like, I can send you a copy of the overlay that now works for me, so you can examine it. Advise if you want that. Eric 28-Feb-84 08:10:23-MST,2614;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 08:10:09-MST Date: Mon, 27 Feb 84 22:25:29 EST From: David Towson (CSD) <towson@amsaa> To: info-cpm@amsaa Subject: Query to Multics people. Multics people - I have been having an interesting exchange of messages with David Cargo at Hi-Multics concerning the transfer of Simtel20 files stored in ITS binary format (this includes all binary files, and ALL files in the SIGM and CPMUG archives). Apparently, Hi-Multics' FTP doesn't accommodate TENEX mode (which works so nicely for us here on the BRLNET UNIX machines). That has left David in the same awkward position we were in until we were told about TENEX mode, namely, that of having to transfer the files using binary mode, and then post-process them to get rid of the four padding zeros that follow the four 8-bit bytes in each 36-bit ITS binary word. With the aid of a system wizard, David now has a program that is a modified version of a proprietary system copy routine, and which does the necessary post-processing. Using this program, he has successfully transferred ITS binary files from Simtel20. He has then used Keith Petersen's ITSCVT program (available as ITSCVT.HEX on Simtel20 in directory MICRO:<CPM.HEX>) to remove the four ITS "header-bytes". (This is done after the program has been downloaded to a CP/M machine.) So my question to you Multics users is this: What methods are you using to transfer ITS binary files from Simtel20 ? Does anyone have an FTP that will transfer these files and automatically discard the padding bits ? Or is there an FTP option that has not been mentioned here, and which will do the job ? As the maintainer for this list, I get many queries. By far, the most frequent questions deal with the archives and how to FTP. Not being a Multics user, I am very much at a disadvantage in trying to help Multics people, and I would greatly appreciate your assistance in providing me with information. The program David is now using is based on proprietary roots, and cannot, therefore, be freely distributed. He has suggested the possibility of creating a difference file that could be used by legitimate users of the base-program to produce the modified version. Back before we learned about TENEX mode (which solved our problem on the UNIX machines), we too used a post-processor. It was a happy day when we were able to abandon it. Is there a similar happy solution for Multics users ? Dave Towson info-cpm-request@amsaa 28-Feb-84 08:10:33-MST,997;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 08:10:26-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 27 Feb 84 22:57 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 27 Feb 84 22:44 EST From: ssalzman.es@PARC-MAXC.ARPA Date: 27 Feb 84 19:42:50 PST Subject: Re: modem7 on Micro Decision In-reply-to: reece@nadc.ARPA's message of 27 Feb 84 10:49:02 EST To: reece@nadc.ARPA cc: info-cpm@brl.ARPA Hi. A friend of mine has an MD-3 and he's running mdm720 with no problems. You shouldn't change anything in the overlay file at all. Just leave all the port equates and modem setup routines in tack. Run setup and make sure the serial port is set to 1200 baud. From there mdm720 will use a divisor to get down to 300 baud. Any more problems let me know. We are in the process of getting the BYE program running on it too. If you have anything on that let me know. - Isaac Salzman. ssalzman.es@parc-maxc 28-Feb-84 08:10:42-MST,919;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 08:10:36-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 27 Feb 84 23:08 EST Received: From Bnl.ARPA by BRL via smtp; 27 Feb 84 22:57 EST Date: 27-Feb-84 22:00:34-EST From: jalbers@bnl To: STORK@mit-mc, info-cpm@brl, reece@nadc, root@BRL.ARPA To: reece@nadc, root Subject: Re: Problem with MDM720 on MicroDecision Cc: STORK@mit-mc, info-cpm@brl I have discovered the same problem with the Osborne Executive and Osborne 1 overlays. It looks like to overlays at SIMTEL20, or at least not all of them, have been set up for MDM724+. Is MDM724 larger than MDM720? Should the ORG or starting locations, or the locations of some 'subroutines' be changed in the overlays? Jon Albers jalbers@bnl 28-Feb-84 08:10:43-MST,976;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 08:10:38-MST Received: From Uw-Beaver.ARPA by AMSAA via smtp; 28 Feb 84 1:08 EST Date: 27 Feb 84 22:00:22 PST (Mon) From: David Ragozin <ENTROPY!rag@AMSAA.ARPA> Received: by ENTROPY.UUCP (3.320/4.2) id AA29560; 27 Feb 84 22:00:22 PST (Mon) Subject: Re: Query to Multics people. Message-Id: <8402280600.AA29560@ENTROPY.UUCP> To: info-cpm@amsaa, uw-beaver!towson@amsaa Some time ago someone posted the following suggestion for FTP'ing ITS format files to get rid of thepadding bits in each 36-bit word: >quote (> is the FTP prompt) type "l 8" Entering these two lines seems to set things up properly on the UNIX system I work on, even though FTP does not have the TENEX mode (type?). There is still the need to eliminate the first 4 bytes using ITCVT (or using dd on a UNIX system). Hope this helps. David Ragozin - entropy!rag@uw-beaver 28-Feb-84 08:11:33-MST,1002;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 08:11:27-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 28 Feb 84 9:10 EST Received: From Sri-Sprm.ARPA by BRL via smtp; 28 Feb 84 9:05 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 28 Feb 84 5:55-PST Date: 27 Feb 84 12:15:03-PST (Mon) To: info-cpm@brl From: hplabs!hpda!fortune!burton@ucb-vax Subject: Moving Downloaded Files to Floppy - (nf) Article-I.D.: fortune.2629 #N:fortune:25500007:000:409 fortune!burton Feb 27 09:55:00 1984 For me this question is academic, since I'm not on ARPANET, and cannot down- load from SIMTEL20. For those who are/do, "How do you transfer your downloaded files onto a floppy for use on your CP/M system" Philip Burton 101 Twin Dolphin Drive Fortune Systems Redwood City, CA 94065 (415) 595-8444 x 526 - - - {allegra decvax!decwrl!amd70 cbosgd harpo hpda ihnp4 sri-unix}!fortune!burton 28-Feb-84 10:04:50-MST,815;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 10:04:45-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 28 Feb 84 11:44 EST Received: From Mit-Mc.ARPA by BRL via smtp; 28 Feb 84 11:36 EST Date: Tue, 28 Feb 84 11:22:54 EST From: Manny Crivello <crivello@bbn-unix> Subject: help wordstar To: info-cpm@mit-mc Hi I have an: apple II+,als cpmplus,smarterm 80col, and pkaso interface to a prism 132-all option. I can get Wordstar to work with my 80col or my printer, BUT, not at the sane time. can anyone save me a lot time of debuging and tell me how to configer wordstar. p.s. i'm using wordstar ver 3.01p I also have ver 3.3. i would be greatful for any help. M.D.Crivello 28-Feb-84 11:51:18-MST,1075;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 11:51:07-MST Date: Tue, 28 Feb 84 13:33:06 EST From: David Towson (CSD) <towson@amsaa> To: hplabs!hpda!fortune!burton@ucb-vax cc: info-cpm@amsaa Subject: Re: Moving Downloaded Files to Floppy - (nf) Philip - There are two families of programs that are commonly used to download files from a timeshare machine to a CP/M machine. One is based on a protocol created by Ward Christensen, and the other had its roots at Columbia University (I think). The first is called MODEM2, MODEM7, MDM7xx (xx=two digits) or some similar name. The second is called KERMIT. Both of these are available for with several timeshare machines and many micros. Whichever you choose, there must be compatible programs running on both ends of the transfer to obtain the benefits of automatic transfer with error detection and retransmission of bad blocks. MODEM7 files are on Simtel20, and KERMIT files are on Columbia-20. Dave towson@amsaa 28-Feb-84 15:57:15-MST,663;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 28 Feb 84 15:57:12-MST Received: From Brl-Vgr.ARPA by AMSAA via smtp; 28 Feb 84 16:03 EST Received: From Nbs-Sdc.ARPA by BRL-VGR via smtp; 28 Feb 84 15:58 EST Date: Tue, 28 Feb 84 15:34:48 EST From: blue@nbs-sdc Subject: Aztec CII directed I/O To: info-cpm@brl-vgr Recently someone described the slowness of directed I/O with Aztec's CII compiler as being caused by doing one 128-byte sector write for each character written. Can someone point me to the way to fix this? Thanks. Jim Blue National Bureau of Standards (blue @ nbs-sdc) 29-Feb-84 13:42:46-MST,1205;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 13:42:41-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 29 Feb 84 0:03 EST Received: From Cmu-Cs-A.ARPA by BRL via smtp; 28 Feb 84 23:52 EST Date: 28 Feb 84 2350 EST (Tuesday) From: George.Wood@cmu-cs-a To: info-cpm@brl Subject: RE: disk editor wanted for cpm/1791 Message-Id: <28Feb84.235047.GW90@CMU-CS-A> Ward Christiansen's DUU (DU version 77 ?) is a good disk editor, but will not do exactly what Bob Meier wants, i.e. read a bad sector, if the sector crc is bad; This is bacause the 179x series won't do the read -- it reports the crc error instead. If the sector is damaged but contains a valid crc, or is intermitently readable DUU will read it. The only way I know of to read really bad sectors is to read the whole track and pick the sector out of the track. I don't know of any editor which will do this, although I have a little program which will read a track into a buffer and let me mess with it via ddt. Reading whole tracks is pretty hardware specific, and on some non-dma systems, can't be done because of timing problems. George 29-Feb-84 13:42:52-MST,622;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 13:42:49-MST Received: From Brl-Vgr.ARPA by AMSAA via smtp; 29 Feb 84 0:49 EST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 29 Feb 84 0:46 EST Date: Wed 29 Feb 84 00:43:45-EST From: Lance Rips <HLP.LR%MIT-SPEECH@MIT-MC.ARPA> Subject: Help on graphics To: info-cpm@BRL-VGR.ARPA Does anyone know of reasonable graphics software for cpm? I don't need fancy pie charts or histograms, but simply bivariate plots (with lines or just scatter) for looking over data. Thanks. Lance ------- 29-Feb-84 13:43:00-MST,1402;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 13:42:55-MST Received: From Hi-Multics.ARPA by AMSAA via smtp; 29 Feb 84 1:18 EST Date: 29 February 1984 00:16 cst From: Eaton.HFED@hi-multics Subject: disk crc emulation To: info-cpm@amsaa I am trying to duplicate the CRC generation that occurs inside a WD1793 floppy disk controller chip. Western Digital's application notes on this chip specify that the crc register is preloaded with all ones and that the crc generation commences with the address mark and continues through the last data character. The test data that I am attempting to use was obtained by reading an ID field from disk. It consists of: FE (ID Adr Mark),00,00,02,00,87 (CRC1),90 (CRC2). I used the CRC routine from SYSLIB 2.7 feeding it 5 bytes of FE,00,00,02,00. The result was not 87,90 as I felt it should be. Even after modifying CRCCLR to initialize it's counter to FFFF I was still unable to duplicate the CRC's that were generated by the WD1793. Does the fact that the address mark is generated using a clock pattern of C7 have anything to do with this? Are clock bits also piped through the generator? The CRC routine supposedly uses the same X16 + X12 + X5 + 1 polynomial as the WD1793 chip. Where am I missing the boat on this? Eaton.HFED @ HI-MULTICS 29-Feb-84 13:43:12-MST,1749;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 13:43:04-MST Received: From Hi-Multics.ARPA by AMSAA via smtp; 29 Feb 84 1:58 EST Date: 29 February 1984 00:57 cst From: Eaton.HFED@hi-multics Subject: re:desoldering To: info-cpm@amsaa Some desoldering techniques that I have heard of or used: 1. Hand held solder sucker ball and soldering iron. (pros are good with these) 2. Vaccuum pump with desoldering iron. (excellent and expensive) 3. Propane torch and chip puller. (used on surplus boards only) 4. Special multiprong tips which desolder all pins simultaneously. 5. Solder wick and soldering iron. (I always blow etches) 6. Clip pins off chip using GA54-2 cutters from Diamond Tools then trim leads on new chip and solder them to stubs from old chip. The cutters have carbide steel tips which actually crush the pins across their widest points. A cheap tool will not hold up in repeated use. As you can tell by the length of this entry this is my method of choice for replacing bad chips. With the other methods that I can afford, there always seems to be some type of plated through hole damage. 7. One of my fellow technical types uses a variation of no. 6. He takes a hammer and screwdriver, puts the board on a sturdy flat surface and smashes the little buggers to smithereens (the chips that is) then reuses the old leads just as before. That always makes me nervous but he does it with high density memory boards with no ill effects. 8. Spring loaded vaccuum plungers and iron. (so-so) That's all I can think of at the moment. Bon Apetit. Jesse Eaton @ HI-MULTICS 29-Feb-84 13:43:23-MST,688;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 13:43:20-MST Received: From Radc-Multics.ARPA by AMSAA via smtp; 29 Feb 84 10:31 EST Date: 29 February 1984 10:32 est From: Wiedemann.4506i1808@radc-multics Subject: Ithaca S-100 CPU Monitor To: info-cpm@amsaa I have an Ithaca Audio Z-80 CPU board for an S-100 bus that needs a monitor ROM. The board is Model 1A-1010, Rev 2. Does anyone out there have the source code for the monitor? I have contacted Ithaca Audio and they said that since that board was discontinued several years ago, they no longer support it. Thanx much!! Wolf Wiedemann 29-Feb-84 13:43:31-MST,1245;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 13:43:26-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 29 Feb 84 11:21 EST Received: From Usc-Eclb.ARPA by BRL via smtp; 29 Feb 84 11:18 EST Date: 29 Feb 1984 0811-PST From: Brad%fcdssasd@BRL.ARPA Subject: Re: Help on graphics Sender: FCDSSASD@USC-ECLB.ARPA To: HLP.LR%MIT-SPEECH@MIT-MC.ARPA cc: FCDSSASD@USC-ECLB.ARPA, INFO-CPM@BRL.ARPA Reply-To: FCDSSASD@usc-eclb In-Reply-To: Your message of 28-Feb-84 2336-PST Lance, Probably the best all around grahpics package for business applications or any fairly simple problem is a software package called DGRAPH by FOX & GELLER 604 Market Street; Elmwood Park, New Jersey 07407 phone (201) 837-0142 Now i have used this package and it is very easy to use and won't take any time to learn. It's all menu driven and will even work on letter quality printers. In the latter use the period wears out quickly. The final product looks good and as you can probably tell, it will graph DBASE II (Ashton-Tate) files without conversion. Hope this helps. If you need mor info about DGRAPH (Fox & Geller) then let me know. Cheers, Brad ------- 29-Feb-84 13:44:14-MST,712;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 13:44:10-MST Received: From Hi-Multics.ARPA by AMSAA via smtp; 29 Feb 84 13:37 EST Date: 29 February 1984 12:37 cst From: Cargo.PD@hi-multics Subject: ? Command line access from MBasic To: info-cpm@amsaa I remember (too vaguely) seeing an article or note in a "recent" publication (within the last year) a "how to" on getting the cp/m command line from inside a MicroSoft BASIC program. I thought it was either in Dr. Dobb's or BYTE, but it might have been Microsystems. I would appreciate it if anybody could refresh my memory on this. Thank you. David Cargo (Cargo at HI-Multics) 29-Feb-84 19:08:31-MST,972;000000000000 Return-Path: <info-cpm-request@AMSAA.ARPA> Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 29 Feb 84 19:08:27-MST Received: From Brl-Vgr.ARPA by AMSAA via smtp; 29 Feb 84 20:51 EST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 29 Feb 84 20:49 EST Date: Wed 29 Feb 84 20:51:08-EST From: Thomas D. Carrell <SR.CARRELL%MIT-SPEECH@MIT-MC.ARPA> Subject: Help on graphics To: hlp.lr%MIT-SPEECH@MIT-MC.ARPA cc: info-cpm@BRL-VGR.ARPA Another plotting package that I use a lot is DataPlotter available from Lark Software, 7 Cedars Rd, Caldwell, NJ, 07006, phone (201) 226-7552. You can see examples of their plots in their ads in Microsystems. The package is cheap ($50), easy to use, flexible, and the graphs look great. I have had some accepted for publication in professional journals. They have versions for CP/M 80, MS-DOS, and CP/M 86. They support lots of different dot-matrix printers, and you have to specify which one you want. -------