CP/M

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

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

Wrap

Text File | 1993-02-12 | 326KB | 7,557 lines

3-Jan-84 16:18:08-MST,1024;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 16:18:04-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 24 Dec 83 17:07 EST Received: From Mit-Mc.ARPA by BRL via smtp; 24 Dec 83 17:04 EST Date: Sat 24 Dec 83 17:04:05-EST From: Edward Huang <RMS.G.EH%MIT-OZ@MIT-MC.ARPA> Subject: NEC/Rainbow MODEM pgms To: info-cpm@BRL.ARPA cc: rms.g.eh%MIT-OZ@MIT-MC.ARPA Hello, I have some members in my RCP/M network who are hampered due to insufficient info/lack of pub-dom pgms for the Rainbow 100 (IN 8-BIT MODE, not 16-bit which is easy) and the NEC PC-8001 (Anyone know how to use its UART?). I womuld appreciate hearing from others who own the above machines (running CP/M) and have sucessfully installed MODEM and/or BYE. Thanks, --Ed DataTech Network Headquarters 415-595-0541 300/1200 baud ps: Reply DIRECT to me as I am not on INFO-CPM. Thanks and Happy Holidays! ------- 3-Jan-84 16:22:12-MST,888;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 16:22:09-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 25 Dec 83 17:23 EST Received: From Mit-Ml.ARPA by BRL via smtp; 25 Dec 83 17:15 EST Date: 25 December 1983 17:18 EST From: Herb Lin <LIN@mit-ml> Subject: checksumming program for backing up disks... To: info-cpm@brl When I back up my disks, I live in constant fear that I am trashing a good copy of a file on my backup with a bad copy that somehow found its way onto the disk that I am backing up. it seems that a good solution to this would be the checksumming (or other check) on a disk file that could be compared to a central file of checksums somewhere. Anyone know anything like this in the public domain or for cheap sale? tnx. I will forward responses to the net. herb lin 3-Jan-84 16:22:41-MST,1340;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 16:22:35-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 25 Dec 83 19:58 EST Date: Sun, 25 Dec 83 19:53:16 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: MDM7xx overlay for DEC CP/M-80 machines Bernie Eiben has given us a new overlay for MDM7xx for 3 different DEC machines that run CP/M-80. It was announced earlier as a part of the MDM7xx package available from SIMTEL20 in the MICRO:<CPM.MODEM7> directory as M7VT-2.ASM, but I felt that additional information might be of use to Info-Cpm readers. Here's an excerpt from the message he sent to me telling what he did. ---forwarded message--- From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO> To: w8sdz at BRL Subject: MODEM 714 Keith, I modified the VT180 overlay to be "general" in serving VT180 / Rainbow / DECmate II , the three DEC-micro's currently able to run CP/M and to "talk" to the outside world. This overlay supersedes the M7VT-1 one - we have currently three BIOS-versions out in the field - and above overlay would have necessitated heavy DDTing. I re-defined EXTCHR to be closer to KERMIT and redefined IGNORCTL to be able to run HOST-programs which require Cursor-Control. 3-Jan-84 16:27:07-MST,1207;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 16:27:02-MST Received: From Rand-Relay.ARPA by BRL-VGR via smtp; 27 Dec 83 18:40 EST Date: 27 Dec 1983 1438-PST From: Rob-Kling <Kling.UCI-20B@rand-relay> Return-Path: <KLING%UCI-20b.UCI@Rand-Relay> Subject: Re: PC Lisp To: fsbrn@brl-voc, info-micro@brl-vgr, info-cpm@brl-vgr In-Reply-To: Your message of 27-Dec-83 1329-PST Received: from UCI-20b by UCI-750a; 27 Dec 83 14:39:41 PST (Tue) Via: UCI; 27 Dec 83 14:45-PST The December 1983 issue of PC Magazine has reviews of two LISPs for the IBM-PC: IQLISP and mu-LISP-82. IQ-LISP: $175 Integral Quality PO Box 31970 Seattle, Wash 98103 206-527-2918 mu-LISP-82 $250 Microsoft 10700 Northrup Way Bellvue, Wash 96828 206-838-8080 Other LISPs for the IBM-PC include: Intellect-UL: $225 PCD Systems Inc. 163 Main Street Penn Yan, New York 14527 315-536-7428 Intellect-UL LISP $100 IOTC Inc. 910 Scully Laramie, Wy. 82070 307-721-5818 LISP/88: $50 NORELL Data Systems 3400 Wilshire Blvd. Los Angeles, Ca. 90010 Rob Kling University of California, Irvine 3-Jan-84 16:29:09-MST,650;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 16:29:06-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Dec 83 20:03 EST Date: Tue, 27 Dec 83 19:56:54 EST From: Keith Petersen <w8sdz@brl> To: Info-Micro@brl-vgr, Info-Cpm@brl-vgr Subject: Need init info for MITS SIO board A friend wants to initialize his old MITS SIO S-100 board for either 300 baud or 1200 baud taking advantage of the fact that it can be programmed to use X1 or X16 division of the system clock. He doesn't have a book and needs to know what to output to the board to do this. 3-Jan-84 18:34:53-MST,1651;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 18:34:41-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Dec 83 14:13 EST Date: Wed, 28 Dec 83 14:08:50 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: MDM7xx overlay warning Anyone who upgrades to MDM715 should be told that the patching instructions in all the overlays are based upon the smaller MDM712-713-714 programs. Thanks to Bernie Eiben at DEC for pointing this out and telling about a simple way to calculate the number of pages to save. --- forwarded message --- Date: 28 Dec 1983 1214-EST From: B.Eiben LCG Ext 617-467-4431 <EIBEN at DEC-MARLBORO> To: w8sdz at BRL Subject: MODEM-Overlays Since MODEM has "grown" again, it might be usefull to update the "SAVE 66 MODEM.COM" to something like "SAVE 68 MODEM.COM" -- one otherwise gets quite erratic behaviour... A "better" way would probably a short explanation of the "magic": To convert the HEX "NEXT" address printed by DDT or SID into the decimal number You must give to the SAVE command in order to save the customized MODEM-version to disk, use the following algorithm: first take the leftmost two hex-digits and compute their decimal equivalent (e.g. 3C80 yields 3C, which is 60 decimal). Then, subtract 1 from that ONLY IF the rightmost two digits are 00 (for example the 60 above would remain 60 because the rightmost two digits of 3C80 are 80, not 00 ). The final value is the number to give to SAVE. [Courtesy of BDS C Users-Guide, Leor Zolman]. --- end of forwarded message --- 3-Jan-84 18:39:25-MST,630;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 18:39:21-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Dec 83 23:28 EST Date: Wed, 28 Dec 83 22:06:23 EST From: Rick Conn <rconn@brl> To: hplabs!hao!seismo!rlgvax!cvl!umcp-cs!aplvax!ded@ucb-vax cc: info-cpm@brl Subject: Re: Determining free disk space The DFREE routine in SYSLIB determines free disk space for a CP/M 2.2 system. It is a simple subroutine in assembly language, and you can get the source (make sure it is for SYSLIB 2.7) from SIMTEL20 or SIG/M. Rick 3-Jan-84 18:50:19-MST,554;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 3 Jan 84 18:50:15-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Dec 83 23:28 EST Date: Wed, 28 Dec 83 22:12:24 EST From: Rick Conn <rconn@brl> To: Keith Petersen <W8SDZ@simtel20> cc: Info-Cpm@brl-vgr Subject: Re: LRUN files There is also LRUNZ in the ZCPR2 set. This is a version of LRUN which can be used as an extended command processor under ZCPR2 and has a built-in search for the LBR file. Rick 4-Jan-84 09:11:25-MST,1079;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 4 Jan 84 09:11:19-MST Received: From Stl-Host1.ARPA by BRL-VGR via smtp; 28 Dec 83 23:27 EST Date: 28 Dec 1983 22:25 CST (Wed) Message-ID: <WANCHO.11979242740.BABYL@STL-HOST1> From: WANCHO@stl-host1 To: INFO-CPM@brl-vgr Subject: Need Help with CCS 2422 FDC As thorough as the manuals for the CCS 2422 FDC appear to be, it doesn't help me configure the board precisely the way I need it. What I need is to set it up so that it uses NO memory address space, banked or otherwise, and does not Auto Boot or anything. I simply want it to sit there, waiting to be "addressed" with something equivalent to an attached BIOS. The configuration is for a N* HORIZON running TurboDOS, and, yes, I have the alternate U22 addressed at F8H-FDH (instead of the default 30H-34H and 04H). I have also read the article in Microsystems, but it was no help for this case. If anybody has made such a configuration work, please contact me by net mail. Thanks, Frank 4-Jan-84 09:25:13-MST,786;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 4 Jan 84 09:25:09-MST Received: From Brl-Bmd.ARPA by BRL-VGR via smtp; 2 Jan 84 13:07 EST Date: Mon, 2 Jan 84 12:52:31 EST From: Keith Petersen <w8sdz@brl-bmd> To: Info-Modem7@mit-mc, Info-Cpm@brl-vgr Subject: Incorrect phone number in MDM715 overlay The following is forwarded from the Sysop Clearinghouse RCPM: --- Date: 12/31/83 From: Walt Jung To: All Re: MDM715 numbers A bad phone number has crept into MDM715, in the NM overlay, under my name. The correct number is 301-661-2175.. pls correct the copy for distribution, so that the poor soul doesn't get called to death. Why doesn't RCPM-nnn.LST get checked for these numbers? --end-- 4-Jan-84 09:26:37-MST,898;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 4 Jan 84 09:26:33-MST Received: From Brl-Bmd.ARPA by BRL-VGR via smtp; 2 Jan 84 13:33 EST Date: Mon, 2 Jan 84 13:30:28 EST From: Keith Petersen <w8sdz@brl-bmd> To: Info-Modem7@mit-mc, Info-Cpm@brl-vgr Subject: Using MDM716 with Cromemco CDOS CDOS users: Get M7CD-1.ASM from the SIMTEL20 MICRO:<CPM.MODEM7> directory. After you overlay MDM716.COM using DEBUG, patch the following locations to NOPs (binary zeros): 2ABD, 2ABE, 2ABF, 2AC0. This will disable the CP/M disk stat call function 1Fh which is not implemented in the current version of CDOS. The MDM716 DIR function will then work, but will show 0k left on the disk. That's livable, and certainly better than before when CDOS gave an error message and jumped out of MDM716 to return to the system. --Keith 4-Jan-84 09:51:15-MST,593;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 4 Jan 84 09:51:12-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Jan 84 15:19 EST Received: From Mit-Mc.ARPA by BRL via smtp; 29 Dec 83 22:50 EST Date: 29 December 1983 22:50 EST From: Robert L. Plouffe <PLOUFF@mit-mc> To: INFO-CPM@mit-mc, INFO-MODEM7@mit-mc cc: PLOUFF@mit-mc Regarding release of mdm716 per Keith's message, and for those at MIT-MC who can't ftp from SIMTEL20. please be advised that the squeezed source file is also at MC in MC:FJW;MDM716 AQM 4-Jan-84 09:56:37-MST,4950;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 4 Jan 84 09:56:25-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Jan 84 15:18 EST Date: Thu, 29 Dec 83 13:46:28 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr cc: Info-Modem7@mit-mc Subject: MDM716 release - a major improvement Bob Plouffe has just released MDM716, a major improvement in the MDM7xx series of MODEM7 programs. It's now available on SIMTEL20 in the MICRO:<CPM.MODEM7> directory as: MDM716.ASM - the source code (not normally needed, use .COM and overlay) MDM716.AQM - same as above, but squeezed, stored in ITS-Binary format MDM716.COM - stored in ITS-Binary format MDM716.HEX - for people who cannot FTP .COM files NOTE: When customizing the .COM file with your overlay, use the command SAVE 69 MODEM7.COM after exiting DDT. This is because MDM716.COM is larger than MDM712-713-714 for which the instructions were written. Here's what's new in this, and a few previous versions: ---- 12/27/83 1. Detection of first SOH is made less susceptible to noise hits on the line and to extraneous characters sent by a remote just prior to sending sector header. (such MDM716 as when 'Q' option is not set at remote under 'BYE') 2. Permits operation with a remote computer using `BYE' and any version of the CHRISTENSEN PROTOCOL without the need to set the 'Q' option at remote when receiving files FROM it (SENDING & RECEIVING WHEN BOTH ENDS ARE CHANGED TO THIS CODE). Thus progress reporting at both ends is possible. This works in both single file and BATCH modes of operation. 3. At the receive file end, progress is shown only after each sector is actually received rather than when it is awaiting a sector. Thus, the sector count at the end of receiving a file matches the actual sector count in the file. 4. Adds back the feature previously deleted that allows the operator the option of retry if the ERROR LIMIT is reached. This is virtually essential on packet switched Networks like ARPANET and others that can get throttled by traffic and delay the sending of packets. Who needs an automatic ABORT after receiving 1120 sectors out of 1250 when a retry would probably allow continuance? 5. Corrects the SENDFILE routines that caused some of the problems that the above fixes now tolerate. File name characters were actually sent twice. Once as found in the FCB (in FCB format) and again in CP/M format - one after the other, character-by-character including the '.' of the CP/M format. Whoo boy, what a mess. Anyway the program is now fixed not to do that and the receive-file changes tolerate both the new and the old. 6. Provides noise and extraneous string protection to the detection of 'ACK' and 'NAK'. RESENDS A SECTOR ONLY ON RECEIPT OF A VALID NAK OR AFTER A TIMEOUT ERROR MSG. 7. Fixed T-MODE so that re-use of the command buffer does not cause a problem. T-MODE now uses 128 bytes from CMDBUF+2 so that buffer size is not wiped out. 8. Corrected MENU2 for the (V)iew option to show the use of 'R' and/or 'S' to view Received and/or Sent bytes at the console. This feature present since MODEM2 but never correctly shown in the MODEM7 help screens. 9. Fixed buffer problem that caused batch mode to fail unpredictably when sending a large number of files. - Bob Plouffe 12/11/83 Expanded Hayes redial options. Eliminated scrolling MDM715 of CRT display during redial. Added clue to abort CAL. Eliminated duplicate 'CONNECT' msg on CRT (from Hayes). Eliminated display of ALT LD access codes. Faster redial for Hayes. Resets Hayes (ATZ) on BYE command. Finished clean-up of comments missed by NEAT. Shortened 3 LTR command help screen by one line. New NUMLIB ORG 0D00. - Tom Bering 11/11/83 Releasing full source code, including all comments. Updated MDM714 the telephone library for currently available RCPM systems. LF not automatically added in "L" half duplex mode now. Can be added via "TLF" command if needed. Renamed the overlays to allow them to remain independent of further updates. Ex- ample: M7AP-1.ASM, M7GP-1.ASM, M7PC-1.ASM, etc. Enjoy. - Irv Hoff --end-- 4-Jan-84 10:31:08-MST,1437;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 4 Jan 84 10:30:59-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Jan 84 15:22 EST Received: From Sri-Unix.ARPA by BRL via smtp; 30 Dec 83 2:30 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 29 Dec 83 23:25-PST Date: 27 Dec 83 10:16:00-PST (Tue) To: info-cpm@brl From: hplabs!hpda!fortune!burton@ucb-vax Subject: How Does Wordstar Work - the 'r' command. Article-I.D.: fortune.2106 How does the 'r' command work in Wordstar V3.x? Why can't a cpm 'submit' work properly. Does WS do its own submit. If so, it doesn't leave behind a $$$.sub file, if my system is rebooted before the return from the cp/m command back to WS. Is the 's' spelstar command just a special purpose 'r' command? Could Spelstar be operated from the 'r' command? Could WS be patched by replacing SPELSTAROVR (about location 1000h) with DU to any command name, and get that command run off the 's' command? Is all of WS.COM cleared out of RAM when an 'r' command (or SPELSTAR) is invoked? Also, my version of XDIR3 (1.5) running on straight vanilla cp/m doesn't work properly when run from 'r'. -- >From phipps Wed Dec 21 18:05:03 1983 To: burton {allegra,amd70,cbosgd,dsd,floyd,harpo,hollywood,hpda,ihnp4, magic,megatest,nsc,oliveb,sri-unix,twg,varian,VisiA,wdl1} !fortune!phipps 4-Jan-84 10:57:49-MST,825;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 4 Jan 84 10:57:46-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Jan 84 15:22 EST Received: From Sri-Unix.ARPA by BRL via smtp; 30 Dec 83 3:30 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 30 Dec 83 0:26-PST Date: 21 Dec 83 6:27:04-PST (Wed) To: info-cpm@brl From: decvax!duke!mcnc!ecsvax!emigh@ucb-vax Subject: Latest version of UC.C (UNIX to CP/M file transfer shell) Article-I.D.: ecsvax.1739 I have posted the latest version of UC.C (UNIX(tm) to CP/M file transfer shell) to net.sources (ecsvax.1738). The program was written by Rick Conn (rconn@brl), and the latest version corrects a minor error in that UC always created a uc.log file, even when the option was turned off. 5-Jan-84 09:23:19-MST,689;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 5 Jan 84 09:23:14-MST Received: From Brl-Vgr.ARPA by BRL-TGR via smtp; 6 Jan 84 10:17 EST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Jan 84 15:31 EST Received: From Bnl.ARPA by BRL via smtp; 30 Dec 83 11:03 EST Date: 29-Dec-83 21:07:48-EST From: jalbers@bnl Subject: BYE for CPM3? To: info-cpm@brl Does anyone out there have BYEx.x out for the Osborne Executive 1 running CPM3? Does anyone have a version for CPM3? Could anyone help someone write/set-up/whatever such a version? (Help! Help!) Jon Albers (jalbers@bnl or ALBERS@ML) 5-Jan-84 09:23:40-MST,2319;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 5 Jan 84 09:23:33-MST Received: From Brl-Vgr.ARPA by BRL-TGR via smtp; 6 Jan 84 10:17 EST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Jan 84 15:32 EST Date: Fri, 30 Dec 83 13:27:15 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: New Apple CP/M overlay for MDM7xx M7AP-2.ASM, an updated Apple CP/M overlay for MDM7xx, is now available on SIMTEL20 in the MICRO:<CPM.MODEM7> directory. This overlay file enables Apple II computers with the Apple Super Serial card and external modem to use the MDM7xx phone modem program. It also supports the following Apple modem configurations: a) CCS 7710 serial interface and external modem b) SSM serial interface and external modem c) Apple communications interface and external modem d) Mountain Hardware CPS Multifunction card and external modem e) Prometheus Versacard with software baud select and ext. modem To use SET with the Prometheus Versacard a small hardware mod must be made, since the Versacard only supports baud rate selection via DIP switches. This Mod will allow the Versacard to be switched between 300 and 1200 baud via software. Revision history: 12/26/83 - Added Versacard support with software baud selection. Revised to allow easy serial card relocation made SYSVER more informative. - Tony Antonucci 11/11/83 - Renamed to M7AP-1.ASM, no changes - Irv Hoff 10/07/83 - Added CPS card support - Wally Hubbard 07/27/83 - Renamed to work with MDM712 - Irv Hoff 07/01/83 - Revised to work with MDM711 - Irv Hoff 06/22/83 - Revised to work with MDM710 - Irv Hoff 05/27/83 - Updated to work with MDM709 - Irv Hoff 05/15/83 - Revised to work with MDM708 - Irv Hoff 04/11/83 - Updated to work with MDM707 - Irv Hoff 04/04/83 - Updated to work with MDM706 - Irv Hoff 02/27/83 - Updated to work with MDM705 - Irv Hoff 02/12/83 - Used MDM703CF to make this file for Apple computers using a var- iety of serial interface cards with external modem. - Bruce Kargol 5-Jan-84 09:28:03-MST,2082;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 5 Jan 84 09:27:54-MST Received: From Brl-Vgr.ARPA by BRL-TGR via smtp; 6 Jan 84 10:18 EST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Jan 84 15:32 EST Date: Fri, 30 Dec 83 13:29:50 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: ERAQ15.ASM now available ERAQ15.ASM is now available on SIMTEL20 in the MICRO:<CPM.DIRUTL> directory. ERAQ15 is a selective erase program. Shows file names and separately asks confirmation on each, prior to erasure. This minimizes accidental erasures. (If you still erase a file you meant to keep you can easily restore it to normal by using a program called "UNERA". This assumes you have not overwritten any part of it). This program is patterned after the ERAQ function provided with Digital Research's MP/M system. Modification & Update List: 12/21/83 Increased capacity to more than 256 files. Used to have v1.5 problems with large directories because file counters were only eight bits wide - now 16. Made the "no files specified" error optional by conditional assembly. Added "ASEG" directive and eliminated colons on equate lables to allow assembly by Macro-80. Tony Newman (WB7FCN) 01/10/83 Modified to eliminate warm reboot when finished. Was most annoying, for if not in 'A' drive rebooted both the current v1.4 drive and 'A' as well. Reformatted, now assembles normally with ASM or MAC. Standardized tab stops, some were missing. Included error message if no files specified for erasure. - Irv Hoff 04/16/82 Mask bit 7 for console output for memory-mapped video boards which use the high bit for attribute info. 12/10/81 Added checks for $SYS and $RO attributes. 11/20/81 Added default to '*.*' if no input parameters. 11/08/81 Original program written by Thomas Hill. 5-Jan-84 09:28:36-MST,3094;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 5 Jan 84 09:28:27-MST Received: From Brl-Vgr.ARPA by BRL-TGR via smtp; 6 Jan 84 10:18 EST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Jan 84 15:32 EST Date: Fri, 30 Dec 83 13:28:40 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: BYE3-16.ASM now available BYE3-16.ASM is now available on SIMTEL20 in the MICRO:<CPM.BYE3> directory. This program allows modem callers to use a CP/M system just as if they were seated at the system console. Special assembly-time options allow limiting the caller's access by password and/or access to only a message-service program. A number of external routines are available to adapt this program to various computers. This revision corrects some problems with conditional assembly errors. Here's an excerpt from the update history: 12/16/83 Cleaned up some conditional statements. Added WELFILE v3.1.6 conditional statement to bypass typing Welcome. Made minor mods to the SMODEM routine to make it work on a KAYPRO. - Bill Duerr 12/15/83 Included a new Smartmodem routine. This will be needed by v3.1.5 most users since the Smartmodem (or similar, such as the U.S. Robotics) are in common use. (There were four different rou- tines being used in the various external inserts. This will standardize that to just one version.) Hopefully this routine will prevent reception of any incoming call until it is ready for the call. (Steve Holtzclaw's extensive Smartmodem routine which checks echo characters may still be required under some cirumstances. It is not needed with the US Robotics modems.) This version has been tested extensively on several RCPM sys- systems using several different types of computers, including 2651, 2661, 2850 and 2851 I/O devices.. - Irv Hoff and John Ferguson BYE3 supports the following modems and/or USART combinations: SMDM routine - by Steve Holtzclaw B3SM51-3.ASM (includes 8251 I/O) 8250 - by Paul Traina B3HZ89-3.ASM 2651 - by Paul Traina B3COMP-3.ASM 8251+CTC timer - by Irv Hoff B3DATA-3.ASM APPLE-CAT - by Dave Roznar B3ACAT-3.ASM MM100 - by Dave Jaffe B3DCH-3.ASM HZ-100 - by John Ferguson B3HZ10-3.ASM Kaypro - by Steve Sanders B3KPRO-3.ASM MMII (Apple) - by Paul Traina B3MMII-3.ASM PMMI - by Ward Christensen B3PMMI-3.ASM SIO - by Steve Fox B3SIO-3.ASM Televideo 802 - by K. Robesky B3T802-3.ASM Most users of this program will have an auto-answer modem such as the Hayes 300 or 1200, the U.S.Robotics or Rixon. A routine that supports these modems has been included. Set the SMODEM equate to 'YES' if you have one of these modems, 'NO' if another type of auto-answer modem such as the PMMI, Bell 212A, etc. 5-Jan-84 09:30:38-MST,1240;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Thu 5 Jan 84 09:30:34-MST Received: From Brl-Vgr.ARPA by BRL-TGR via smtp; 6 Jan 84 10:18 EST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Jan 84 15:32 EST Date: Fri, 30 Dec 83 13:36:18 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: UC.C under 4.2BSD Unix ----- Forwarded message # 1: Date: Fri, 30 Dec 83 8:53:17 EST From: Rick Conn <rconn@brl> To: Richard Kawala <kawala%ucbcory@ucb-vax> cc: w8sdz@brl, rconn@brl Subject: Re: uc.c UC.C was written for and is supported on UNIX SYSTEM V. Two problems with it have been reported to me via USENET contacts when one tries to run it on 4.2BSD, but without a 4.2BSD machine available with direct- connect, I am not supporting 4.2BSD implementations. One problem is with the stat() routine in UC. Its name should be changed due to a conflict with some library routine under 4.2BSD. The other problem is with the interrupt scheme used. My reports hinted that a longjump() was required under 4.2BSD. I have no other details. Hope this helps. Rick Conn ----- End of forwarded messages 6-Jan-84 08:53:32-MST,806;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Fri 6 Jan 84 08:53:27-MST Received: From Brl-Vgr.ARPA by BRL-TGR via smtp; 5 Jan 84 12:27 EST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 5 Jan 84 8:40 EST Received: From Sri-Unix.ARPA by BRL via smtp; 5 Jan 84 8:22 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 5 Jan 84 4:56-PST Date: 24 Dec 83 19:42:52-PST (Sat) To: info-cpm@brl From: pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax Subject: Re: The response on BIOS's I promised. - (nf) Article-I.D.: uiucdcs.4700 #R:sri-arpa:-1465200:uokvax:7900004:000:110 uokvax!andree Dec 22 17:13:00 1983 Could you post more details on your BIOS for the Ithaca hardware? Or maybe post a copy to net.sources? <mike 6-Jan-84 08:54:24-MST,1083;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Fri 6 Jan 84 08:54:19-MST Received: From Brl-Vgr.ARPA by BRL-TGR via smtp; 5 Jan 84 12:31 EST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 5 Jan 84 8:45 EST Received: From Brl-Voc.ARPA by BRL via smtp; 5 Jan 84 8:34 EST Date: Thu, 5 Jan 84 8:17:01 EST From: "Ferd Brundick (LTTB)" <fsbrn@brl-voc> To: Mike Simpson <msimpson@bbn-unix> cc: northstar-users@simtel20, info-micro@brl, info-cpm@brl, msimpson@bbn-unix Subject: Re: printer questions Hi, You want to install patches in the user-defined functions ^Q,^W,^E, and ^R. These can be multiple key sequences, which is quite handy if your printer uses ESCape sequences like mine does. Check your Word* manual on how to go about defining your own functions. dsw, fferd Fred S. Brundick USABRL, APG, MD. <fsbrn@brl-voc> 6-Jan-84 09:01:34-MST,2257;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 6 Jan 84 09:01:27-MST Received: From Nbs-Sdc.ARPA by BRL-VGR via smtp; 5 Jan 84 14:08 EST Date: Thu, 05 Jan 84 14:09:44 EST From: blue@nbs-sdc Subject: Conference Announcement To: info-micro@brl-vgr Cc: info-cpm@brl-vgr Numerical Computation and Mathematical Software For Microcomputers On March 19-21, the ACM Special Interest Group on Numerical Mathematics (SIGNUM) will sponsor a conference on Numerical Computation and Mathematical Software For Microcomputers. The conference will be held at the Hilton Harvest House Hotel in Boulder, Colorado. Registration will be limited to approximately 250 applicants. Invited Papers Invited speakers include P. W. Gaffney (Oak Ridge), "FORTRAN Compilers for Microcomputers;" W. M. Gentleman (National Research Council), "MIMD Architecture using Microcomputers;" G. A. Hamlin (Los Alamos), "Graphics on Microcomputers;" J. Siebenaler (Motorola), "Strategy and Testing of Floating-Point Coprocessors;" R. F. Sincovec (U. Colorado, Colorado Springs), "Using Modula-2 and Ada for Numerical Computations on Microcomputers;" and J. Wooten (Los Alamos), "Use of Microcomputers in a Scientific and Engineering Workstation Environment." Special Sessions There will be special sessions of 30-minute talks on Microcomputers in Parallel Architectures and on Mathematical Software for Microcomputers. Vendor Exhibits There will be an exhibit of computers and software during the meeting. Vendors will make 30-minute oral presentations during special evening sessions. Contributed Papers One-page astracts for 20-minute contributed talks should be submitted immediately to: Dr. William G. Pool, Jr. Pacific Analysis & Computing 1020 109th Avenue SE Bellevue, Washington 98004 Registration For information, contact: Dr. Roland A. Sweet MS 713 National Bureau of Standards 325 Broadway Boulder, Colorado 80303 (303) 497-5671 6-Jan-84 09:27:05-MST,937;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Fri 6 Jan 84 09:26:59-MST Received: From Brl-Vgr.ARPA by BRL-TGR via smtp; 5 Jan 84 12:24 EST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 5 Jan 84 7:24 EST Received: From Sri-Unix.ARPA by BRL via smtp; 5 Jan 84 7:14 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 5 Jan 84 4:09-PST Date: 4 Jan 84 14:40:47-PST (Wed) To: info-cpm@brl From: ihnp4!ihuxe!staley@ucb-vax Subject: FOR SALE CP/M SYSTEM Article-I.D.: ihuxe.463 S-100(10 slot),Internal Power Supply,Fan'd inclosure,many cut-outs for connectors,RS-232 Terminal & Modem Interfaces,Z80-CPU,64k Ram,Tarbell Disk Controller,2-serial,2-parallel I/O ports,2-8inch Disk Drives in fan'd inclosure with power supply,Cabling,Documentation,CP/M,Televideo 912c Terminal,Misc Software $1700 ihuxe!staley 1-312-979-1646 1-312-462-1029 6-Jan-84 09:27:28-MST,1268;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Fri 6 Jan 84 09:27:23-MST Received: From Brl-Vgr.ARPA by BRL-TGR via smtp; 5 Jan 84 12:29 EST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 5 Jan 84 8:40 EST Received: From Sri-Unix.ARPA by BRL via smtp; 5 Jan 84 8:24 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 5 Jan 84 5:08-PST Date: 24 Dec 83 19:43:04-PST (Sat) To: info-cpm@brl From: pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax Subject: Re: UC 1.4 - (nf) Article-I.D.: uiucdcs.4701 #R:sri-arpa:-1469500:uokvax:7900005:000:592 uokvax!andree Dec 22 17:19:00 1983 I'm running uc under 4.1c No problems once I got it up. There was a problem in bringing it up. Uc gets file stats through a function called `fstat', which can be found near the end of the source. Fstat is also a library routine on 4.1c, and is called by both printf and stat. Since the uc fstat calls stat, calling printf leads to an infinite recursion. The first thing uc does is print it's name out, so running it produces a short delay, followed by dropping core due to stack overflow. I changed the name of the routine from fstat to filestat, and everything worked like a charm. <mike 6-Jan-84 10:26:56-MST,1015;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-TGR by SIMTEL20.ARPA with TCP; Fri 6 Jan 84 10:26:52-MST Received: From Brl-Vgr.ARPA by BRL-TGR via smtp; 5 Jan 84 12:33 EST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 5 Jan 84 8:59 EST Received: From Sri-Unix.ARPA by BRL via smtp; 5 Jan 84 8:46 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 5 Jan 84 5:39-PST Date: 30 Dec 83 19:45:03-PST (Fri) To: info-cpm@brl From: pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax Subject: UDS 212 A/D autodial code wanted - (nf) Article-I.D.: uiucdcs.4734 #N:uokvax:7900006:000:340 uokvax!andree Dec 28 01:51:00 1983 I am working on autodial code (using YAM) for a UDS 212 A/D. This modem tends to output lines like `OFF HOOK - D.T. - DIALING - ABT - COMPLETE'. The problem is that there is NO way to turn this off. If anyone has code (C preferable) to handle this modem, or something similiar, I'd appreciate seeing a copy before I start. Thanx, <mike 10-Jan-84 10:55:56-MST,552;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 10:55:52-MST Received: From Parc-Maxc.ARPA by BRL-VGR via smtp; 5 Jan 84 13:24 EST Date: Thu, 5 Jan 84 10:18 PST From: BillHolland.es@PARC-MAXC.ARPA Subject: Re: BYE3-16.ASM now available In-reply-to: "w8sdz@brl.ARPA's message of Fri, 30 Dec 83 13:28:40 EST" To: Keith Petersen <w8sdz@brl.ARPA> cc: Info-Cpm@brl-vgr.ARPA HEY CAN I GET THERE FROM A ALTO ? HOW ABOUT MY SYSTEM AT HOME ? PLEASE GIVE DETAILS.....BIG DUMMY Bill 10-Jan-84 10:56:58-MST,740;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 10:56:52-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 5 Jan 84 20:30 EST Received: From Mit-Mc.ARPA by BRL via smtp; 5 Jan 84 20:20 EST Date: 5 January 1984 20:21 EST From: Eric Stork <STORK@mit-mc> Subject: stork To: info-cpm@brl Subject: dBASE2 question Can someone tell me how to set up DBASE2.COM so that it can be permanently on Disk C:, and will find its overlay files on C: even if it is invoked from A: or B:? In WordStar there is a location to set for where to look for overlay files. Logically, there should be such a location in dBASE, too. Advice will be appreciated. Eric. 10-Jan-84 10:57:43-MST,739;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 10:57:38-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 5 Jan 84 20:30 EST Received: From Mit-Mc.ARPA by BRL via smtp; 5 Jan 84 20:24 EST Date: 5 January 1984 20:25 EST From: Eric Stork <STORK@mit-mc> To: info-cpm@brl cc: STORK@mit-mc Subject: dBASE2 question Can someone tell me how to set up DBASE2.COM so that it can be permanently on Disk C:, and will find its overlay files on C: even if it is invoked from A: or B:? In WordStar there is a location to set for where to look for overlay files. Logically, there should be such a location in dBASE, too. Advice will be appreciated. Eric. 10-Jan-84 11:04:16-MST,1110;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 11:04:10-MST Received: From Amsaa.ARPA by BRL-VGR via smtp; 6 Jan 84 9:39 EST Date: Fri, 6 Jan 84 9:28:54 EST From: David Towson (CSD) <towson@amsaa> To: info-cpm@brl-vgr, info-micro@brl-vgr Subject: How to use a TAC. During 1983, there was considerable discussion (and confusion) in these newsgroups concerning the mysteries of the Terminal Access Controller (TAC), that frustrating device by which one can access the Defense Digital Network of computers. Soon, passwords will be required for TAC access, so this message will not be of interest to all. However, for those in a position to benefit, the TAC Users Guide can be obtained by anonymous FTP from machine usc-isia. Login with username anonymous and password ftp (or any non-null string), and ask for file <documentation>tac-user-guide. You might also like to get a directory listing for the <documentation> directory, which is quite large, and which has many goodies. Dave Towson towson@amsaa 10-Jan-84 11:04:29-MST,741;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 11:04:25-MST Date: Fri, 6 Jan 84 11:25:43 EST From: Dave Towson (info-cpm) <cpmlist@brl-vgr> To: info-cpm@brl-vgr Subject: [STERNLIGHT%USC-: BYE with TRS-80 Models 2/12/16 (Part 2).] ----- Forwarded message # 1: Received: From Usc-Ecl.ARPA by BRL-VGR via smtp; 5 Jan 84 17:11 EST Date: 5 Jan 1984 1210-PST From: STERNLIGHT%USC-ECL@SRI-NIC Subject: BYE with TRS-80 Models 2/12/16 (Part 2). To: info-cpm-request at BRL-VGR cc: sternlight at ECL By the way, you need to include B3SIO-3.ASM in BYE3-16 to have it work with the 2/12/16s. -david-- ------- ----- End of forwarded messages 10-Jan-84 11:06:25-MST,1903;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 11:06:19-MST Date: Fri, 6 Jan 84 11:24:08 EST From: Dave Towson (info-cpm) <cpmlist@brl-vgr> To: info-cpm@brl-vgr Subject: [STERNLIGHT%USC-: Running BYE on TRS-80 Models 2/12/16] ----- Forwarded message # 1: Received: From Usc-Ecl.ARPA by BRL-VGR via smtp; 5 Jan 84 17:10 EST Date: 5 Jan 1984 1206-PST From: STERNLIGHT%USC-ECL@SRI-NIC Subject: Running BYE on TRS-80 Models 2/12/16 To: info-cpm-request at BRL-VGR cc: sternlight at ECL Well, users of the TRS-80 Models 2, 12 and 16 running CP/M can finally set up bulletin boards using bye. The latest version, bye3-16 will run fine above bdos. Set BYELOW to 'NO', reconfigure cp/m to leave enough space in high memory, and you're off. For Pickles and Trout CP/M, version 2.2m, what works is to set the top of CP/M to EFFF using the menu configuration program. If you're using a Smartmodem, set the base address of the ports to F4 for Serial Port A or F6 for serial port B. I haven't figured out how to handle the baud rate port yet but if you use the MENU setup command in P&T, you can set that port for either 300 or 1200 baud and leave it there. Make sure you rename bye, since users need to log off by hanging up, not by typing bye and invoking the bye program (it hangs). You can create a substitute program named 'bye' if you like, which simply types 'please hang up now' over and over when it is invoked. If anyone figures out how to get the baud rate select features working in bye3 with P&T CP/M, please let me know. Note also that BYELOW set to YES won't work for P&T CP/M; the bye program runs fine until it tries to drop into CP/M, but then it hangs. If anyone has solved that one also, please let me know. --david-- ------- ----- End of forwarded messages 10-Jan-84 11:09:50-MST,1630;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 11:09:42-MST Received: From Amsaa.ARPA by BRL-VGR via smtp; 6 Jan 84 16:20 EST Date: Fri, 6 Jan 84 16:17:32 EST From: David Towson (CSD) <towson@amsaa> To: info-cpm@brl-vgr, info-micro@brl-vgr Subject: "How to use a TAC" - correction! OOPS!!! It seems I goofed; that file name has a .doc on the end. It should read "<documentation>tac-user-guide.doc". Sorry! Dave ----- Forwarded message # 1: Received: From Brl-Vgr.ARPA by AMSAA via smtp; 6 Jan 84 9:46 EST Received: From Amsaa.ARPA by BRL-VGR via smtp; 6 Jan 84 9:39 EST Date: Fri, 6 Jan 84 9:28:54 EST From: David Towson (CSD) <towson@amsaa> To: info-cpm@brl-vgr, info-micro@brl-vgr Subject: How to use a TAC. During 1983, there was considerable discussion (and confusion) in these newsgroups concerning the mysteries of the Terminal Access Controller (TAC), that frustrating device by which one can access the Defense Digital Network of computers. Soon, passwords will be required for TAC access, so this message will not be of interest to all. However, for those in a position to benefit, the TAC Users Guide can be obtained by anonymous FTP from machine usc-isia. Login with username anonymous and password ftp (or any non-null string), and ask for file <documentation>tac-user-guide. You might also like to get a directory listing for the <documentation> directory, which is quite large, and which has many goodies. Dave Towson towson@amsaa ----- End of forwarded messages 10-Jan-84 11:34:35-MST,832;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 11:34:31-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Jan 84 4:05 EST Received: From Mit-Mc.ARPA by BRL via smtp; 7 Jan 84 3:56 EST Date: 7 January 1984 03:54 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: Church Support Software Distribution To: ABN.ISCAMS@usc-isid cc: INFO-CPM@brl In-reply-to: Msg of 17 Oct 1983 10:00-PDT from ABN.ISCAMS at usc-isid If you can get a disk of your Church Support software to me by US Snail, Workman would be willing to distribute at what amounts to his cost (somewhere between 20 and 30 bucks depending on a number of factors) largely for good will. He's got a number of churches within his customer base and they're always asking for help. 10-Jan-84 11:47:38-MST,800;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 11:47:34-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Jan 84 8:53 EST Date: Sat, 7 Jan 84 8:27:43 EST From: Rick Conn <rconn@brl> To: Eric Stork <STORK@mit-mc> cc: info-cpm@brl Subject: Re: stork Eric, I've had a similar need, but never found a solution. Instead, I got around it under ZCPR2 by creating a script command like the following: A:;dbase setup;B: In this way, I have all my work on B: and dbase.com and its overlays on A:. The command processor goes to A:, runs dbase, and the setup.prg file sets default to B:, so any files I reference come from B:. When done, the trailing B: puts me back into B:. Rick 10-Jan-84 12:10:58-MST,4092;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 12:10:47-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Jan 84 15:40 EST Date: Sat, 7 Jan 84 15:35:13 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: dBASE2'S RESET function Thanks to Eric Stork for the following tip for users of DBASE2: --- Subject: dBASE2's RESET function dBASE2's RESET function does not work as it should. That can be a serious problem. But there is a fix. A bit tricky, but it works. It took so long to figure it out that it seems worthwhile to send this note to the net to share the fix. Over the holidays, I spent some time (quite a bit, it turned out) helping a doctor friend of mine fix his accounting system by interfacing it to dBASE2. His application requires several disk changes. We duly inserted RESET commands in the proper places, but the thing still would not work -- every effort to write to a changed disk bombed out with 'BDOS Error R/O' After a lot of study in various references from magazines, etc., we finally realized why -- RESET simply does not reset the CP/M disk map in memory, as it should. No way to make it work, either, by using SET DEFAULT or so. The solution is in an unpublicized feature of dBASE2 that permits the user the write his own assembly language routines, POKE them into memory above dBASE2's code, CALL them and RETURN from them. Above dBASE2's memory means above A400h, which is used only for sorting dBASE files. The routine that finally did the trick was placed into a file called RESETT.CMD (two t's to differentiate from dBASE2's RESET command). We then inserted in the main command file the line: DO RESETT after every disk swap (we always swapped on B:) * This command file is RESETT.CMD SET CONS OFF STORE 49152 to I POKE I,0,17,2,0,14,37,205,5,0,201 * above line resets ONLY Drive B: SET CALL TO I CALL I SET CONS ON ? "SOFT Warm Boot on B:"+CHR(7) RETURN Explanations (of non-obvious lines, only): STORE 49152 TO I means variable I=C000h (dBASE2 reqires all decimals) POKE I,x,v,v,v,v,v,v,v,v,v (v=decimal value) The 'I' is the address at which the POKE is to store the following data. The 'x' can be any value. After the CALL, HL will point to a memory byte that will contain whatever value is in the 'x' position (could be length of string, if that is useful) The v,v,v,v are whatever routine you want to execute. After the CALL, the Program Counter is set to the first 'v'. The last 'v' must be a RETURN to your dBASE2 command file In the illustration: 17D = 11H = LXI D 2,0 = 02h = 0000$0000$0000$0010B (to reset Drive B:) 14D = 0EH = MVI C 37D = 25h = BDOS Function 37 (CP/M 2.2 only) 205D = CDh = CALL 5,0 = 0005= location 5 (i.e. CALL BDOS) 201D = C9h = RET (to dBASE2 cmd file) SET CALL TO I {that's how you call the POKED routine CALL I { RETURN returns to the main dBASE command file If anyone has an easier way of solving the problem, please post to net. Eric Stork <STORK@MC> 10-Jan-84 12:48:39-MST,1060;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 12:48:33-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Jan 84 20:57 EST Received: From Jpl-Vax.ARPA by BRL via smtp; 7 Jan 84 20:50 EST Date: 7 Jan 1984 1745 PST From: Bruce L. Conroy <BLC@jpl-vax> Subject: dBase Overlay file locations To: info-cpm@brl Cc: stork@mit-mc Reply-To: BLC@jpl-vax To set the drive where dBase looks for its overlay and message files there are two locations to patch. In version 2.03 there are two prototype file control blocks, which look like: 42cc 00 44 42 41 53 45 4d 53 47 43 4f 4d .DBASEMSGCOM 42ed 00 44 42 41 53 45 20 20 20 4f 56 52 .DBASE OVR Changing 42cc and 42ed to 03 causes dBase to look for the files on drive C. I have looked at later versions of dBase, and while the actual locations have been changed, all versions seem to have two of them, between 4200 and 4300, and the ASCII file names make them jump out on a DDT display. ------ 10-Jan-84 13:13:01-MST,2051;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 10 Jan 84 13:12:54-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Jan 84 21:39 EST Received: From Mit-Mc.ARPA by BRL via smtp; 7 Jan 84 21:30 EST Date: 7 January 1984 21:31 EST From: Eric Stork <STORK@mit-mc> To: info-cpm@brl cc: STORK@mit-mc Subject: Answer to my dBASE2 question The question was: Can someone tell me how to set up DBASE2.COM so that it can be permanently on Disk C:, and will find its overlay files on C: even if it is invoked from A: or B:? In WordStar there is a location to set for where to look for overlay files. Logically, there should be such a location in dBASE, too. Advice will be appreciated. Eric. Date: 7 Jan 1984 1745 PST Two suggestions were received, and are shared herewith: From: Bruce L. Conroy <BLC%JPL-VAX> Subject: dBase Overlay file locations Reply-To: BLC%JPL-VAX To set the drive where dBase looks for its overlay and message files, there are two locations to patch In version 2.03 there are two prototype file control blocks, which look like: 42cc 00 44 42 41 53 45 4d 53 47 43 4f 4d .DBASEMSGCOM 42ed 00 44 42 41 53 45 20 20 20 4f 56 52 .DBASE OVR Changing 42cc and 42ed to 03 causes dBase to look for the files on drive C. I have looked at later versions of dBase, and while the actual locations have been changed, all versions seem to have two of them, between 4200 and 4300, and the ASCII file names make them jump out on a DDT display. ------ ^_ Another solution: Date: Sat, 7 Jan 84 8:27:43 EST From: Rick Conn <rconn%brl> I got around it under ZCPR2 by creating a script command like the following: A:;dbase setup;B: In this way, I have all my work on B: and dbase.com and its overlays on A:. The command processor goes to A:, runs dbase, and the setup.prg file sets default to B:, so any files I reference come from B:. When done, the trailing B: puts me back into B:. Rick 11-Jan-84 18:52:36-MST,762;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 11 Jan 84 18:52:31-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 8 Jan 84 17:35 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 8 Jan 84 17:24 EST Date: Sun 8 Jan 84 14:28:22-PST From: Leslie Zatz <ZATZ@SUMEX-AIM.ARPA> Subject: UTILITIES WITH CPM1.4 To: INFO-CPM@BRL.ARPA Users of CPM 1.4 should be aware that while the MODEM7xx series supported 1.4, the MDM7xx series doess not, unffortunately. The NCATxx series indicates that ALLSR must be set false for CPM 1.4, but does not indicate that DSKFRE must also be set false. Unfortunately, this valuable program can not provide the free space left on disks in this mode. ------- 12-Jan-84 20:33:59-MST,1397;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 12 Jan 84 20:33:54-MST Received: From uw-vlsi-gw.ARPA by BRL-VGR via smtp; 8 Jan 84 15:27 EST Date: 8 Jan 1984 11:53:31-PST From: Ed Mills <capn@uw-vlsi> To: pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax Subject: My BIOS for the Ithaca Intersystems 2A. Cc: info-cpm@brl-vgr Mike, My BIOS is based on a copyrighted version distributed by Ithaca for their system 2A with floppy drives. I can't leagally send that to anyone who doesn't already have Ithaca's version. The version I started with is however 2 years out of date from their current version, so if you called them they might not object to my sending you a copy. You might also try offering them $10 - $20, they usually just bundle it in with their CP/M. I can send you more details before you write them a check. I have Cache BIOS version 4h. My current version is about 50-50 theirs and mine. Their number is 1-800-847-2088. The person to talk to is Tim Bond. If you just want to exchange ideas about what might belong in a BIOS, I would love to talk to people about that. Perhaps a new list is in order? I neglected to keep a listing of the description I sent to the net, so if you could send me a copy, I will fill in more details where that one left off. Ed Mills capn@uw-vlsi 12-Jan-84 20:51:20-MST,701;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 12 Jan 84 20:51:14-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 9 Jan 84 5:09 EST Received: From Sri-Unix.ARPA by BRL via smtp; 9 Jan 84 5:04 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Jan 84 1:54-PST Date: 6 Jan 84 20:17:38-PST (Fri) To: info-cpm@brl From: decvax!duke!mcnc!ncsu!ncrcae!jdg@ucb-vax Subject: 8748 Assembler wanted Article-I.D.: ncrcae.1046 I am looking for an 8748 assembler that will run under CP/M. Anyone knowing of such an assembler please let me know. Thanks. -----Jim Griggers duke!mcnc!ncsu!ncrcae!jdg 12-Jan-84 20:52:03-MST,497;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 12 Jan 84 20:51:59-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 9 Jan 84 5:19 EST Received: From Sri-Unix.ARPA by BRL via smtp; 9 Jan 84 5:17 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Jan 84 2:08-PST Date: 8 Jan 84 0:30:36-PST (Sun) To: info-cpm@brl From: decvax!duke!mcnc!ecsvax!hsplab@ucb-vax Subject: cancel ecsvax.1806 Article-I.D.: ecsvax.1807 12-Jan-84 21:33:03-MST,565;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 12 Jan 84 21:32:59-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 9 Jan 84 11:52 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 9 Jan 84 11:47 EST Date: Mon, 9 Jan 84 07:22 PST From: TAFEL.pasa@PARC-MAXC.ARPA Subject: Re: stork In-reply-to: "STORK@mit-mc.ARPA's message of 5 Jan 84 20:21 EST" To: Eric Stork <STORK@mit-mc.ARPA> cc: info-cpm@brl.ARPA If you set up ZCPR on your system you will be able to do this very easyly. Hugo. 13-Jan-84 18:55:51-MST,2465;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 18:55:44-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 9 Jan 84 5:19 EST Received: From Sri-Unix.ARPA by BRL via smtp; 9 Jan 84 5:17 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Jan 84 2:08-PST Date: 8 Jan 84 0:50:58-PST (Sun) To: info-cpm@brl From: decvax!duke!mcnc!ecsvax!hsplab@ucb-vax Subject: MITS 2SIO S-100 Board Information Article-I.D.: ecsvax.1808 Information about the MITS SIO board is available in the S-100 Bus Handbook by Dave Bursky. Unfortunately, I do not have information about the jumpers. Basically the board must be set up to occupy 4 ports in the IO space of the 8080. The even ports are for control and the odd ports are for data. There are two ports on the board. The board uses the Motorola 6850 UARTS and data can be obtained from those data sheets. Pins 3 and 4 on the 6850 are the receive and transmit clocks going into the chips. The initial setup must be done with jumpers and a counter on those pins will tell you the initial baud rate, the measured rate divided by 16. The following is an outline of the information accepted by the control port for the purposes of initializing the 6850: Bits 5,6,7 control the interrupt circuits. Since most CPM software handle this poorly, especially for Mits circuits, they should be set to all zeros to disable them. Bits 2,3,4 control the parity/frame size/stop bits bit 4 = 0 7 data bits; bit 4=1 8 data bits bit 3 = 0 2 stop bits; bit 3=1 1 stop bit bit 2 = 0 even parity; bit 2=1 odd parity exception: bits 4,3,2 = 100 8 bits, 2 stop bits, no parity 101 8 bits, 1 stop bit, no parity Bits 1,0 00 clock divide by 1 01 clock divide by 16 10 clock divide by 64 11 master reset Since the clock is 16 time the baud rate, the effect of a divide by 16 is to divide the baud rate by 2; divide by 64 divides the baud rate by 4. The initial clocks are set to one of eight rates between 110 and 9600. I do not think that there will be any problems with a 1200 / 300 baud scheme being proposed. David Chou University of North Carolina, Chapel Hill ...{mcnc,unc,duke}!ecsvax!hsplab 13-Jan-84 19:05:44-MST,2230;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:05:37-MST Received: From Sri-Nic.ARPA by BRL-VGR via smtp; 9 Jan 84 14:40 EST Received: from USC-ECL by SRI-NIC with TCP; Mon 9 Jan 84 11:42:14-PST Date: 9 Jan 1984 1140-PST From: STERNLIGHT%USC-ECL@sri-nic Subject: BYE with TRS-80 Models II/12/16 To: info-cpm@brl-vgr cc: sternlight@usc-ecl Due to mailer problems, this message may have been lost and is being resent. CP/M users of the TRS-80 Models II/12/16 with D.C. Hayes smartmodems can now use bye3-16 to set up bulletin board and downloading systems. Include b3sio-3.asm in the bye3-16.asm file as per instructions. Set BYELOW equal to NO. (For some reason, with BYELOW equal to YES, at the point where BYE wants to enter CP/M the system hangs, at least with Pickles and Trout CP/M 2.2m. If anyone figures out why, please let me know.) Set the other options as desired. In the sio section of the code, set the base port address to F4 (port A) or F6 (port B). (I do not know what value to use for the baud rate port, but it doesn't seem to matter if you use the setup menu of CP/M 2.2m to set the appropriate port at, say, 300 baud and leave it there.) (Again, if anyone figures that one out, please let me know.) After assembling the program move the COM file to A: drive. Make sure to rename the object code so that people don't type 'bye' in an attempt to log off and get the bye3 program instead; again the system will hang. Instead, create a short program called 'bye' which, when invoked, types 'please hang up now' over and over. Hanging up the remote line will cause bye3 to reset itself for the next call. Now reduce the size of your CP/M to leave room at the top of memory. With P&T CP/M 2.2m, the menu commands SC and LA will get you to the point where you can redefine the top of CP/M. I use EFFF with BYE3, instead of the default FFFF. After resetting the system according to the menu instructions and setting the desired port baud rate, you are ready to type the name of the bye3 program and you are in business. --david-- ------- 13-Jan-84 19:12:16-MST,1741;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:12:11-MST Received: From Usc-Isid.ARPA by BRL-VGR via smtp; 10 Jan 84 9:29 EST Date: 9 Jan 1984 21:12-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: How to use a TAC. From: ABN.ISCAMS@usc-isid To: towson@amsaa Cc: info-cpm@brl-vgr, info-micro@brl-vgr Message-ID: <[USC-ISID] 9-Jan-84 21:12:51.ABN.ISCAMS> In-Reply-To: The message of Fri, 6 Jan 84 9:28:54 EST from David Towson (CSD) <towson@amsaa> The TAC User Guide ain't so very small either! However I find it invaluable. I've also gained a certain amount of notoriety (justly so, I suppose) for "blowing up the TAC" as my local operators fondly call it -- by following instructions exactly (well, best as I can interpret them) for transferring binary (8-bit) files from our host (like .COM files at SIMTEL20) through the TAC to a micro. B O S and B I S (the commands to switch the TAC to binary mode don't work exactly as described -- mainly because some sort of bug (discussed elsewhere) won't permit the TAC to reset to its normal config- uration. We haven't found the bug, but I have finally discovered how to log back on to the TAC at another port (carefully writing down the number of the original port I jammed open), and resetting that jammed port. TAC operators are much relieved, they quit teasing me at parties, no more threats -- but don't have it all for certain yet. Once I figure it out, will put a wee little supplement out on the net. (For those poor souls with the same brain-damaged software on the host or TAC that causes that problem.) Regards, David Kirschbaum Toad Hall (HQ XVIII Abn Corps, Ft Bragg) 13-Jan-84 19:13:51-MST,1623;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:13:46-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Jan 84 9:40 EST Received: From Usc-Isid.ARPA by BRL via smtp; 10 Jan 84 9:30 EST Date: 9 Jan 1984 21:22-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: Church Support Software Distribution From: ABN.ISCAMS@usc-isid To: POURNE@mit-mc Cc: ABN.ISCAMS@usc-isid, INFO-CPM@brl Message-ID: <[USC-ISID] 9-Jan-84 21:22:01.ABN.ISCAMS> In-Reply-To: The message of 7 January 1984 03:54 EST from Jerry E. Pournelle <POURNE @ MIT-MC> Sirrah, Would be more than pleased to cooperate with fielding the Church Support software, and have no objections to someone making back their costs and time. HOWEVER... I have NO feedback from anyone in the world that it works! I have bitter, embarrassing experiences with my perfect programs that I can't crash for trying -- and then a buddy sits down and ties the entire bloody system into one horrible knot! Please hold on until I can get SOME kind of feedback (good or otherwise) so we can be sure we aren't ruining anyone's reputation (me too!) and wasting church members' time. And if ANYONE out there is actually running the program, how about some feedback, huh? Huh? (Cooperate, and you get a free copy of Toad Hall's world famous Kamikaze Ducks - the CP/M version of the Osborne magazine article and listing "DUCKS" - with operational divebombing ducks, droppings, the whole bit. Compiled, it becomes (of course) Hypersonic Ducks!) Regards, David Kirschbaum Toad Hall 13-Jan-84 19:15:07-MST,1406;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:15:00-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Jan 84 16:42 EST Received: From Hi-Multics.ARPA by BRL via smtp; 10 Jan 84 16:21 EST Date: 10 January 1984 08:52 cst From: Chan.CST@hi-multics Subject: buffer size in mdm716 To: info-cpm@brl Could someone verify that the buffer size for receiving file while in terminal mode is about 2K for mdm716 but it is about 16K for mdm715 and before? Why if it is true? This is the result that i got using identical overlay and procedure to generate the .com files. I have also observed some interesting phenomenon and would like to see whether others are having similar problem. I discovered that while receiving data in terminal mode with a mainframe (I tried both Multics and a Cyber -- same results), when the buffer is filled, mdm716 sent the XOFF to the mainframe, but then several characters following the XOFF would screw up. The interesting part was that they were turned into some sort of control characters, showing up when i used mince to look at it, e.g. "a" became "~a", "7" became "~7" etc. However, the file would look correct when I used Wordstar to examine it, or just "type" it, or send it back to the mainframe using the transmit mode in terminal mode. Is there an explanation? 13-Jan-84 19:15:49-MST,1784;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:15:43-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 11 Jan 84 4:40 EST Received: From Mit-Mc.ARPA by BRL via smtp; 11 Jan 84 4:30 EST Date: 11 January 1984 04:31 EST From: Jonathan W. Platt <JWP@mit-mc> Subject: CP/M Plus To: INFO-CPM@brl I am in the process implementing CP/M plus on a new micro being developed. I hope someone can answer a couple of questions. 1] The system manual says that the CSV and ALV, found in the drive's DPH can be in either bank 0 or bank 1 and yet there is no bank pointer for these. How do they know where it is? Do they check to see if the address is below common and assume bank 0 if it is? Could they possibly be placed in bank 2, say? I am disappointed that it looks like the BCBs have to be in common. I know the hash tables can be put anywhere, but is there a way to put the XLT, DIRBCB and DTABCB tables in another bank instead of common? In general, I think DR could have been a little more generous with bank pointers in their tables. You still need too much common if you are making a full system and have loads of tables to deal with. 2] The manual also says that a DRVTBL entry must be zero if the drive does not exist. Could I just fill in all 16 entries with the DPH addresses and have SELDSK return HL=0000 (as it normally would) if the drive doesn't exist? I'd like to set up all of the fixed tables in the BIOS ahead of time so that the system is easily and interactively expandable. Total flexibility is our theme for this project. 2B or D4, Jonathan Platt (JWP@MIT-MC) 13-Jan-84 19:16:43-MST,1193;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:16:38-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 11 Jan 84 6:09 EST Date: 11 January 1984 06:07 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: *** SOMEWHAT IMPORTANT on dBase2 ** To: w8sdz@brl cc: Info-Cpm@brl-vgr In-reply-to: Msg of Sat 7 Jan 84 15:35:13 EST from Keith Petersen <w8sdz at brl> Your RESETT fix for Dbase 2 uses CP/M function 37 Reset Disk. DO NOT USE THAT FUNCTION. Function 37 has a serous bug, undocumented, that can cause CP/M to write over the directories OF ALL DISKS it can get at, including the A: disk, hard disks, memory drive disks, etc. We do not know precisely what triggers the bug; it takes a reasonably complex pattern of disk changes and resets; but it DOES THE JOB. I know of three casees in which 10 megaByte hard disks had to have their files reconstructed sector by sector because they were bitten by CP/M FUNCTION 37. You must use RESET SYSTEM even though that logs you on to the A: drive (and takes longer). I repeat, DO NOT USE FUNCTION 37. You will regret it if you do. J E Pournelle 13-Jan-84 19:18:04-MST,4376;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:17:52-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 11 Jan 84 9:26 EST Date: Wed, 11 Jan 84 9:19:52 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: SD-79 now available SD version 7.9 is now available in SIMTEL20's MICRO:<CPM.DIRUTL> directory as SD-79.ASM, SD-79.COM, and SD-79.HEX. Sigi Kluger has added drive/user to the command-line option so that it's now possible to say: A>SD B7: to get the directory of drive B: user 7. Other recent changes are detailed later in this message. SD displays the directory of a CP/M disk, sorted alphabetically, with the file size in K, rounded to the nearest CP/M block size. Also displays library files with the file size in K if the '$L' option is used. Current versions of SD will automatically adjust for any block size and directory length under CP/M 1.4 or 2.x or MP/M (any version). They also automatically adjust for any number of disk drives and work sat- isfactory even if no disk is in that drive at the moment. Provisions are made for: (1) automatic pauses when the screen fills up (2) searching individual or multiple drives and/or user areas (3) unconditional or optionally resetting the disk system before execution begins (4) directing output to a disk file and appending to it on sub- sequent runs (5) summary line output giving drive and user information, # of files matched and how much space they consume, and the amount of free space remaining on the disk (6) displaying or suppressing "system" files (7) accepting ambiguous filenames with or without a drive name (8) printer output (9) can make a disk file of the results called SD.DIR (10) Horizontal or vertical sorting of filenames See SD-78.DOC for detailed instructions on configuring and running SD. ----- What's new in this, and the more recent previous versions: 12/30/83 - SD-79 - Added drive/user code (concurrent with $U). The routine FNAME was taken from Rick Conn's SYSLIB. (FNAME.MAC). Also fixed ^C bug. - S. Kluger 12/24/83 - SD-78 - Fixed file and printer output code to not place the reverse video sequences in file or on paper. Reverted back to old SD by renaming output file to SD.DIR. Deleted obsolete update comments prior to 10/1/83. - S. Kluger 11/20/83 - SD-77A - Removed 'BDOSPAG: DB BDOSPG' and relabeled BDOSPAG to BDOSPG elsewhere to conform to label used in initial equates. This will once again allow you to run BYELOW and use the 'DOPT'. This bug has existed since SD-71. - Loren Cook 11/07/83 - SD-77 - (1). Added DORST to allow option of always doing a disk reset if the D (all disk) option has been chosen on the command line. Thus if a disk has been withdrawn after the last warm boot, the program will not hang at the empty drive as the program automatically does the warm boot before reading the disk directories. An RCPM (have to think of them or incur a little criticism) or others with just a hard disk setup would set this equate to NO to prohibit the disk reset, but those using floppies should find it better than trying to remember to do a Ctl-C after removing a disk. Setting both AUTOR & DORST to YES will not result in a double disk reset, but will always do 1 reset. Setting just DORST to YES will force a reset ONLY when the D option is specified on the command line. (2). Eliminated label LLENLOT as it wasn't used for anything and caused a "Multiple Definition" error when assembling with RMAC. (3). Added code to always start search at user 0 when A option specified on command line. Now you can say: C3> SD filename $AD - to start at A0: or C3> SD filename $U2AD - to start at A2: Also note again, if NODISK is set to YES at assembly time, a drive does NOT have to be specified for the above command. (4). Fixed glitch which caused turn-up of 1 extra blank line when last library had a full line of member files. (5). Reinstated ability to limit $D option by specifying a starting drive. SD B: $D will now start searching on drive B. Note that SD $D will always start on drive A. - Dennis Vallianos --end-- 13-Jan-84 19:19:59-MST,1201;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:19:53-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 11 Jan 84 15:17 EST Received: From Mit-Mc.ARPA by BRL via smtp; 11 Jan 84 15:04 EST Date: 11 Jan 1984 14:42-EST From: Conal.Elliott@CMU-CS-CAD.ARPA Subject: atari <--> cpm question To: info-atari@su-score, info-cpm@mit-mc Message-Id: <442698124/conal@CMU-CS-CAD> It is possible to make CP/M readable files with an atari computer and disk drive, or alternately, to read an atari disk with a CP/M system, both without hardware modifications? Are the problems physical incompatability, or can they be bypassed with low-level software mucking about? (Both use soft-sectored 5 1/4 disks.) I have an atari 800 with an atari 810 and astra 1620 disk drives and Jack Palevich's "Chamelon" terminal program, and want to copy some of the archived public-domain CP/M software and send it to my younger brother, who uses a CP/M 2.2 based computer. Any suggestions would be greatly appreciated. - Conal P.S. I'm not on the info-cpm list, so any cp/m people, please respond directly to me. Thanks. 13-Jan-84 19:20:09-MST,1449;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:20:05-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 11 Jan 84 14:48 EST Received: From Hi-Multics.ARPA by BRL via smtp; 11 Jan 84 14:43 EST Date: 11 January 1984 13:39 cst From: Chan.CST@hi-multics Subject: buffer size in mdm716 To: info-cpm@brl Acknowledge-To: Chan.CST at HI-MULTICS Could someone verify that the buffer size for receiving file while in terminal mode is about 2K for mdm716 but it is about 16K for mdm715 and before? Why if it is true? This is the result that i got using identical overlay and procedure to generate the .com files. I have also observed some interesting phenomenon and would like to see whether others are having similar problem. I discovered that while receiving data in terminal mode with a mainframe (I tried both Multics and a Cyber -- same results), when the buffer is filled, mdm716 sent the XOFF to the mainframe, but then several characters following the XOFF would screw up. The interesting part was that they were turned into some sort of control characters, showing up when i used mince to look at it, e.g. "a" became "~a", "7" became "~7" etc. However, the file would look correct when I used Wordstar to examine it, or just "type" it, or send it back to the mainframe using the transmit mode in terminal mode. Is there an explanation? 13-Jan-84 19:22:04-MST,1110;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:21:59-MST Received: From Brl-Bmd.ARPA by BRL-VGR via smtp; 11 Jan 84 19:49 EST Date: Wed, 11 Jan 84 19:49:08 EST From: Charlie Strom (NYU) <strom@brl-bmd> To: Chan.CST@hi-multics cc: INFO-CPM@brl-vgr Subject: Re: buffer size in mdm716 You are quite correct that MDM716 has a 2K buffer rather than a 16K buufer. Being a devoted YAM user, I have not yet fiddled with 716, but there have been a number of complaints from users on Compuserve. I hope that Plouffe can advise us of the rationale for the change. The problem with extra characters (after buffer fill) that was determined to be a problem on CIS is that the routine used in MDM7 AFTER the buffer is filled does not strip parity, whereas the normal ASCII capture routine does. A simple fix would be to run the received file through PIP with the [Z] option set. Irv Hoff is hoping to release a new version fixing this. Of course you might tell your mainframe not to use parity if that is possible. 13-Jan-84 19:23:53-MST,1613;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:23:48-MST Received: From Brl-Bmd.ARPA by BRL-VGR via smtp; 11 Jan 84 21:53 EST Date: Wed, 11 Jan 84 21:40:07 EST From: Keith Petersen <w8sdz@brl-bmd> To: Charlie Strom (NYU) <strom@brl-bmd> cc: Chan.CST@hi-multics, INFO-CPM@brl-vgr Subject: Re: buffer size in mdm716 Please tell Irv Hoff that Bob Plouffe and Ron Fowler already have MDM717 "in progress" and we should have something forthcoming from them with these fixes in about a week. I'd hate to see all that good stuff that Bob Plouffe put in MDM716 "stripped out" by Irv "because he doesn't agree with it" or "doesn't like it". That's how we lost the "retry after ten errors" option, amoung other things. On the subject of the 2k buffer size. This is true ONLY for the protocol file transfer mode. It does not affect the terminal capture mode. It was done after NUMEROUS complaints from people with slower disk systems which took so long writing the 16k buffer out (and consequently closing that extent and opening the next in the directory) that they lost the next sector and several tries from the sender. In many cases this caused the transfer to abort. The 2k buffer was chosen MANY versions back (when the program was MODEM2) as an acceptable compromise between disk access speed and the improvement in receiving speed by putting the characters into the buffer instead of writing every sector (which was the way Ward Christensen's old original MODEM program worked) to the disk. 13-Jan-84 19:33:03-MST,978;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:32:59-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 12 Jan 84 6:16 EST Received: From Sri-Unix.ARPA by BRL via smtp; 12 Jan 84 6:08 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 12 Jan 84 2:56-PST Date: 10 Jan 84 5:50:09-PST (Tue) To: info-cpm@brl From: harpo!floyd!clyde!burl!ars@ucb-vax Subject: Terminal Emulator Program Wanted for DECmate II Article-I.D.: burl.396 I am looking for a Public Domain terminal program for the DECmate II. I am using the DECmate II with the cpm option. I have DEC's WPS communications package but that is of no help for uploading and downloading files to cpm. Any help would be appreciated. Thanks Allen R. Shuff -- 919-697-4339 (Cornet 292) ...![ floyd clyde ihnp4 mhuxv ]!burl!ars -- Allen R. Shuff -- 919-697-4339 (Cornet 292) ...![ floyd clyde ihnp4 mhuxv ]!burl!ars 13-Jan-84 19:37:18-MST,1314;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:37:14-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 12 Jan 84 8:46 EST Date: Thu, 12 Jan 84 8:38:14 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: Patching MDM716.ASM for Hayes result codes Date: 01/01/84 11:30:07 From: Bob Plouffe To: Frank Wancho Re: Patching MDM716 for Smart Modem result codes Regarding failure of MDM716 to go to terminal mode after dial commection is made, try changing the SMRESUL1 routine to the following code. I assume you are using a SmartModem which has both verbose and numeric result codes depending on how your modem switches are set. This code will work regardles which way the result code switch is set. I have it implemented this way in my version for the IBMPC and hadn't noticed that it wasn't implemented properly in MDM7xx. SMRESUL1: CALL IN$MODDATP ANI 7FH MOV B,A CPI 'C' JZ CONMADE1 CPI 1 JZ CONMADE1 CPI 'E' JZ GIVLF CPI 4 JZ GIVLF CPI 'N' JZ SMDM1 CPI 3 JNZ SMRESULT This should be a permanent change to MDM7xx and I will put it into the next release. In the meantime, perhaps it should be put on the nets as a patch. Bob Plouffe 13-Jan-84 19:44:10-MST,1879;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:44:04-MST Received: From Parc-Maxc.ARPA by BRL-VGR via smtp; 12 Jan 84 14:11 EST Date: Thu, 12 Jan 84 10:59 PST From: MMOON.ES@PARC-MAXC.ARPA Subject: Re: BIOS In-reply-to: "capn@uw-vlsi.ARPA's message of 8 Jan 84 11:53:31 PST" To: Ed Mills <capn@uw-vlsi.ARPA> cc: pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax.ARPA, info-cpm@brl-vgr.ARPA I would dearly like to see BIOS information put out in the public domain. While different hardware manufacturers have every right to copyright their particular code, I see no reason not to exchange ideas on the generalized techniques involved in a particular subroutine or task without the gory details of a peculiar implimentation. If the idea is one's own, of course the publishing of source code is a personal decision. It may be more appropriate to put the technique down in some form of pseudo-code since, CP/M is no longer tied to a small group of code-compatible processors. I feel this list is an appropriate forum, but would certainly add myself to any other on which the discussion took place. I will suggest a few topics I would like to see and participate in discussions on: 1)Interrupt drivers for anything, but particularly floppy controllers 2)Pointer interfaces, e. g., mice, touchpads, etc. 3)Bdos call trapping 4)Any public-domain LRU or other buffering techniques for flavors of CP/M which don't already employ the same Having a pool of techniques for even the more mundane and necessary stuff needed for baseline systems would be incredibly useful for those of us with the unstoppable urge to hack hardware, not to mention the poor people who can't get their manufacturer to supply BIOS source. I'll be watching this develop. MMoon.es 13-Jan-84 19:49:14-MST,636;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:49:11-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 12 Jan 84 17:49 EST Received: From Usc-Eclb.ARPA by BRL via smtp; 12 Jan 84 17:38 EST Date: 12 Jan 1984 1438-PST From: Dick <MEAD@usc-eclb> Subject: NSWP199H To: info-cpm@brl From reading the doc file on the 'LAST' update to a nice program, it looks as though SQ/USQ is supposed to work, but I have not been able to get the Squeeze functioon to work. All I get is the message, "can't squeeze yet" ... Is this never going to be fixed? ------- 13-Jan-84 19:50:43-MST,1241;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:50:37-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 12 Jan 84 9:02 EST Date: Thu, 12 Jan 84 8:48:41 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: MDM716 RV bug fix MDM716 has a problem when you try to "View" an incoming received ASCII file (.i.e., using the RV command). Dick Mead has found the problem and offers the fix below, which is easily done with DDT. After the patch, the View mode works but displays the sector headers in hex - apparently a problem with one of the View flags. This will be fixed in the next version. ---forwarded message-- Date: 5 Jan 1984 2246-PST From: Dick Mead Re: MDM716 RV bug fix To: Info-Modem7@MC In case no one else has had the time to look at the bug Keith pointed out with Receive View mode in MDM716, I seem to have stumbled across it. At label --> MONIN: POP PSW PUSH PSW CALL SHOW PUSH PSW <------this is the culprit I NOP'ed the byte and the RV mode works fine, this shows up as an F5 at location 2571H. Dick.... 13-Jan-84 19:51:07-MST,1322;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:51:03-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 12 Jan 84 19:01 EST Received: From Jpl-Vax.ARPA by BRL via smtp; 12 Jan 84 18:58 EST Date: 12 Jan 1984 1555 PST From: Bruce L. Conroy <BLC@jpl-vax> Subject: Use of dBase RESET function. To: info-cpm@brl Cc: stork@mit-mc Reply-To: BLC@jpl-vax Although there are some funny effects in dBase's RESET command I have found it to be 100% reliable under several versions of dBase if: a) Any files on the disk to be changed are closed (this is merely good practice in any event,) b) The disk is changed, then c) The command RESET (not RESET B) is given. In particular, this sequence avoids the following anomolies: a) RESET B or RESET B: or any similar command seems to have no effect whatever. b) As long as a data file is open, there is an unpredicable amount of data in memory, which is not on disk. If the disk is changed at this point these data are lost, unless c) There is a file of the same name on the new disk, in which case, the extra data are stuffed into that file, resulting in the loss of the integrity of both data files. ------ 13-Jan-84 19:53:44-MST,907;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:53:40-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 12 Jan 84 20:23 EST Received: From Mit-Mc.ARPA by BRL via smtp; 12 Jan 84 20:17 EST Date: 12 January 1984 20:17 EST From: Eric Stork <STORK@mit-mc> To: info-cpm@brl cc: STORK@mit-mc Subject: Need MODEM7xx for EAGLE A friend of mine has an EAGLE z-80, cp/m 2.2, 5" drive. He needs MODEM7xx, prferably set up for SModem (Hayes). If you can help, pls respond direct to me and i'll get you together with him. Or, if you're in LAX areea, give him a call direct. His name: Ernie Rosenberg, home:(213)501-0756 (yes, really 501-) office:(213)486-6098. Ernie and I want to communicate by modem, but until he has MODEM7xx, we can't begin and I can't help him because I'm 8" CP/M. Thanks for any help, Eric. 13-Jan-84 19:55:08-MST,524;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:55:05-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 12 Jan 84 20:44 EST Received: From Mit-Mc.ARPA by BRL via smtp; 12 Jan 84 20:37 EST Date: 12 January 1984 20:22 EST From: Eric Stork <STORK@mit-mc> To: info-cpm@brl Subject: Correction re EAGLE MODEM7xx need. The guy who needs the MODEM7xx for the CP/M Eagle, Ernie R, is at (213)501-0736, NOT 0756 as I said before. Sorry Eric 13-Jan-84 19:56:34-MST,1302;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:56:30-MST Received: From Usc-Isid.ARPA by BRL-VGR via smtp; 12 Jan 84 22:34 EST Date: 12 Jan 1984 13:55-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: My BIOS for the Ithaca Intersystems 2A. From: ABN.ISCAMS@usc-isid To: capn@uw-vlsi Cc: pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax Cc: info-cpm@brl-vgr Message-ID: <[USC-ISID]12-Jan-84 13:55:15.ABN.ISCAMS> In-Reply-To: The message of 8 Jan 1984 11:53:31-PST from Ed Mills <capn@uw-vlsi> Reference exchanging ideas about what might belong in a BIOS... I too am very interested, since I dearly love hacking about in my own Morrow Decision I CBIOS&. I understand the copyright problem (and agree with something like a BIOS), but I wonder what the ethical (and maybe legal) line is on sending parts of one to show how something is done, or to show the environment in whichd a particular hack fits. Like, if I invent a new wonderful I/O procedure, or how to set parity or something -- can I show the "before" and "after" without upsetting someone? Anyone know the legal niceties about this? Or a net opinion on the ethics? Would be glad to summarize. David Kirschbaum Toad Hall (ABN.ISCAMS@USC-ISID) 13-Jan-84 19:58:10-MST,1422;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 13 Jan 84 19:58:06-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 12 Jan 84 22:36 EST Received: From Usc-Isid.ARPA by BRL via smtp; 12 Jan 84 22:34 EST Date: 12 Jan 1984 14:03-PST Sender: ABN.ISCAMS@usc-isid Subject: SPELL and its DICT.DIC From: ABN.ISCAMS@usc-isid To: INFO-CPM@brl Message-ID: <[USC-ISID]12-Jan-84 14:03:31.ABN.ISCAMS> You all may know SPELL (a nice public domain spelling checker) and an ITS-binary format dictionary, DICT.DIC are out on SIMTEL20 under MICRO:<CPM.SPELL>SPELL.(MAC, COM).1 and DICT.DIC.1 If you have a particularly brain-damaged TAC like mine, you may find it difficult to download an 8-bit binary file to your micro. And if you lost the pointers to a particular utilityl on TOPS-20 (I think) that converts ITS-Binary files to regular 8-bit binary (by stripping off the first 32-bit word, I guess), you may find it even harder to get that DICT.DIC to run! I solved both problems, and if anyone wants a (somewhat lengthy) How To (right down at the novice, how to figure SAVE pages in DDT, level) -- message me. Don't want to inflict it on the net. If the SIMTEL20 MICRO: Sysop is out there, and if there's enough interest in this, maybe you'd like to put it in the <CPM.SPELL> directory. David Kirschbaum Toad Hall (ABN.ISCAMS@USC-ISID) 16-Jan-84 09:41:54-MST,2750;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:41:38-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 15 Jan 84 11:40 EST Date: Sun, 15 Jan 84 11:26:18 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: Function 37 disk reset and dBase With all the discussion about CP/M's function 37 disk reset, I thought a review of the following file, UNDOCCPM.DOC, might be useful. It's likely that function 37 causes any open files to be closed and then when DBASE writes to the file it THINKS is still open, it causes CP/M to write the data to the directory tracks. The solution, of course is to tell DBASE to close the files first before doing the reset. --Keith ----- August 12, 1982 TO: All CP/M assembly programmers FROM: Thomas Hill 200 Oklahoma Anchorage, Ak. 99504 (907) - 337-1984 SUBJECT: Undocumented CP/M BDOS Features Just a short note to aquaint you with an "undocumented feature" I have encountered in the CP/M 2.2 BDOS. While developing an assembly program which read and wrote disk files, an early version did not open the output file before writing to it. Oddly enough, the BDOS accepted the write and did not return an error condition. Being a curious soul (and cautious), I sidetracked to investigate this effect. A call to Digital Research resulted in a letter informing me that they knew of the effect and told me it was an "undocumented feature" of CP/M. They also told me that it was the programmer's responsibility to open and close his files properly, to which a heartily agree. However. I wrote some test programs to determine WHERE on the disk the information was going, and WHAT happened to the valid data on the disk. Writing to an unopened file apparently writes information beginning at Group 0, sector 1 and continues in a sequential manner thru the allocation map. (I lost three directories that way). No change is made in the allocation map, however, and the only change in the File Control Block is the Current Record and Next Record fields are incremented. NO CHANGE occurs in the FCB allocation map. While it is, of course, the programmer's responsibility to control the file accesses, and proper opening and closing is mandatory, in some cases (particularly during program development), proper file access may not take place. If this occurs, a possible loss of data may result. There may be a BDOS patch which will clear this up, or someone out there may already have one. If anyone knows more about this, I would appreciate it if you would drop me a line at the above address. Thanks, Thomas Hill 16-Jan-84 09:43:16-MST,451;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:43:00-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 15 Jan 84 16:32 EST Received: From Mit-Mc.ARPA by BRL via smtp; 15 Jan 84 16:17 EST Date: 15 January 1984 16:20 EST From: Richard P. Wilkes <RICK@mit-mc> Subject: Remove from list To: info-cpm@brl Please remove RICK at MIT-MC from the CPM list. Thanks. -r 16-Jan-84 09:43:56-MST,791;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:43:48-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 11 Jan 84 21:27 EST Date: 11 Jan 1984 19:25 MST (Wed) Message-ID: <WANCHO.11982890842.BABYL@SIMTEL20> From: "Frank J. Wancho" <WANCHO@simtel20> To: INFO-CPM@brl-vgr Subject: Lots of new files available! With the help of Bill Westfield's NMODEM (in batch upload mode) AND Bob Plouffe's ruggedized MDM716, our operator, Dave Tapia, was able to finally upload (with CRCs checked), all the remaining SIG/M volumes on hand. This brings our online collection to 213 disk volumes: SIG/M #000 - 145 (MICRO:<SIGM.VOLnnn>) CPMUG #001 - 054 (MICRO:<CPMUG.VOLnnn>) #078 - 090 Enjoy! --Frank 16-Jan-84 09:44:00-MST,487;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:43:55-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 15 Jan 84 20:21 EST Received: From Bnl.ARPA by BRL via smtp; 15 Jan 84 20:15 EST Date: 14-Jan-84 00:59:54-EST From: jpm@bnl Subject: January Byte To: info-cpm@brl, info-micro@brl Did anybody get their copy of the January Byte yet? Is it just very late this month, or did Los Angeles get left out? 16-Jan-84 09:45:18-MST,580;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:45:15-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 15 Jan 84 20:21 EST Received: From Bnl.ARPA by BRL via smtp; 15 Jan 84 20:15 EST Date: 14-Jan-84 23:57:01-EST From: jpm@bnl Subject: Byte finally showed up To: info-micro@brl, info-cpm@brl Cc: jpm@BRL.ARPA I want to thank the 10 or so people who told me the status of their January issue of Byte. I just got mine today. It seems that the west coast was just a bit late in getting theirs. 16-Jan-84 09:48:20-MST,3229;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:48:10-MST Received: From Sri-Nic.ARPA by BRL-VGR via smtp; 16 Jan 84 2:42 EST Received: from USC-ECLB by SRI-NIC with TCP; Sun 15 Jan 84 23:42:02-PST Date: 15 January 1984 23:36-PST (Sunday) Sender: TLI@usc-eclb From: Tony Li <Tli@usc-eclb> To: Info-Cpm@brl-vgr Subject: Function 37 Reply-to: Tli@usc-eclb Home: 1275 W. 29th #211, Los Angeles, Ca. 90007 (213) 737-8168 All right, if were really going to discuss this, let me give you a copy of my source. The following is the description of Function 37 from the CCP/M-86 manual. Admittedly, this isn't the same as the CP/M 2.2 filesystem, but I would be surprised if there were any significant differences. Anyhow: ---------------------------------------------------------------------- DRV_RESET Reset Specified Disk Drives Entry Parameters: Register CL : 025H (37) DX : Drive Vector Returned Values: AL : Return Code BL : Same as AL The DRV_RESET system call is used to programmatically restore specified removable media drives to the reset state (a reset drive is not logged in and is in Read-Write status). [Presumably there are no files open on a drive which is not logged in. - Tony] The passed parameter in register DX is a 16-bit vector of drives to be reset, where the least significant bit corresponds to drive A, and the high-order bit corresponds to the sixteenth drive, labelled P. Bit values of 1 indicate that the specified drive is to be reset. Refer to Section 2.17 [CCP/M-86 1.0 Programmers Guide] for more information regarding the use of this system call. This system call is conditional under Concurrent CP/M-86. If another process has a file open on any of the drives to be reset, the DRV_RESET system call is denied, and none of the drives are reset. Upon return, if the reset operation is successful, DRV_RESET sets register AL to 00H. Otherwise, it sets register AH to 0FFH. If the BDOS Error mode is not in Return Error mode (refer to the F_ERRMODE system call), the system displays an error message at the console identifying the process owning the first open file that caused the DRV_RESET request to be denied. ---------------------------------------------------------------------- Section 2.17 goes on to stipulate that "If all the open files on a removable drive belong to the calling process, the process is said to 'own' the drive. In this case, the file system performs a qualified reset on the drive and returns a successful result. This means that the next time a process accesses this drive, the BDOS performs the log-in operation only if it detects a media change on the drive." ---------------------------------------------------------------------- Conclusion: In the safest case, one should close all files before performing a DRV_RESET. However, if you do not, and your BIOS is somewhat flakey about detecting a media change (or your hardware is), you might not get the reset. This would probably result in destruction of the newly inserted media, as has been described by JEP. Cheers, Tony ;-) 16-Jan-84 09:50:04-MST,979;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:49:56-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 13 Jan 84 2:42 EST Received: From Sri-Unix.ARPA by BRL via smtp; 13 Jan 84 2:36 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 12 Jan 84 23:24-PST Date: 6 Jan 84 13:25:48-PST (Fri) To: info-cpm@brl From: hplabs!sdcrdcf!trw-unix!scgvaxd!ns05040@ucb-vax Subject: problem with async i/o on Big Board (HELP!) Article-I.D.: scgvaxd.159 I have recently built a Big Board and I am attempting to use it as a teminal (initially) to our UNIX system. I have had some difficulty understanding Zilog's documentation on the Z80 SIO as evidenced by the fact I cannot get either SIO A or B to give me anything on a write other than transmit data overrun?? If anyone has any experience with this particular system I sure would like to here from you. thanks Norm Scherer 16-Jan-84 09:50:20-MST,1036;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:50:14-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 13 Jan 84 9:01 EST Date: Fri, 13 Jan 84 8:52:01 EST From: "Richard G. Turner" <rturner@brl> To: info-cpm@brl Subject: BYE3 -- KayPro II Gentlefolken, I'm relatively new to the CP/M world, and even though I have made my living as a programmer at times, I'm over the hill, so to speak, as a hacker. I'd like to hear (directly, not to tie up this list) from anyone who has a similar configuration to mine, or as close as possible: KayPro II [CP/M 2.2] Hayes Smartmodem 300 Epson look-alike printer I'm especially interested in hearing from anyone who has gotten BYE3 to work in this configuration. I can get BYE to answer the modem, but the system turns into a pumpkin after that. I have been reasonably successful with some of the public domain software at SIMTEL20; MODEM716 runs great guns! Thanks, rick 16-Jan-84 09:50:58-MST,2976;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:50:49-MST Received: From Brl-Voc.ARPA by BRL-VGR via smtp; 13 Jan 84 9:46 EST Date: Fri, 13 Jan 84 9:36:31 EST From: "Ferd Brundick (LTTB)" <fsbrn@brl-voc> To: Mike Simpson <msimpson@bbn-unix>, Pete Criqui <ihnp4!hlhop!pcc@ucb-vax> cc: info-micro@brl-vgr, info-cpm@brl-vgr Subject: Re: WordStar printer questions Hi, There are at least 4 ways that you can get Word* to print special characters and control sequences -- 1. Install your own routines in ^Q, ^W, ^E, ^R and ribbon change. If you modify the ribbon change sequence (I use it to turn off enhanced printing) you can patch the help file as well so that the NoFile Menu has the correct prompt. This method only works for very short sequences. 2. Write your own printer driver and install it in WS. There are a few control chars that WS doesn't use, and your driver could use these as special flags to change the meaning of the next char(s). For example, ^]A could mean "print an Alpha", ^]B --> print a Beta, etc. 3. Write the same printer driver but install it in your CBIOS. This is a bit more involved (depending on whether or not you have a source listing) but has the advantage that all programs that talk to your printer would be able to use the special chars/features. This is the method that I prefer and am slowly working on. A recent issue of MicroSystems had an article/program that used this technique. 4. Write a new utility program that prints WS files (instead of using WS's print routine). This would be a large program and something that you would probably not do Except for the fact that it has already been done. The January 84 issue of Interface Age has an article in MBASIC (plus a small assembler sbr to send chars to the printer) that uses true proportional spacing to print a WS file. Of course it also can also access your printer's special abilities as well, but does not print non-ASCII chars. I have begun converting this program into 8080 assembler for 3 reasons: a) It only prints 8 lines per minute b) I think the author made 2 major mistakes c) I don't have MBASIC. The author does mention that he is also rewriting it in assembler. If anyone else "out there" is pursuing a project such as this I would be interested in hearing from you. I have a NEC PC-8001 and 8023 printer. The MicroSystems article was written for a North*/8023 combo and the IA article is for the ProWriter printer. The 8023 and ProWriter are different versions of the same basic dot-matrix printer made by TEC, as are a printer by Panasonic and the (newest?) Apple printer. dsw, fferd Fred S. Brundick USABRL, APG, MD. <fsbrn@brl-voc> 16-Jan-84 09:51:48-MST,1012;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:51:36-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 13 Jan 84 12:58 EST Received: From Usc-Isid.ARPA by BRL via smtp; 13 Jan 84 10:59 EST Date: 13 Jan 1984 07:57-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: buffer size in mdm716 From: ABN.ISCAMS@usc-isid To: Chan.CST@hi-multics Cc: info-cpm@brl Message-ID: <[USC-ISID]13-Jan-84 07:57:34.ABN.ISCAMS> In-Reply-To: The message of 11 January 1984 13:39 cst from Chan.CST@hi-multics Ref the little ~ character showing up sometimes in MDM716 -- I see the same thing in my earlier MDM's, and also in KERMIT and other terminal programs. Not all the time - just under certain conditions. It doesn't show up in my files, but appears to be something that went up to the host and echoed back to me. I believe I can delete it up on the host. Donno what it is - but appears to be harmless. David Kirschbaum Toad Hall 16-Jan-84 09:54:56-MST,551;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:54:53-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Jan 84 6:33 EST Received: From Mit-Mc.ARPA by BRL via smtp; 16 Jan 84 4:42 EST Date: 16 January 1984 04:46 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: Byte finally showed up To: jpm@bnl cc: info-cpm@brl, info-micro@brl, jpm@brl In-reply-to: Msg of 14-Jan-84 23:57:01-EST from jpm at bnl Heck I GOT MY BYTE for Jan on Saturday 14 Jan! Ye gods. 16-Jan-84 09:56:37-MST,970;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:56:33-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Jan 84 6:07 EST Date: Sat, 14 Jan 84 0:51:13 EST From: Keith Petersen <w8sdz@brl> To: Richard G. Turner <rturner@brl> cc: Info-Cpm@brl-vgr Subject: Re: BYE3 -- KayPro II Get BYE3-17.ASM and the BY2SMDM something file (I forget it's name) from the SIMTEL20 MICRO:<CPM.BYE3> directory. This version fixed a problem in 3-16 that's probably causing it not to run on your system. If you like MDM716, you'll love MDM717. You can get it from SIMTEL20 Monday, or if you want it earlier you can FTP it from MIT-MC. It's in the following files there: FJW;MDM717 ASM FJW:MDM717 COM FJW:MDM717 HEX FJW:MDM717 MSG Suggest you read the MSG file first. You don't need the ASM file to make it run, as you know. You can use your present overlay file. 16-Jan-84 09:56:57-MST,4065;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:56:45-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Jan 84 6:07 EST Date: Sat, 14 Jan 84 0:55:01 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: Hoff notes on MDM717 update Forwarded message from Irv Hoff to Dave Hardy and myself... --- 01/12/84 Hi Dave / Keith Here is MDM717 as promised. Took longer than I had planned. Paul Grupp was telling me about a problem with the "V" flag. Took me most of the day to track that down as it was actual a dual problem. (1) stack problem in the MOmin area and (2) a DATAFLG problem in the RCVCHR area that took quite awhile to track down. That one caused the results with "V" to be similar to those with "R" and showed the non-ASCII characters as (0D) hex characters when it wasn't supposed to. The stack problem of course just bombed things. Dave Mabry also pointed out a problem with the LOGON message being inconsistent at times. (I had noticed that also but rarely use it and did not get around to tracking down the problem until yesterday. I am pretty sure that is solved now, I can't get it to act up any more on several different systems, and don't see how it can, now. The main thing I got into MDM717 for was to fix a problem the fellows are having on Compuserve with "save to disk". Since many do not have BUFEXC or CSEXEC, they just download ASCII files directly to disk (and take their changes on no errors). But MDM716 was saving to disk every 2k (instead of every 16k like I had it set for, Plouffe changed that, it's now back to 16k with a note to leave it that way for distribution copies and if an individual user wants to change it later, fine.) When set for 2k the problem during transfer to disk was aggravated badly. I was stripping off parity from incoming characters but failed to also do that during the time we picked up propagation delayed characters re- ceived after an X-off. It was very simple to fix with an ANI 7FH in the INMODEM area. Then started finding things that needed to be done with MDM716. Now I did not change anything Plouffe did, basically. I was going to, then decided against it. All I really did was add an option to use what he has now for GETACK, or with ACKNAK set to "normal ('YES') for RCPM, it resends the sector immediately on any non-ACK. Since XMODEM will time out with 10 errors, we do not ask if you want to "try again" after you get 10 errors - knowing that XMODEM has already terminated the file transfer at the RCPM end. But with ACKNAK set for ARPANET to "NO", you only resend a file with a valid NAK. This can take up to about 1-1/2 minutes the way Plouffe re-did the GETACK area, for each error. After 10 errors, it THEN asks you if you want to continue. So think we have the best of both worlds, now, and Plouffe should be happy, and I guess I am too. It's all automatic, with how you set the equate at ACKNAK. That about takes care of things. With any luck, this version will last 3-4 days before Sigi Kluger or somebody decides to take yet another crack at it. It is possibly my last effort at MDM7-anything. My next "big deal" is going to be called either "MU-1" or "MC-1" or "MCU-1" have not made up my mind yet. Will support RCPM and CIS protocols, and include BUFEXC as part of the program. Will be a little more along the lines of YAM, perhaps. Only assembly level source. This is already on several west coast systems now. These systems are so private the three big ones in this area are talking about going re- stricted on users. Maybe something along the lines of what Gary Shaffstall is doing in Denver or even Jud Newell. Hate to see that, but it is getting impossible to get on some of these at all, without calling on the voice line and making a schedule. Auto-dial would be nice, but one hates to work that hard to give programs away! Best regards, Irv 16-Jan-84 09:57:08-MST,485;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:57:05-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Jan 84 6:08 EST Received: From Bnl.ARPA by BRL via smtp; 14 Jan 84 0:55 EST Date: 14-Jan-84 00:59:54-EST From: jpm@bnl Subject: January Byte To: info-cpm@brl, info-micro@brl Did anybody get their copy of the January Byte yet? Is it just very late this month, or did Los Angeles get left out? 16-Jan-84 09:57:42-MST,3678;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:57:32-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Jan 84 6:08 EST Date: Sat, 14 Jan 84 0:56:03 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: MDM717.MSG TOPIC: MDM717.ASM MODEM PROGRAM FROM : IRV HOFF W6FFC DATE : 11 JAN 84 NOTE: This program when assembled is 69 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 MDM717 use: B>SAVE 69 MDM717.COM NOTE: If using the phone number overlay to change the phone library numbers, be sure to use: ORG 0D00H Most users will not need the lengthy (152k) source code at all. Just get MDM717.COM and then check one of the associated over- lay programs to obtain the overlay for your particular computer. Merge that with MDM717.COM according to the instructions near the start of the overlay file, using DDT.COM, etc. (See above note relative to saving 69 sectors. STAT.COM would then show 138 records for 18k.) CURRENT CHANGES FOR MDM717 -------------------------- MDM717 allows characters with parity bit set to be properly handled during propagation overruns after an X-off. This occurs during a "save to disk" after the disk buffer fills. (This problem was noticed on Com- puserve which sends some characters with the parity bit set.) The disk buffer size was restored to 16k. This is the length of "one file extent". Even slow floppy disks can store 16k in a reason- able amount of time. This should remain 16k for distribution copies of the source code although it can be easily changed to suit the individual user's own preference. (It could even be lengthened to 32k if you like fewer disk operations. This would make the printer buffer proportion- ally smaller but most printers are so fast the buffer is rarely filled in any case.) Fixed a stack problem introduced in v716 in the "V" flag routine to allow the user to show ASCII characters on the CRT during a file trans- fer. Fixed the "L" Logon feature so it should be consistent. At times it would run away without waiting for the echo characters, thus not cor- -rectly displaying the Logon message. Restored the ACKNAK feature developed for the exclusive use of the ARPANET networking group. When set normal ("YES") it resends a disk re- cord after any NON-ACK character is received. This has been the normal configuration for all RCPM systems using the XMODEM file transfer pro- gram. When set "NO" for ARPANET use, it resends a record only after a NAK has been received. Other characters are ignored. Some systems will resend a NAK after a 10-second TIMEOUT. This slows things considerably, which allows the main frame time to recover if busy. This tends to run the phone bill higher for RCPM use, but is necessary for ARPANET to pre- vent aborting the file transfer too quickly if the main frame is busy. If a normal TIMEOUT sequence does attempt to abort the transfer with the ACKNAK equate set to NO, it will ask if you want to try again or abort. (RCPM systems would have already timed completely out with 10 consecutive errors, making the question worthless and misleading. ARPANET does not have a similar feature, and the user can manually force the transfer to continue.) - Irv Hoff 16-Jan-84 09:58:46-MST,816;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:58:33-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Jan 84 6:09 EST Received: From Mit-Mc.ARPA by BRL via smtp; 14 Jan 84 4:32 EST Date: 14 January 1984 04:35 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: Use of dBase RESET function. To: BLC@jpl-vax cc: STORK@mit-mc, info-cpm@brl In-reply-to: Msg of 12 Jan 1984 1555 PST from Bruce L. Conroy <BLC at jpl-vax> I warn you: use of DR CP/M Function 37 "reset disk" can be hazardous to your disk directory. The exact sequences that can trigger the bug are not known; but it exists, it's real, it jumps out and bites you, and you cannot know that it won't since we don't know how it does it. You are warned. 16-Jan-84 09:58:49-MST,1468;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:58:38-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 16 Jan 84 6:36 EST Date: 16 January 1984 05:15 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: My BIOS for the Ithaca Intersystems 2A. To: MMOON.ES@parc-maxc cc: ABN.ISCAMS@usc-isid, pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax, capn@uw-vlsi, info-cpm@brl-vgr In-reply-to: Msg of Fri 13 Jan 84 12:08 PST from MMOON.ES at PARC-MAXC.ARPA under copyright and patent law, ideas and concepts are not protectable, but specific implementtions are. plaguarism can be brought in for sufficient similarities even though the language is not identical: if plot and characters are essentially the same, juries may and have found plagiarism. Dunno if that helps. Date: Fri, 13 Jan 84 12:08 PST From: MMOON.ES at PARC-MAXC.ARPA To: ABN.ISCAMS at usc-isid.ARPA cc: capn at uw-vlsi.ARPA, pur-ee!uiucdcs!parsec!ctvax!uokvax!andree at ucb-vax.ARPA, info-cpm at brl-vgr.ARPA Re: My BIOS for the Ithaca Intersystems 2A. Don't know the legaliteis, etc., but I know of no manufacturer who ever published pseudo-code. Can we translate the particular impilmentation of an algorithm, then communicate it? Can common sense guidlines work here? Anyone with legal credentials listening? MMoon.es 16-Jan-84 09:59:54-MST,954;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 09:59:49-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 16 Jan 84 6:36 EST Date: 16 January 1984 04:58 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: BDOS Function 37 possible bug. To: Tli@usc-eclb cc: Info-Cpm@brl-vgr In-reply-to: Msg of 14 Jan 1984 23:11-PST () from Tony Li <Tli at usc-eclb> Dear Mr. Li: Perhaps you know best. Me, I will not use Fn 37; I have seen too many disk directories trashed. Re: how, it is NOT triggered ONLY by writing to improperly opened/closed files. There is NO (known to me) simple algorithm for preventing the fn 37 bug from biting you, even taking meticulous care. Or so say several sources I trust. You are welcome to continue using fn 37 with its undocumented features. My apologies for bringing up the subject. I really ought to know better by now. JEP 16-Jan-84 10:04:15-MST,784;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:04:11-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Jan 84 12:32 EST Received: From Mit-Mc.ARPA by BRL via smtp; 14 Jan 84 12:22 EST Date: Sat 14 Jan 84 12:23:58-EST From: Mark Becker <CENT.MBECK%MIT-OZ@MIT-MC.ARPA> Subject: No January BYTE here either.. To: INFO-CPM@BRL.ARPA, INFO-MICRO@BRL.ARPA In response to jpm@bnl'l s message, I haven't received January's issue of Byte either (I'm in Maryland). BUT I SURE HAVE SEEN IT IN THE STORES!! EVEN THE GIANT GROCERY HAS IT ON THE SHELF!!! Ah, for the days when being a subscriber meant you got your issue before the stores or corner newstand did.... Mark ------- 16-Jan-84 10:05:45-MST,1025;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:05:40-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Jan 84 13:34 EST Received: From Sri-Unix.ARPA by BRL via smtp; 14 Jan 84 13:20 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 14 Jan 84 10:14-PST Date: 13 Jan 84 6:50:14-PST (Fri) To: info-cpm@brl From: decvax!duke!mcnc!pbr@ucb-vax Subject: Re: Heath/Zenith microcomputers Article-I.D.: mcnc.1923 In-Reply-To: Article <106@5941ux.UUCP> I have been waiting for a Heathkit computer that runs UNIX ever since I heard about their UNIX software group in Benton Harbor. Can anyone tell me *if* there is a UNIX/Heathkit system anywhere, *why* there isn't one (if there isn't), and/or what those UNIX programmers in Benton Harbor have been doing for the past three years! I suspect that there are such systems, but that most Heathkit catalog readers will buy the Heathkit OS, if that is all they see in the catalog. 16-Jan-84 10:06:56-MST,4171;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:06:45-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Jan 84 13:44 EST Received: From Sri-Unix.ARPA by BRL via smtp; 14 Jan 84 13:33 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 14 Jan 84 10:24-PST Date: 12 Jan 84 6:28:27-PST (Thu) To: info-cpm@brl From: decvax!duke!mcnc!ecsvax!mjg@ucb-vax Subject: CP/M Disk Formats Article-I.D.: ecsvax.1847 Help wanted on compiling CPM disk format data ! ----------------------------------------------- This is a follow up to my last follow up requesting help on compiling a data base of cp/m disk formats. Because of the minimal of response I wonder just how many CP/M users really KNOW what their own disk format is. I am still trying to compile information and have got quite a lot from other sources. So far I am up to about 30 formats and am willing to share this with anyone who can make a positive contribution. I need information in one of the following forms: 1) A freshly formatted disk with a single reasonably sized text file on it. The file must be large enough to span at least 2 tracks. This is sufficient to extract all the parameters below. After analyzing I will return the original untarnished!. 2) The alternative, if you can provide it is to provide me with the following data: Computer Make and Model No. Disk Size, 5 or 8 (or 3 1/4 or 3 1/2!) inch Is the format one or two side Single or Double Density? No of tracks, e.g. 35,40,77,80 etc. Sector Size in Bytes. Physical sector sequence on the disk. This is needed for optimum formatting. 8 inch SS,SD for instance has the sectors numbered 1,2,3,4,5........26. Sector translate table. This tells the bios when you ask for a given sector number what actual sector to give. 8 inch SS,SD has a table that starts 1,7,13,..... Directory offset. This tells CPM what track the directory is on. Directory size in sectors, bytes and number of files. Sectors per track. Some of the above information is contained in a standard CP/M DPB table in your BIOS in the following format, ( I will give the numbers for standard SS,SD 8 inch as an example): SPT 1A00 (no of equivalent 128 byte sectors/track) BSH 03 (Block Shift = Log base 2 of block size in sectors) BLM 07 (Block mask = no of 128 bytes in block - 1) EXM 00 (Extent mask, relates disk size and block size) DSM F200 (Highest block number on disk - 1 ) DRM 3F00 (No of entries in directory -1 ) ALO C000 (Each bit set in ALO represents 1 block in the directory) CKS 1000 (No of 128 byte sectors in directory ) OFF 0200 (Directory offset in tracks) >From the above the block size is 8 128 byte sectors or 1k, the directory 2 and occupies 16 sectors or 2 blocks with 64 entries max. Note that 2 byte values are expressed least significant byte first. If you dont know how to determine the parameters of your cpm format here is a simple way using DDT or SID: Run DDT or SID and enter the following: DDT SID A100 A100 100 MVI C,1F 100 LD C,1F 102 CALL 5 102 CALL 5 105 RST 7 105 RST 38 then type a period (.) to get out of the Assembler mode. What you have just done is create a small CPM program which will use your CP/M to find its own DPB (device parameter block). Run the program by typing G100 and display the CPU registers by typing X. The address of the DPB is in the HL register pair. Type D and the address to display the contents of memory starting at the beginning of the DPB and read off the first 15 bytes which is the DPB for the currently selected drive. Please reply to me here at ecsvax!mjg by computer mail, or Mike Gingell, PO Box 51155, Raleigh, NC 27609 or by phone (out of work hours 919-847-4779). Regards to all CPM users out there wherever you are, Mike Gingell, PO Box 51155 Raleigh NC 27609 ....ecsvax!mjg 16-Jan-84 10:07:09-MST,936;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:07:04-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Jan 84 13:44 EST Received: From Sri-Unix.ARPA by BRL via smtp; 14 Jan 84 13:35 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 14 Jan 84 10:17-PST Date: 11 Jan 84 19:34:34-PST (Wed) To: info-cpm@brl From: decvax!duke!mcnc!ncsu!ncrcae!jdg@ucb-vax Subject: ISIS to CP/M copy program Article-I.D.: ncrcae.1047 Does anyone know of an MDS to CP/M disk copy utility that is public domain (free)? Both MDS and CP/M disks are single density IBM format. Also, has anyone written an ISIS emulation program such that ISIS files could be executed under CP/M. I know of at least one company that sells such a program for about $80, but I don't know how well it works. -----Jim Griggers duke!mcnc!ncsu!ncrcae!jdg 16-Jan-84 10:08:29-MST,3840;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:08:17-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Jan 84 13:55 EST Received: From Mit-Mc.ARPA by BRL via smtp; 14 Jan 84 13:49 EST Date: 14 January 1984 13:52 EST From: Eric Stork <STORK@mit-mc> To: info-cpm@brl cc: STORK@mit-mc, POURNE@mit-mc, W8SDZ@mit-mc SUBJECT: RESETT for dBASEII; Function #37 of BDOS A few days ago, I submitted to the net a trick for POKEing an ass'y routine from dBASEII and a specific illustration that I had successfully used to solve a problem for a friend's accounting system. The illustration POKEd a routine utilizing BDOS Function #37 (reset an individual disk) and then CALLed that routine with a RETurn to the dBASE .CMD file. Jerry Pournelle has vigorously warned against using BDOS function #37. His warnings are reproduced below. For me, it worked. But Jerry may be right. Two more points: 1. At the end of Jerry's warning notes, a note from Bruce Conroy suggesting an alternate way of resetting dBASEII disks. I have not tried, but will next time I need this function. 2. If someone from DRI reads this and can shed more light on the validity of the concerns that Pournelle has about BDOS Function 37, I for one would be eager to know what he/she has to say. Eric ************************************************************** Date: 14 January 1984 04:35 EST From: Jerry E. Pournelle Subject: Use of dBase RESET function. I warn you: use of DR CP/M Function 37 "reset disk" can be hazardous to your disk directory. The exact sequences that can trigger the bug are not known; but it exists, it's real, it jumps out and bites you, and you cannot know that it won't since we don't know how it does it. You are warned. Date: 11 January 1984 06:07 EST From: Jerry E. Pournelle Subject: *** SOMEWHAT IMPORTANT on dBase2 ** Your RESETT fix for Dbase 2 uses CP/M function 37 Reset Disk. DO NOT USE THAT FUNCTION. Function 37 has a serous bug, undocumented, that can cause CP/M to write over the directories OF ALL DISKS it can get at, including the A: disk, hard disks, memory drive disks, etc. We do not know precisely what triggers the bug; it takes a reasonably complex pattern of disk changes and resets; but it DOES THE JOB. I know of three casees in which 10 megaByte hard disks had to have their files reconstructed sector by sector because they were bitten by CP/M FUNCTION 37. You must use RESET SYSTEM even though that logs you on to the A: drive (and takes longer). I repeat, DO NOT USE FUNCTION 37. You will regret it if you do. J E Pournelle Date: 12 Jan 1984 1555 PST From: Bruce L. Conroy Subject: Use of dBase RESET function. Although there are some funny effects in dBase's RESET command I have found it to be 100% reliable under several versions of dBase if: a) Any files on the disk to be changed are closed (this is merely good practice in any event,) b) The disk is changed, then c) The command RESET (not RESET B) is given. In particular, this sequence avoids the following anomolies: a) RESET B or RESET B: or any similar command seems to have no effect whatever. b) As long as a data file is open, there is an unpredicable amount of data in memory, which is not on disk. If the disk is changed at this point these data are lost, unless c) There is a file of the same name on the new disk, in which case, the extra data are stuffed into that file, resulting in the loss of the integrity of both data files. ************************************************************** 16-Jan-84 10:08:59-MST,872;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:08:53-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Jan 84 15:20 EST Date: Sat, 14 Jan 84 14:59:51 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: Using MDM717 with Cromemco CDOS CDOS users: Get M7CD-1.ASM, the overlay for Cromemco systems. After you overlay MDM717.COM using DEBUG, patch the following locations to NOPs (binary zeros): 2A8F, 2A90, 2A91, 2A92. This will disable the CP/M disk stat call function 1Fh which is not implemented in the current version of CDOS. The MDM717 DIR function will then work, but will show 0k left on the disk. That's livable, and certainly better than before when CDOS gave an error message and jumped out of MDM717 to return to the system. --Keith 16-Jan-84 10:09:46-MST,796;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:09:38-MST Received: From Parc-Maxc.ARPA by BRL-VGR via smtp; 14 Jan 84 18:26 EST Date: Fri, 13 Jan 84 12:08 PST From: MMOON.ES@PARC-MAXC.ARPA Subject: Re: My BIOS for the Ithaca Intersystems 2A. In-reply-to: <[USC-ISID]12-Jan-84 13:55:15.ABN.ISCAMS> To: ABN.ISCAMS@usc-isid.ARPA cc: capn@uw-vlsi.ARPA, pur-ee!uiucdcs!parsec!ctvax!uokvax!andree@ucb-vax.ARPA, info-cpm@brl-vgr.ARPA Don't know the legaliteis, etc., but I know of no manufacturer who ever published pseudo-code. Can we translate the particular impilmentation of an algorithm, then communicate it? Can common sense guidlines work here? Anyone with legal credentials listening? MMoon.es 16-Jan-84 10:10:03-MST,966;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:09:58-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Jan 84 23:32 EST Received: From Hi-Multics.ARPA by BRL via smtp; 14 Jan 84 23:27 EST Date: 14 January 1984 22:25 cst From: Chan.HCSCAD@hi-multics Subject: Re: No January BYTE here either.. To: Mark Becker <CENT.MBECK%MIT-OZ@mit-ml> cc: info-cpm@brl In-Reply-To: Message of 14 January 1984 13:42 cst from Mark Becker I just got mine . But I had the same problem last month (DEC issue) and I actually called BYTE subscription. The lady who answered my call said that their policy is not to do anything until about 15 days after the month (I forgot the exact number of days she said). Call back after the 15th, in essential.. I have been thinking of canceling my subscriptin and just go out to buy one on the 1st of every month. Maybe we all should do that. 16-Jan-84 10:10:36-MST,1473;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:10:29-MST Received: From Sri-Nic.ARPA by BRL-VGR via smtp; 15 Jan 84 2:19 EST Received: from USC-ECLB by SRI-NIC with TCP; Sat 14 Jan 84 23:18:24-PST Date: 14 January 1984 23:11-PST (Saturday) Sender: TLI@usc-eclb From: Tony Li <Tli@usc-eclb> To: Info-Cpm@brl-vgr Subject: BDOS Function 37 possible bug. Reply-to: Tli@usc-eclb Home: 1275 W. 29th #211, Los Angeles, Ca. 90007 (213) 737-8168 Hi, You requested someone from DRI? As far as I know, I'm the only one from DRI who is on ARPA at all, much less reading Info-Cpm. Anyhow, despite what Jerry Pournelle has to say, I know nothing of a BDOS bug in function 37. Now, you should realize that I'm probably not the best person to ask. I'm a summer intern at DRI, and as such, don't deal with CP/M-80 to any extent. So if there is a bug, there is a VERY good chance that I wouldn't know about it. A better idea: Is there anyone who reads this list who works for an OEM who buys stuff from DRI? If so, said person could holler at his sales rep/tech support person from DRI. If this doesn't work, I do have some alternate methods for getting an exact answer, but they're somewhat rash, and I'm reluctant to use them. Cheers, Tony Li ;-) Software Engineer Systems Software Group Digital Research Inc. aka Tony Li <Tli@Usc-Eclb> Univ. of Southern Ca. 16-Jan-84 10:14:11-MST,867;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:14:07-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Jan 84 6:34 EST Received: From Mit-Mc.ARPA by BRL via smtp; 16 Jan 84 4:57 EST Date: 16 January 1984 05:00 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: No January BYTE here either.. To: Chan.HCSCAD@hi-multics cc: info-cpm@brl, CENT.MBECK%mit-oz@BRL.ARPA In-reply-to: Msg of 14 Jan 1984 22:25 cst from Chan.HCSCAD at hi-multics The problem is the Post Office, which in Dec/Jan treats BYTE like a catlogue, which, I suppose, it resembles... We make more from copies sold in stores than from subs (I think, I may be wrong there; marketing doesn't talk to contributing editors much). But heck, I can't even get copies sent first class on time. Sigh. JEP 16-Jan-84 10:19:55-MST,865;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:19:52-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Jan 84 8:53 EST Received: From Nosc-Cc.ARPA by BRL via smtp; 16 Jan 84 8:37 EST Received: by Nosc.ARPA (4.12/4.7) id AA06672; Mon, 16 Jan 84 05:39:49 pst Date: Sun, 15 Jan 84 09:59:50 pst From: bang!bblue@nosc Message-Id: <8401161339.AA06672@Nosc.ARPA> To: ksproul@rutgers Subject: BREAK Cc: info-cpm@brl, info-micro@brl Keith, unfortunately, zok@ucb-vax is right about the break, even though he called it a character. The Anchor XII will not send the space state required as a break, even when the space state is correctly sent to it by the serial interface. I tried it on that modem because I didn't believe it at first either! May I echo his sentiments... 16-Jan-84 11:53:17-MST,554;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 11:53:14-MST Received: From Amsaa.ARPA by BRL-VGR via smtp; 16 Jan 84 12:50 EST Date: Mon, 16 Jan 84 12:35:06 EST From: David Towson (CSD) <towson@amsaa> To: Tli@usc-eclb cc: Info-Cpm@brl-vgr Subject: Re: Function 37 Tony - I was very surprised to see that you consider it the responsibility of the BIOS to detect a disk-change. I should think that would be an OS chore. Comment ? Dave towson@amsaa 16-Jan-84 12:29:16-MST,635;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 12:29:13-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Jan 84 13:40 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 16 Jan 84 13:22 EST Date: Mon, 16 Jan 84 09:37 PST From: MMOON.ES@PARC-MAXC.ARPA Subject: Re: January Byte In-reply-to: "jpm@bnl.ARPA's message of 14 Jan 84 00:59:54 EST" To: jpm@bnl.ARPA cc: info-cpm@brl.ARPA, info-micro@brl.ARPA Know of 1 OC resident who got his 13-Jan; haven't checked our tech lib yet, but mine's not here. Microsystems is also late. MMoon.es 16-Jan-84 13:10:16-MST,2087;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 13:10:04-MST Received: From Sri-Nic.ARPA by BRL-VGR via smtp; 16 Jan 84 14:22 EST Received: from USC-ECLB by SRI-NIC with TCP; Mon 16 Jan 84 11:21:59-PST Date: 16 January 1984 11:17-PST (Monday) Sender: TLI@usc-eclb From: Tony Li <Tli@usc-eclb> To: Jerry E. Pournelle <POURNE@mit-mc> Cc: Info-Cpm@brl-vgr Reply-to: Tli@usc-eclb Subject: BDOS Function 37 possible bug. Home: 1275 W. 29th #211, Los Angeles, Ca. 90007 (213) 737-8168 In-reply-to: The message of 16 Jan 1984 04:58 EST from Jerry E. Pournelle <POURNE @ MIT-MC> Date: 16 January 1984 04:58 EST From: Jerry E. Pournelle <POURNE @ MIT-MC> To: Tli @ USC-ECLB cc: Info-Cpm @ BRL-VGR Re: BDOS Function 37 possible bug. Return-path: <POURNE@MIT-MC> Received: from MIT-MC by USC-ECLB; Mon 16 Jan 84 01:59:12-PST Dear Mr. Li: Perhaps you know best. As I stated directly in my first comment. I DO NOT KNOW BEST. I DO NOT KNOW CP/M-80 EVENT TO THE EXTENT THAT THE READERS OF THIS LIST DO. Me, I will not use Fn 37; I have seen too many disk directories trashed. You may be right. If indeed there is a bug, I would like to know about it. Bugs should be common knowledge. When DRI finds out about a bug, it publishes a small in-house sheet, and then considers it a feature. Re: how, it is NOT triggered ONLY by writing to improperly opened/closed files. There is NO (known to me) simple algorithm for preventing the fn 37 bug from biting you, even taking meticulous care. Or so say several sources I trust. May we talk to the sources? I'm sure that the net would appreciate more info on the problem. You are welcome to continue using fn 37 with its undocumented features. My apologies for bringing up the subject. I really ought to know better by now. Yup, you're right. We've argued before Jerry, and we've never gotten anywhere but flaming. Cheers, Tony ;-) 16-Jan-84 13:15:53-MST,1341;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 13:15:46-MST Received: From Sri-Nic.ARPA by BRL-VGR via smtp; 16 Jan 84 14:24 EST Received: from USC-ECLB by SRI-NIC with TCP; Mon 16 Jan 84 11:23:54-PST Date: 16 January 1984 11:20-PST (Monday) Sender: TLI@usc-eclb From: Tony Li <Tli@usc-eclb> To: David Towson (CSD) <towson@amsaa> Cc: Info-Cpm@brl-vgr Reply-to: Tli@usc-eclb Subject: Function 37 Home: 1275 W. 29th #211, Los Angeles, Ca. 90007 (213) 737-8168 In-reply-to: The message of Mon 16 Jan 84 12:35:06 EST from David Towson (CSD) <towson@amsaa> Date: Mon, 16 Jan 84 12:35:06 EST From: David Towson (CSD) <towson@amsaa> To: Tli@usc-eclb cc: Info-Cpm@brl-vgr Re: Function 37 Return-path: <towson@amsaa> Received: from AMSAA by USC-ECLB; Mon 16 Jan 84 09:37:31-PST Tony - I was very surprised to see that you consider it the responsibility of the BIOS to detect a disk-change. I should think that would be an OS chore. Comment ? Hi Dave, As you must realize, detection of a disk-change is actually a hardware function. The little microswitch on the disk drive door is usually the mechanism. It is, of course, up to the BIOS to pass this along to the OS. Cheers, Tony ;-) 16-Jan-84 13:26:59-MST,523;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 13:26:56-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Jan 84 14:26 EST Received: From Usc-Eclb.ARPA by BRL via smtp; 16 Jan 84 14:14 EST Date: 16 Jan 1984 1110-PST From: Dick <MEAD@usc-eclb> Subject: DRC's Solid State Disk query To: info-cpm@brl Has anyone used the Digital Research Computers 256k S-100 Solid State Disk?? Any comments pro/con? Bugs? Compatibility problems? ------- 16-Jan-84 14:03:26-MST,668;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 14:03:17-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Jan 84 15:08 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 16 Jan 84 15:02 EST From: dgilbert.es@PARC-MAXC.ARPA Date: 16 Jan 84 11:59:12 PST Subject: CP/M Fn 37? To: INFO-CPM@brl.ARPA cc: DGILBERT.ES@PARC-MAXC.ARPA Having not used function 37, I have a dumb question. Are we only talking about MP/M or CP/M86 systems when referring to fn. 37? David Cortesi, in 'INSIDE CP/M' says fn. 37 is for MP/M only, not CP/M 2.2. Is David wrong about this too??? Doug. 16-Jan-84 14:04:36-MST,732;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 14:04:31-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 16 Jan 84 15:16 EST Date: Mon 16 Jan 84 13:16:11-MST From: Keith Petersen <KPETERSEN@SIMTEL20.ARPA> Subject: New VAX/VMS XMODEM program To: Info-Cpm@BRL-VGR.ARPA XMODEM.FOR for VAX/VMS has been updated to XMODEM2.FOR in the SIMTEL20 MICRO:<CPM.VAXVMS> directory. Thanks to Charles Horn and Dennis Recla for the fix which repairs a bug in the command line search when the R mode is used. If there was an S in the extension then it would try to send a file instead of receive. Previously it searched for the S command first. --Keith ------- 16-Jan-84 15:35:31-MST,945;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 15:35:27-MST Received: From Amsaa.ARPA by BRL-VGR via smtp; 16 Jan 84 17:01 EST Date: Mon, 16 Jan 84 16:47:20 EST From: David Towson (CSD) <towson@amsaa> To: Tli@usc-eclb cc: David Towson (CSD) <towson@amsaa>, Info-Cpm@brl-vgr Subject: Re: Function 37 Tony - It is my understanding that CP/M-80 detects a disk change by noting that the directory information that has been read from the "first" disk no longer matches the information read from the "second" disk, and that when this happens we get the familiar (although usually unwelcome) message "BDOS ERROR R/O", and the system must be reset. Is this not so ? Second question: If a given drive does have the door switch, and I want to have my BIOS pass the information from this switch to CP/M, what should the BIOS put where ? Dave 16-Jan-84 15:49:46-MST,1730;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 15:49:41-MST Received: From Sri-Nic.ARPA by BRL-VGR via smtp; 16 Jan 84 17:15 EST Received: from USC-ECLB by SRI-NIC with TCP; Mon 16 Jan 84 14:13:41-PST Date: 16 January 1984 14:08-PST (Monday) Sender: TLI@usc-eclb From: Tony Li <Tli@usc-eclb> To: David Towson (CSD) <towson@amsaa> Cc: Info-Cpm@brl-vgr Reply-to: Tli@usc-eclb Subject: Function 37 Home: 1275 W. 29th #211, Los Angeles, Ca. 90007 (213) 737-8168 In-reply-to: The message of Mon 16 Jan 84 16:47:20 EST from David Towson (CSD) <towson@amsaa> Date: Mon, 16 Jan 84 16:47:20 EST From: David Towson (CSD) <towson@amsaa> To: Tli@usc-eclb cc: David Towson (CSD) <towson@amsaa>, Info-Cpm@brl-vgr Re: Function 37 Return-path: <towson@amsaa> Received: from AMSAA by USC-ECLB; Mon 16 Jan 84 13:57:58-PST Tony - It is my understanding that CP/M-80 detects a disk change by noting that the directory information that has been read from the "first" disk no longer matches the information read from the "second" disk, and that when this happens we get the familiar (although usually unwelcome) message "BDOS ERROR R/O", and the system must be reset. Is this not so ? I think that that's exactly correct. Just one question: How often does CP/M-80 read the directory? I don't know. As I said, I'm not an expert on CP/M-80. Second question: If a given drive does have the door switch, and I want to have my BIOS pass the information from this switch to CP/M, what should the BIOS put where ? I don't know. I haven't done it. Cheers, Tony ;-) 16-Jan-84 17:54:01-MST,440;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 17:53:57-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Jan 84 19:36 EST Received: From Mit-Ml.ARPA by BRL via smtp; 16 Jan 84 19:36 EST Date: 16 January 1984 19:34 EST From: Herb Lin <LIN@mit-ml> Subject: PD programs to do file compares... To: info-cpm@brl are there any? names, etc? tnx. 16-Jan-84 19:17:01-MST,1702;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 19:16:51-MST Received: From Dec-Marlboro.ARPA by BRL-VGR via smtp; 16 Jan 84 20:58 EST Date: 16 Jan 1984 2052-EST From: "Ted Hess" <THESS@dec-marlboro> To: Tli@usc-eclb, towson@amsaa cc: Info-Cpm@brl-vgr Subject: Re: Function 37 Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11984195593.16.555.24503 at DEC-MARLBORO> Regarding: Message from Tony Li <Tli@usc-eclb> of 16-Jan-84 1708-EST Folks - CP/M-80 & CP/M-86 will read a directory whenever: 1) You open a file 2) Close a file 3) Do a directory operation like delete, rename etc... 4) The first disk i/o performed (on each drive) after "warm boot","disk reset", or ^C (which causes warm boot). 5) Every time you do I/O to a file across a 16K boundary (ie 16K := 1 extent). NOTE: No matter what block size or disk organization you use, this is one of CP/M's natural (and most inefficient) constants. Oh yes, CCP/M gets around this by using an LRU disk cache and expecting the BIOS to inform it that a drive door changed state. The unfortunate fact about this feature is that it is very difficult to flush these buffers from inside an application. It seems that CCP/M won't flush the buffers and mark them invalid if there are any files open on that drive. The problem, I suppose is to prevent a disk change while a file is open, however, I don't think anything is being gained by preventing an application from trying to guarantee all the data it has modified (including the directory itself), be up to date! Sorry, didn't mean to flame CCP/M - It's really quite nice. /ted -------- 16-Jan-84 19:38:43-MST,1702;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 19:38:32-MST Received: From Dec-Marlboro.ARPA by BRL-VGR via smtp; 16 Jan 84 21:10 EST Date: 16 Jan 1984 2052-EST From: "Ted Hess" <THESS@dec-marlboro> To: Tli@usc-eclb, towson@amsaa cc: Info-Cpm@brl-vgr Subject: Re: Function 37 Message-ID: <"MS10(2124)+GLXLIB1(1136)" 11984195593.16.555.24503 at DEC-MARLBORO> Regarding: Message from Tony Li <Tli@usc-eclb> of 16-Jan-84 1708-EST Folks - CP/M-80 & CP/M-86 will read a directory whenever: 1) You open a file 2) Close a file 3) Do a directory operation like delete, rename etc... 4) The first disk i/o performed (on each drive) after "warm boot","disk reset", or ^C (which causes warm boot). 5) Every time you do I/O to a file across a 16K boundary (ie 16K := 1 extent). NOTE: No matter what block size or disk organization you use, this is one of CP/M's natural (and most inefficient) constants. Oh yes, CCP/M gets around this by using an LRU disk cache and expecting the BIOS to inform it that a drive door changed state. The unfortunate fact about this feature is that it is very difficult to flush these buffers from inside an application. It seems that CCP/M won't flush the buffers and mark them invalid if there are any files open on that drive. The problem, I suppose is to prevent a disk change while a file is open, however, I don't think anything is being gained by preventing an application from trying to guarantee all the data it has modified (including the directory itself), be up to date! Sorry, didn't mean to flame CCP/M - It's really quite nice. /ted -------- 16-Jan-84 20:26:36-MST,603;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 20:26:32-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Jan 84 22:13 EST Date: Mon, 16 Jan 84 22:10:31 EST From: Rick Conn <rconn@brl> To: Herb Lin <LIN@mit-ml> cc: info-cpm@brl Subject: Re: PD programs to do file compares... The ZCPR2 utilities COMPARE and DIFF are for file compare. COMPARE simply tells you if two files are the same, and DIFF lists differences in decimal, hex, and ASCII. SIMTEL20 has these in the ZCPR2 archives. Rick 17-Jan-84 08:50:41-MST,558;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:50:37-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Jan 84 23:14 EST Received: From Cmu-Cs-A.ARPA by BRL via smtp; 16 Jan 84 23:13 EST Date: 16 Jan 84 2310 EST (Monday) From: George.Wood@cmu-cs-a To: jpm@bnl, info-cpm@brl Subject: Re: January Byte In-Reply-To: "MMOON.ES@PARC-MAXC.ARPA's message of 16 Jan 84 12:37-EST" Message-Id: <16Jan84.231006.GW90@CMU-CS-A> My Jan. Byte's not here either. Dr.Dobbs is, though. 17-Jan-84 08:50:50-MST,788;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:50:44-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Jan 84 23:25 EST Date: Mon, 16 Jan 84 23:25:30 EST From: Keith Petersen <w8sdz@brl> To: Herb Lin <LIN@mit-ml> cc: Info-Cpm@brl-vgr Subject: Re: PD programs to do file compares... COMPARE.COM compares any CP/M files and aborts when it comes to a difference. DF.COM compares two ASCII files and prints the differences to the console. HEXDIF.COM compares any two CP/M files (binary or ASCII) and prints the addresses and the byte values in HEX and ASCII (if printable). All are available on SIMTEL20. Get MICRO:<CPM>CPM.CRCLST for a complete listing of what's available. 17-Jan-84 08:51:01-MST,1271;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:50:55-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 17 Jan 84 0:11 EST Date: 17 January 1984 00:10 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: Function 37 To: towson@amsaa cc: Tli@usc-eclb, Info-Cpm@brl-vgr In-reply-to: Msg of Mon 16 Jan 84 16:47:20 EST from David Towson (CSD) <towson at amsaa> It is not required that you RESET the system if the BIOS is properly written, but you will have to do a ^c warm boot if you have changed disks; R/O actually means that the bit map doesn't match t he current directory entries. As to BIOS detecting door opening, on 5 1/4" disks there is no hardware detect is there? Nor do I know a way to detect whether a door HAS BEEN OPENED although you can have (and my BIOS does) a look at the door to see if it is open NOW and put up a message like "Load Drive A" or "Please close Door" or some such; I recall startling some Morrow and Compupro troops a couple of years ago by inviting them over to the house and showing them I could access non-existent disks, open doors, or anything else, and recover from it. But that was before fn 37, which can have unrecoverable errors. 17-Jan-84 08:51:11-MST,469;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:51:06-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 17 Jan 84 0:24 EST Date: 17 January 1984 00:23 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: BDOS Function 37 possible bug. To: Tli@usc-eclb cc: Info-Cpm@brl-vgr In-reply-to: Msg of 16 Jan 1984 11:17-PST () from Tony Li <Tli at usc-eclb> Please continue to use the feature. 17-Jan-84 08:51:21-MST,959;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:51:16-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 17 Jan 84 0:27 EST Received: From Mit-Mc.ARPA by BRL via smtp; 17 Jan 84 0:24 EST Date: 17 January 1984 00:20 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: CP/M Fn 37? To: dgilbert.es@parc-maxc cc: INFO-CPM@brl In-reply-to: Msg of 16 Jan 84 11:59:12 PST from dgilbert.es at PARC-MAXC.ARPA CP/M 2.2 The confusion happens because many of the older CP/M manuals, including alas the one distributed with Compupro CP/M 2.2 systems, stop with Function 36 and do not even mention 37-40. Fn 37 returns a 0 in A to be compatible with MP/M Incidenteally Tony installed CP/M 8/16 tonight with a new Compupro hard disk. I love it. Huge TPA even with 8-bit stuff since all the CP/M goo is in memory above 64K and the 8088 handles disk ops fast fast fast... 17-Jan-84 08:51:32-MST,719;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:51:27-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 17 Jan 84 0:34 EST Date: 17 January 1984 00:32 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: Function 37 To: Tli@usc-eclb cc: Info-Cpm@brl-vgr In-reply-to: Msg of 15 Jan 1984 23:36-PST () from Tony Li <Tli at usc-eclb> wearily I repeat: under circumstances not known to me, but which have happened to Systems Interface Consultants, Proteus Engineering, and other correspondents, fn 37 can wipe out the diredctory of a HARD (not removable) disk. This is an interesting feature. May you have many interesting features. 17-Jan-84 08:51:45-MST,1310;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:51:39-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 17 Jan 84 1:22 EST Received: From Mit-Mc.ARPA by BRL via smtp; 17 Jan 84 1:11 EST Date: 17 January 1984 01:08 EST From: Robert L. Plouffe <PLOUFF@mit-mc> Subject: mdm716/mdm717 BUGS? To: INFO-MODEM7@mit-mc, INFO-CPM@mit-mc, INFO-CPM@brl, INFO-MODEMXX@simtel20 1. "Mea Culpa" on stack imbalance at label MONIN: Thanks to Dick Mead for finding that one. that got in there. 2. Data capture buffer is NOT affected by fifer size. It uses all of memory up to the CCP or optionally can ehe CCP. The 2k floppies. 16k of buffering does not buy anythingfile transfer speed. Try it both ways and you will see for yourseason for SECTORnot upsetting the protocol when a file transfer i a remote that is under BYE and the 'Q' switch is not set so thatreporting is seethe ACKNAK flag and has nothing to do with ARPANEt this is slightly different from the original CHRISTENSEN protocompletely compator upon a 10 sec timeout. 4. Sorry for delay inall of the discue Country for 10 days and just returned. 5. In vve discussion, arce code to give a 2k file transfer buffer AND thCKNAK flag to penly (or timeout).. 17-Jan-84 08:51:57-MST,1899;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:51:50-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 17 Jan 84 1:23 EST Received: From Mit-Mc.ARPA by BRL via smtp; 17 Jan 84 1:18 EST Date: 17 January 1984 01:15 EST From: Robert L. Plouffe <PLOUFF@mit-mc> Subject: mdm716/mdm717 bugs? To: INFO-MODEM7@mit-mc, INFO-CPM@mit-mc, INFO-CPM@brl, INFO-MODEMXX@simtel20 1. "Mea Culpa" on stack imbalance at label MONIN: Thanks to Dick Mead for finding that one. I don't know how that got in there. 2. Data capture buffer is NOT affected by file transfer buffer size. It uses all of memory up to the CCP or optionally can even overwrite the CCP. The 2k size recommendation has to do with the slowness of floppies. 16k of buffering does not buy anything with respect to file transfer speed. Try it both ways and you will see for yourself. 3. The reason for SECTOR_RESEND_ON_VALID_NAK only has to do with not upsetting the protocol when a file transfer is being made FROM a remote that is under BYE and the 'Q' switch is not set so that full progress reporting is seen at both ends. Thus is the reason for killing the ACKNAK flag and has nothing to do with ARPANET. I realize that this is slightly different from the original CHRISTENSEN protocol, but it is completely compatible with it. So in MDM716, repeats are done only if a valid NAK is received or upon a 10 sec timeout. 4. Sorry for delay in responding to all of the discussion of the past week or so, but I was out of the Country for 10 days and just returned. 5. In view of the above discussion, and if you use MDM717 as released by HOFF, I recommend the you modify the source code to give a 2k file transfer buffer AND that you set the ACKNAK flag to permit resending of sectors upon receipt of valid NAK only (or timeout).. 17-Jan-84 08:52:08-MST,1103;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:52:03-MST Received: From Mit-Multics.ARPA by BRL-VGR via smtp; 17 Jan 84 3:51 EST Date: Tuesday, 17 January 1984 03:48 est From: Schauble@MIT-MULTICS.ARPA Subject: Function 37 - disk door open To: info-cpm@BRL-VGR.ARPA, POURNE@MIT-MC.ARPA Message-ID: <840117084842.884899@MIT-MULTICS.ARPA> Some disk drives (my Qume DT8's for example) have a "disk change" line on the interface. This is driven by a flip-flop that is set when the door is open and reset when the drive is unselected while ready. If you select the drive and find -ready, there is presently not a disk in it. If you find it ready and disk change, someone changed the disk while you weren't looking. I don't know about the existance of this feature on 5 inch disks. I do know that the IO driver discriptions for MS/DOS document an entry point for "is this disk changed since the last I/O operation" that can return "yes", "no", or "I don't know". So I suspect that it occurs on 5 inch disks also. 17-Jan-84 08:52:29-MST,815;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:52:22-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 17 Jan 84 3:58 EST Received: From Sri-Unix.ARPA by BRL via smtp; 17 Jan 84 3:56 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 17 Jan 84 0:39-PST Date: 15 Jan 84 16:55:17-PST (Sun) To: info-cpm@brl From: harpo!eagle!mhuxl!aluxe!lra@ucb-vax Subject: spell program in C Article-I.D.: aluxe.1274 Does anyone have a public domain "spell" program written in 'C'? I would like to put it up on my Apple with Aztec 'C'. If one exists, would the kind person bless net.sources with it. I'm sure this would be of general interest. Thanks.. Lonnie R. Abelbeck AT&T Bell Laboratories ..{mhuxh | aluxe}!lra 17-Jan-84 08:53:45-MST,958;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:53:41-MST Received: From Amsaa.ARPA by BRL-VGR via smtp; 17 Jan 84 8:51 EST Date: Tue, 17 Jan 84 8:42:08 EST From: David Towson (CSD) <towson@amsaa> To: Ted Hess <THESS@dec-marlboro> cc: info-cpm@brl-vgr Subject: Re: Function 37 Ted - Thanks for the information - very helpful. One question: What is an LRU ? In the equipment maintenance business, it means "line replaceable unit" a term derived from "flight line". It refers to any "box" that can be quickly replaced in an aircraft standing on the flight line. I doubt if that's what you mean by "LRU disk cache". By the way, as another bit of trivia, some folks in the maintenance business take LRU to mean "least replaceable unit", which is a small part, and is therefore the exact opposite of "line replaceable unit" - very confusing. Dave 17-Jan-84 08:54:43-MST,1392;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 08:54:36-MST Received: From Amsaa.ARPA by BRL-VGR via smtp; 17 Jan 84 9:22 EST Date: Tue, 17 Jan 84 9:14:55 EST From: David Towson (CSD) <towson@amsaa> To: Jerry E. Pournelle <POURNE@mit-mc> cc: towson@amsaa, Tli@usc-eclb, Info-Cpm@brl-vgr Subject: Re: Function 37 Jerry - Right you are. When I said "reset the system" I was thinking of "warm boot", not hardware reset; but I was too lazy to go back and edit the message after I read it over and decided I'd used the wrong term. In view of all I am now typing, I'd have been way ahead if I'd edited the message. Ah well, what the heck... The BIOS I'm using (Omikron Mapper-I BIOS for the TRS-80 Model-I) has a nice trap built in that allows "dignified" recovery from an open door. It displays the message "NOT READY TYPE C", and then waits for you to close the door and type "C" (for "continue", I suppose). However, when you switch disks and then try to write to the new disk without doing a warm boot first, it nails you with the familiar BDOS ERROR, and there is no dignified way out. I'd much prefer a nice friendly question like, "HEY DUMDUM, do you REALLY want to do this ?", to which I could respond "Y" to continue or "N" to abort. Someday, I'll hack that in. Dave 17-Jan-84 10:06:47-MST,2817;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 10:06:36-MST Received: From Amsaa.ARPA by BRL-VGR via smtp; 17 Jan 84 11:42 EST Date: Tue, 17 Jan 84 11:29:42 EST From: David Towson (CSD) <towson@amsaa> To: info-cpm@brl-vgr Subject: TAC news. The following is provided for the benefit of those persons who can access MILNET TAC's. Dave Towson info-cpm-request@brl-vgr ----------------------------------------------------------------------------- Received: From Sri-Nic.ARPA by BRL via smtp; 16 Jan 84 19:51 EST Date: Mon 16 Jan 84 16:04:23-PST From: NIC Subject: All-Points Broadcast--TAC Login Procedures Sender: NIC@SRI-NIC To: ALL-POINTS: ; Reply-To: NIC@SRI-NIC The following message explains MILNET TAC Login. Users will encounter the need for this information as of Midnight tonight EST. These instructions are also available through all MILNET/ARPANET TAC's as a menu item in the TACNEWS system, which is accessible via the "@n" command. Note that ARPANET users will be unaffected at present, unless they use a MILNET (Defense Data Network) TAC to access their ARPANET host. Please broadcast these TAC Login procedures to all of your MILNET TAC users. As announced in DDN Newsletter No. 35, the Universal UserID procedure will be in effect 17 January through 15 February, after which individual UserIDs will be necessary. ===================================================================== The access control system for MILNET (Defense Data Network) TAC's requires you to login before connections may be opened. The login process is automatically started with the first "@open" ("@o") command you issue. There is also a new "@logout" ("@l") command to logout. Otherwise, the functioning of the TAC is unaffected by the access control system. Here is a sample of the login dialog (user input is underlined): a) PVC TAC 110 #:01 b) @o 26.2.0.8<RETURN> ----------- c) TAC Userid: TAC.LOGIN<RETURN> ---------- d) Access Code: 22ockedc2<RETURN> (Does not echo.) ---------- e) Login OK f) TCP trying...Open In the above example, the TAC prints its greeting (a). The user proceeds to give the command to open a connection to host 26.2.0.8 (b). If you are used to using a host number with a slash in it, you may still use that form, i.e. "@o 2/8", as long as you are not going across networks. The TAC prompts for a TAC UserID. The user enters the Universal UserID which expires February 15, 1984 (c). The Access Code corresponding to the UserID is entered (d). After a brief wait, the TAC indicates that ***Error on net connection*** === brl-vgr netread error from amsaa at Tue Jan 17 11:43:49 === 17-Jan-84 10:28:58-MST,5686;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 10:28:36-MST Received: From Amsaa.ARPA by BRL-VGR via smtp; 17 Jan 84 11:53 EST Date: Tue, 17 Jan 84 11:29:42 EST From: David Towson (CSD) <towson@amsaa> To: info-cpm@brl-vgr Subject: TAC news. The following is provided for the benefit of those persons who can access MILNET TAC's. Dave Towson info-cpm-request@brl-vgr ----------------------------------------------------------------------------- Received: From Sri-Nic.ARPA by BRL via smtp; 16 Jan 84 19:51 EST Date: Mon 16 Jan 84 16:04:23-PST From: NIC Subject: All-Points Broadcast--TAC Login Procedures Sender: NIC@SRI-NIC To: ALL-POINTS: ; Reply-To: NIC@SRI-NIC The following message explains MILNET TAC Login. Users will encounter the need for this information as of Midnight tonight EST. These instructions are also available through all MILNET/ARPANET TAC's as a menu item in the TACNEWS system, which is accessible via the "@n" command. Note that ARPANET users will be unaffected at present, unless they use a MILNET (Defense Data Network) TAC to access their ARPANET host. Please broadcast these TAC Login procedures to all of your MILNET TAC users. As announced in DDN Newsletter No. 35, the Universal UserID procedure will be in effect 17 January through 15 February, after which individual UserIDs will be necessary. ===================================================================== The access control system for MILNET (Defense Data Network) TAC's requires you to login before connections may be opened. The login process is automatically started with the first "@open" ("@o") command you issue. There is also a new "@logout" ("@l") command to logout. Otherwise, the functioning of the TAC is unaffected by the access control system. Here is a sample of the login dialog (user input is underlined): a) PVC TAC 110 #:01 b) @o 26.2.0.8<RETURN> ----------- c) TAC Userid: TAC.LOGIN<RETURN> ---------- d) Access Code: 22ockedc2<RETURN> (Does not echo.) ---------- e) Login OK f) TCP trying...Open In the above example, the TAC prints its greeting (a). The user proceeds to give the command to open a connection to host 26.2.0.8 (b). If you are used to using a host number with a slash in it, you may still use that form, i.e. "@o 2/8", as long as you are not going across networks. The TAC prompts for a TAC UserID. The user enters the Universal UserID which expires February 15, 1984 (c). The Access Code corresponding to the UserID is entered (d). After a brief wait, the TAC indicates that login is successful (e) and goes on to the normal connection sequence (f). When you are entering your TAC UserID and Access Code: - A carriage return (indicated as "<RETURN>" in the example) terminates each input line and causes the next prompt to appear. - As you type in your TAC UserID and Access Code, it does not matter whether you enter an alphabetic character in upper or lower case. In the typing of the TAC UserID, all lower case alphabetic characters echo as upper case. - The Access Code is not echoed in full-duplex mode. An effort is made to obscure the Access Code printed on hardcopy terminals in half-duplex mode. - As an aid to correct reading of Access Codes, they have been designed so that they never contain a zero, a one, a "Q" or a "Z", because each of these characters resembles another. So if you think you see one of these characters in your Access Code, you know it is really the letter "O" [oh], the letter "L" [el], or the number "2" [two]. - You may edit what you type by using the backspace (Control-H) key to delete a single character. - You may delete the entire line and restart it by typing Control-U. A new prompt will appear. - While entering either the TAC UserID or Access Code, you may type Control-C to abort the login process and return to the TAC command mode. You must interrupt or complete the login process in order to issue any TAC command. After both the TAC UserID and Access Code are collected from the terminal, the TAC must verify the login attempt. Often this takes less than a second, but in some cases a slight delay will occur. Anything typed at the terminal after the concluding carriage return of the access code, but before the login confirmation (or denial) is received, will generate the message "Wait" on the terminal. If the login is allowed, you will see the message "Login OK" and immediately afterward the TAC will attempt to open your TCP connection. If the login is denied for any reason, you will see the message "Bad Login." The TAC will then prompt you for another UserID and Access Code. After several bad login attempts, the TAC will attempt to hang up your TAC port. Once logged in, your port remains logged in as long as you have an open connection. There is a ten minute period after you close one connection in which you may open another one without having to go through the login sequence. When you are finished using your TAC port you should log out by using the TAC "@logout" command. Typing "@reset" has no effect on your login state. If ten minutes go by during which your port does not have an established TCP connection, the TAC will attempt to hang up on your port, logging you out. If you are having problems logging in, call the Network Information Center at (415) 859-3695 between the hours of 8:00-17:00 PST. ------- 17-Jan-84 10:36:35-MST,802;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 10:36:30-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 17 Jan 84 12:05 EST Date: 17 Jan 1984 10:04 MST (Tue) Message-ID: <WANCHO.11984361659.BABYL@SIMTEL20> From: "Frank J. Wancho" <WANCHO@simtel20> To: INFO-CPM@brl-vgr Subject: M7P1-1.ASM - PMC Micromate Overlay for MDM7xx Date: Monday, 16 January 1984 22:33-MST From: wcwells%ucbopal.CC at Berkeley (William C. Wells) Re: M7P1-1.ASM - PMC Micromate Overlay for MDM7xx We have developed an overlay for use with the PMC MicroMate 101 microcomputer and Unix timesharing systems. Bill Wells WB6NLL wcwells@Berkeley.ARPA -------------------- The file is now in MICRO:<CPM.MODEM7> as M7P1-1.ASM. --Frank 17-Jan-84 11:26:50-MST,1656;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 11:26:44-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 17 Jan 84 13:07 EST Date: 17 Jan 1984 11:07 MST (Tue) Message-ID: <WANCHO.11984373127.BABYL@SIMTEL20> From: "Frank J. Wancho" <WANCHO@simtel20> To: INFO-CPM@brl-vgr Subject: Function 37 (clue!) In-reply-to: Msg of 16 Jan 1984 22:32-MST from Jerry E. Pournelle <POURNE at mit-mc> At the extreme risk of prolonging this discussion, I'm surprised that no one noticed Jerry's not-so-subtle clue in his last message: fn 37 can wipe out the diredctory of a HARD (not removable) disk. Most, if not all BIOSes are set up with hard disk logical drives having CKS set to ZERO. This is a crude but somewhat effective way to indicate to CP/M that the drive is fixed rather than removable, and not to bother doing the checksum calculation/compare. This would be fine in a single-user environment, but potentially devastating in a multi-user one. Function 37 "RESET DRIVE" is actually misnamed. It should have been named "RESET WRITE PROTECT VECTOR", which write-enables the indicated drives, as opposed to "resetting" them. A subtle but significant difference. An unsynchronized Function 37, combined with the fact that hard disk drive integrity via checksum is bypassed, will indeed cause unpredicatable results. The correct and safe sequence is: Function 25: Return Current Disk (needed for Function 14 below) Function 13: Reset Disk System (ends up selecting A) Function 14: Select Disk (to reselect the original current drive) --Frank 17-Jan-84 11:39:54-MST,2169;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 11:39:45-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 17 Jan 84 13:14 EST Received: From Office-2.ARPA by BRL via smtp; 17 Jan 84 13:02 EST Date: 17-Jan-84 09:55 PST From: ACB.TYM@office-2 Subject: Function 37 ..sigh. To: info-cpm@brl Message-ID: <[OFFICE-2]TYM-ACB-3Y1NK> I have tried to hold off, but I can resist no longer. Jerry tries to share his experience (is that not what this forum is for) and he is dumped on. Such activity keeps me from sharing some of my experiences. I am implementing LRU disk caches in the BIOS and am lamenting over the inability of the BIOS to tell when to flush the cache. It is very unfriendly to leave the directory tracks of an old disk in the cache (the old disk can be kept whole by using a write through cache) when allocating new files on a new disk. Most schemes that are safe (no explicit action required to insure integrity of disks) end up flushing the cache every warm boot because the BIOS cannot distinguish between the first disk selection after warm boot (innocent) and the first disk selection after a change (requires flush). This is ok for long sessions in database applications but not good when in an edit, compile, test loop. I would be interested in the experiences of others but wary of being assumed to be an idiot. Judging from the volume of the reaction to the Function 37 remarks, there are a lot of people out there waiting to pounce an a cause. Long live Function 37! I certainly won't use it until someone explain's Jerry's information. By the way, how silly it is to see 22 lines of mail header just to see some joker ask whether anyone has received BYTE. Darn! I guess I will get lectured about how, If I wanted to spend the time (or how utility "X" on system "Y" will solve the problem) I could write a program to filter the header. If all that garbage were written on a Postal envelope, the mail never would be delivered. I am not interested in the Odyssey of such a foolish letter, only the author. 17-Jan-84 12:58:14-MST,2541;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 12:58:05-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 17 Jan 84 14:32 EST Date: Tue, 17 Jan 84 14:32:09 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr cc: Info-Modem7@mit-mc Subject: MDM717 update news ---forwarded from the Sysop Clearinghouse RCPM--- Msg 241 is 10 line(s) on 01/14/84 from STEVE SANDERS to ALL about MDM717.MOD When trying to overlay MDM717 with the M7NM-2.ASM file I found that the ORG of 0D00h was bad...After hunting around, I found the new location should be: ORG 0CDFh I have changed M7NM-2.ASM accordingly and will be carrying a copy called M7NM-3.ASM with the new ORG as stated. Steve Sanders Msg 242 is 10 line(s) on 01/14/83 from RON FOWLER to ALL about NO MORE MDM RELEASES!!! Apparently, Irv didn't get the word -- I'm making MAJOR modifications to MDM7 and am totally unwilling to add any- one else's belatedly. If you don't want to be left behind (I will release a version # ahead of yours if need be), then WAIT until I get done. I will be only a few more days. Among the new features will be a TYPE command, a RENAME, enhanced DIR command, ZCPR2-style DU file specifications, and several other things I'm not specifying (in case I don't get to them all). So please, read and heed. --Ron Fowler Msg 243 is 16 line(s) on 01/15/83 from RON FOWLER to ALL about MORE RE MDM720 Re the previous messages about the phone number library: I have changed the ORG back to 0D00H. This was not done indiscriminately; MDM720 will have a new configuraton block located immediately after the phone # library (the whole thing will be configurable, including the modem overlay, with my newest version of MLOAD; ddt no longer necessary). Hence, this area must stay firmly located, now and forever. (Fair warning; don't spend a lot of time changing phone # overlay files back, you'll just have to do it again later). Please forgive the tone of this and the previous message; I am a bit upset about the new release of MDM several days after I posted a message here asking for a moratorium, but I guess I'll get over it (I just hate to have to go back and add Irv's 717 stuff to what is no longer a correct ante- cedant. Plus I have this funny feeling that Irv is about to do a 718....). --Ron --end-- 17-Jan-84 14:24:13-MST,865;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 14:24:10-MST Received: From Ucla-Ats.ARPA by BRL-VGR via smtp; 17 Jan 84 16:04 EST Date: Tue, 17 Jan 84 12:56:29 PST From: Willard Korfhage <korfhage@ucla-ats> To: info-cpm@brl-vgr Subject: Function 37 - disk door open Floppy disk controller chips can check for an open door by monitoring the sector hole sensor (the 1791 does this). If the chip doesn't receive a pulse from the sensor within xx milliseconds of the last pulse, then it knows the disk has stopped rotating, presumably because the door has been opened. If I read the data sheet properly, the 1791 can send an interrupt when this happens. This technique, of course, works for any floppy, regardless of size. Willard Korfhage 17-Jan-84 21:13:47-MST,2136;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 21:13:41-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 17 Jan 84 22:52 EST Received: From Mit-Mc.ARPA by BRL via smtp; 17 Jan 84 22:46 EST Date: 17 January 1984 22:41 EST From: Robert L. Plouffe <PLOUFF@mit-mc> Subject: mdm716 buffer size To: INFO-MODEM7@mit-mc, RGF@mit-mc, INFO-CPM@mit-mc, info-cpm@brl, info-modemxx@simtel20 The following message from Keith Petersen correctly and completely explains the reason for the 2k file transfer buffer. He assumed as I did that the data capture buffer (even if started at the same point) and the file transfer buffer had independent size limits - i.e, one set by the BUFSIZ equate for filhe other set by checking to see if either the CCP or BDOS (optiono be overwritten so that the whole TPA can be used on a dynamic bture. This is tER, it was changed somewhere along the line and iprinter buffer tfile transfer and data capture buffers to BUFSI BE STRAIGHTENEDE OPTIMAL COMPROMISE AS EXPLAINED BY KEITH), AND BUFFER ALLOWED T BUFFER (FIXED) [4K OUGHT TO BE ENOUGH]. If I ul correctly, Ron, and it will hopefully be in MDM718. In the mey thing that can at 16 as Hoff has done in MDM717. Do make sure patching with Dr since MDM715, the program has been larger than overlay patch fi---- Date: Wed, 11 Jan 84 21:40:07 EST From: Keit at brl-bmd> To:: Chan.CST at hi-multics, INFO-CPM at brl-vgr Rin mdm716 Pleasr already have MDM717 "in progress" and we shouldorthcoming from hate to see all that good stuff that Bob Plouffe ripped out" by Iike it". That's how we lost the "retry after tenamoung other thir the protocol file transfer mode. It does not al capture mode. th slower disk systems which took so long writingut (and consequein the directory) that they lost the next sector from the senderabort. The 2k buffer was chosen MANY versions bacam was MODEM2) apeed and the improvement in receiving speed by puers into the bufs the way Ward Christensen's old original MODEM p the disk. ----- 17-Jan-84 21:31:40-MST,791;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 17 Jan 84 21:31:37-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 17 Jan 84 23:13 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 17 Jan 84 23:11 EST Date: Tue 17 Jan 84 20:03:20-PST From: Leslie Zatz <ZATZ@SUMEX-AIM.ARPA> Subject: MDM versions To: w8sdz@BRL.ARPA cc: info-cpm@BRL.ARPA The old MODEM series supported both CPM 1.4 and later versionss. The MDM series does not support 1.4 and does not state that in descriptions, causing a great waste off time till I contacted Irv Hoff. If possible, could the revisers support 1.4? If not this information should be in descriptive material. Could this get forwarded to Ron Fowler? LESLIE ZATZ ------- 18-Jan-84 09:28:56-MST,3356;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 18 Jan 84 09:28:46-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 18 Jan 84 0:37 EST Received: From Mit-Mc.ARPA by BRL via smtp; 18 Jan 84 0:30 EST Date: 18 January 1984 00:27 EST From: Robert L. Plouffe <PLOUFF@mit-mc> Subject: mdm716/717 buffer size To: INFO-MODEM7@mit-mc, RGF@mit-mc, info-cpm@brl, info-modemxx@simtel20 The following message from Keith Petersen correctly and completely explains the reason for the 2k file transfer buffer. He assumed as I did that the data capture buffer (even if started at the same point) and the file transfer buffer had independent size limits - i.e, one set by the BUFSIZ equate for file transfer, and the other set by checking to see if either the CCP or BDOS (optionally) was about to be overwritten so that the whole TPA can be used on a dynamic basis for data capture. This is the way that the program always used to work. HOWEVER, it was changed somewhere along the line and it now allows the printer buffer to use the TPA dynamically and fixes both the file transfer and data capture buffers to BUFSIZ. THIS NEEDS TO BE STRAIGHTENED OUT SO THAT THE FILE TRANSFER BUFFER CAN BE SET TO 2K (THE OPTIMAL COMPROMISE AS EXPLAINED BY KEITH), AND THE DATA CAPTURE BUFFER ALLOWED TO USE THE TPA WITH A COMPROMISE SIZED PRINTER BUFFER (FIXED) [4K OUGHT TO BE ENOUGH]. If I understand the mail correctly, Ron Fowler is working on this, or some variation, and it will hopefully be in MDM718. In the mean time, the only thing that can be done is to leave the BUFSIZ equate set at 16 as Hoff has done in MDM717. Do make sure to SAVE 69 after patching with DDT as Keith has repeatedly warned because ever since MDM715, the program has been larger than indicated in the overlay patch files. Forwarded message: ------------------------ Date: Wed, 11 Jan 84 21:40:07 EST From: Keith Petersen <w8sdz at brl-bmd> To: Charlie Strom (NYU) <strom at brl-bmd> cc: Chan.CST at hi-multics, INFO-CPM at brl-vgr Re: buffer size in mdm716 Please tell Irv Hoff that Bob Plouffe and Ron Fowler already have MDM717 "in progress" and we should have something forthcoming from them with these fixes in about a week. I'd hate to see all that good stuff that Bob Plouffe put in MDM716 "stripped out" by Irv "because he doesn't agree with it" or "doesn't like it". That's how we lost the "retry after ten errors" option, amoung other things. On the subject of the 2k buffer size. This is true ONLY for the protocol file transfer mode. It does not affect the terminal capture mode. It was done after NUMEROUS complaints from people with slower disk systems which took so long writing the 16k buffer out (and consequently closing that extent and opening the next in the directory) that they lost the next sector and several tries from the sender. In many cases this caused the transfer to abort. The 2k buffer was chosen MANY versions back (when the program was MODEM2) as an acceptable compromise between disk access speed and the improvement in receiving speed by putting the characters into the buffer instead of writing every sector (which was the way Ward Christensen's old origithe disk. -------------- End of forwarded message.. 18-Jan-84 09:33:50-MST,692;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 18 Jan 84 09:33:46-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 18 Jan 84 8:29 EST Date: Wed, 18 Jan 84 8:28:07 EST From: Keith Petersen <w8sdz@brl> To: Leslie Zatz <ZATZ@sumex-aim.arpa> cc: Info-Cpm@brl-vgr Subject: Re: MDM versions and CP/M 1.4 You said that MDM7 doesn't work with CP/M 1.4. What is it that isn't supported? Does the program bomb? I use it at work on CDOS, which is based on CP/M 1.3. It works fine. Why are you still using 1.4? 2.2 has so many nice features most people I know have long ago upgraded to it. --Keith 18-Jan-84 09:34:06-MST,756;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 18 Jan 84 09:34:03-MST Received: From Parc-Maxc.ARPA by BRL-VGR via smtp; 18 Jan 84 8:13 EST Date: Wed, 18 Jan 84 08:10 EST From: Damouth.Wbst@PARC-MAXC.ARPA Subject: Re: Function 37 - disk door open In-reply-to: "korfhage@ucla-ats.ARPA's message of Tue, 17 Jan 84 12:56:29 PST" To: Willard Korfhage <korfhage@ucla-ats.ARPA> cc: info-cpm@brl-vgr.ARPA " . . monitoring the sector hole sensor . . . works for any floppy, regardless of size ." Sorry - not true. You forget that some 5 1/4" drives are soft sectored. The Apple II drives are not only soft sectored, they don't even use the once-per-revolution index hole. /Dave 19-Jan-84 08:29:40-MST,1902;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 08:29:16-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 19 Jan 84 2:23 EST Received: From Sri-Unix.ARPA by BRL via smtp; 19 Jan 84 4:31 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 19 Jan 84 1:09-PST Date: 18 Jan 84 7:14:34-PST (Wed) To: info-cpm@brl From: hplabs!hao!seismo!rlgvax!plunkett@ucb-vax Subject: Demise of JRT Pascal Article-I.D.: rlgvax.1576 - JRT Systems, makers of the $29.95 JRT Pascal compiler, have filed Ch. 11 Bankruptcy. For some time I have been reading various letters-to-editors complaining that JRT was slow to respond to orders, if at all. Other complaints, most notably from J. Pournelle of Byte, mentioned that JRT Pascal was not Standard, and that it was a shoddy piece of work, viz., easily crashable. Yet "a bargain at $29.95". The pricing seems to have been its undoing. JRT was flooded with orders it could not handle, the revenue received is now shown to have been insufficient to support the software firm, yet almost everywhere I read reviews commending Mr. Tyson for the courage of pricing it at $29.95; that it was a "steal" for the Pascal programmer. It strikes me as a foolish act of irresponsibility to price a compiler so low, and somewhat negligent on the part of reviewers to be seduced by the mere $29.95. (One exception was Dr. Dobbs that rightly said it was *not* a bargain regardless of price.) If the reports of JRT developing a Modula-2 compiler are true, I hope that they will invest alot more effort into the product, price it accordingly, and price it to support their company in maintaining and improving it. And in filling orders promptly. JRT has committed a disservice to the software industry with their JRT Pascal. Scott Plunkett ..seismo!rlgvax!plunkett 19-Jan-84 08:29:44-MST,1115;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 08:29:33-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 19 Jan 84 3:24 EST Received: From Mit-Mc.ARPA by BRL via smtp; 19 Jan 84 5:27 EST Date: 19 January 1984 05:25 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: Demise of JRT Pascal To: hplabs!hao!seismo!rlgvax!plunkett@ucb-vax cc: info-cpm@brl In-reply-to: Msg of 18 Jan 84 7:14:34-PST (Wed) from hplabs!hao!seismo!rlgvax!plunkett at ucb-vax 1. JRT 2.+ was NOT a bargain at any price. 2. His 3.0 was, assuming you could get it; did you actually read what I said? 3. Barry workman can make a profit (not large) with sales at $35.00 per disk postpaid if he doesn't have large royalties to pay. 4. Borland'd Turbo Pascal at $49.95 IS a bargain, and indeed is pretty nifty; and t hey seem to be surviving and thriving. 5. Bookstores make a good living selling books at considerably less than $39.95; at least some do. And they have high volume of sales, lots of inventory, lots of items to stock, unlike JRT. 19-Jan-84 08:30:05-MST,1217;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 08:29:51-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 19 Jan 84 6:05 EST Received: From Mit-Mc.ARPA by BRL via smtp; 19 Jan 84 8:13 EST Date: 19 January 1984 08:11 EST From: Robert L. Plouffe <PLOUFF@mit-mc> Subject: MDM717 ACKNAK BUG To: INFO-MODEM7@mit-mc, INFO-CPM@brl, INFO-MODEMXX@simtel20 cc: PLOUFF@mit-mc I had recommended that the ACKNAK flag be set to 'NO' in MDM17 as released by Irv Hoff so that sectors are repeated only upon receipt of a valid NAK or a timeout occurs. This works automatically in MDM716 since I had killed the ACKNAK flag. However Hoff tried to restore it in MDM717 and did it wrong. Setting ACKNAK to 'NO' has no effect (gives same as 'YES'). For those who have source and need a correction, the following three lines at GETACK are wrong: LDA AGETACK ORA A JZ ACKLUP Change to: LDA ACKNAK ORA A JZ GETACK1 Better yet, wait for MDM720 (and go back to MDM716 in the mean time). Ron Fowler is working on beta test version of 720 now and will have this as well as all the buffer discussion problems fixed plus new featyres.. 19-Jan-84 08:42:22-MST,1898;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 08:42:16-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 19 Jan 84 7:45 EST Date: Thu, 19 Jan 84 9:45:29 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: Kaypro BIOS list bug The following is forwarded from CompuServe, courtesy Irv Hoff. --- #: 74332 Sec. 1 - General Sb: #Kaypro Mystery Solved 18-Jan-84 01:54:26 Fm: JACK CRENSHAW 72325,1327 To: All Some time ago I reported a problem with the MDM711/Kaypro/Epson combina- tion, in that the ^P print buffer dropped characters. Periodically, the subject has come up again, with Irv Hoff and Pete Holsberg trying hardest to help me solve the problem. I finally got around to looking at the Kaypro BIOS, and as Pete suspected, there's a bug. The offending piece of code is in the ROM, and goes: LISTST: IN 1CH ;GET SYSTEM PORT BIT 3,A ;TEST PRINTER READY BIT RZ ;THIS IS THE BUG MVI A, 0FFH ;ELSE RETURN FF RET Note that if the bit 3 is zero, the routine returns garbage in A. The garbage is whatever is in port 1CH, which includes output as well as input bits. However, the zero FLAG is set properly, which is why BIOS function 4 (LIST) works OK. Ironically, if the programmer had used the usual ANI insruction instead of the Z-80 fancy bit test, he would have saved two bytes as well as get the right response. The bug is in the ROM, so can't be easily fixed. The patch is easy, though - Change the jump vector in the BIOS to: JMP PATCH and add: PATCH: CALL 0FB65H ;call old bios entry RNZ ;OK unless its zero XRA A ;else clear A RET ;that's all, folks - Jack Crenshaw 19-Jan-84 09:09:34-MST,465;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 09:09:30-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 19 Jan 84 8:11 EST Received: From Usc-Isi.ARPA by BRL via smtp; 19 Jan 84 10:15 EST Date: 19 Jan 1984 07:13:48 PST From: METH@usc-isi Subject: TECO for CP/M To: INFO-CPM@brl cc: METH@usc-isi Is there such an animal? Is it in the public domain?? Sheldon Meth ------- 19-Jan-84 19:57:03-MST,294;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 19:57:00-MST Received: From Amsaa.ARPA by BRL-VGR via smtp; 19 Jan 84 19:31 EST ***Error on net connection*** === brl-vgr netread error from amsaa at Thu Jan 19 19:32:24 === 19-Jan-84 20:23:53-MST,3814;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 20:23:43-MST Received: From Amsaa.ARPA by BRL-VGR via smtp; 19 Jan 84 19:42 EST Date: Thu, 19 Jan 84 21:35:09 EST From: David Towson (CSD) <towson@amsaa> To: info-cpm@brl-vgr, info-micro@brl-vgr Subject: A good deal on Shugart model 800 8-inch drives. I'll get to the disk drives in a moment, but first an anecdote: Several years ago when there was no such thing as an under-500-dollars printer, I went to a microcomputer show at the Philadelphia Civic Center. A small local company named Selectronics had a booth there, and they were selling various surplus items. In front of the booth they had a large placard that advertised the availability of five Texas Instruments Silent 700 series printers (without keyboards) for $100 each (yep, one-hundred -- ridiculous). Well, I walked past that sign for many circuits of the Civic Center until I had just about seen all I wanted to see there. Finally, I decided to go see their el-cheapo printers. I asked the guy at the booth what was the deal. He said they were made by TI, they worked, and they were cheap, and what else did I want to know. I asked to see one print. He said okay and hooked up a keyboard. I typed and it printed, only the line feed didn't quite work right, so I asked to try another. Well, in time I had tried all five, and the guy said I'd had my fun and now it was time to put up or buzz off (he didn't really say THAT). I picked one and began writing my check. Now mind you, these things had been sitting there ALL DAY with everyone apparently thinking they must be junk -- just as I was thinking. By the time I had written my check, they were all gone. It seems that I had attracted a BIG CROWD of interested folks just waiting for some reason to think the $100 printers were okay. And as soon as that was taken care of, they really moved fast. So that was my introduction to Selectronics. Now on to the disk drives... Back in August 1983 I saw an ad in "Microcomputing" in which Selectronics offered new Shugart model 800 8-inch drives for $140 each (what, a $350 drive for $140 -- ridiculous). After 15 milliseconds contemplation, I called the company and asked for the details. Nothin to it -- new drives, no hookers, $140. They also had "little used" (as in slightly, not small) ones for $100. I didn't pursue that one. I bought one of the new ones, and when it arrived shortly thereafter, it was just what they said: new, clean, functional. By December, I was having a yen for a second 8-incher (I run a modified TRS-80 Model-I, originally with two 5-inch drives.) So I ordered a second 8-inch drive. It arrived in jig time and didn't work worth a hoot. There appeared to be massive sticky-friction in the worm-drive head positioner. I called Selectronics: No problem, they'd send a new one, and I should return the one I had. Well, they sent two. It seems that one was sent as soon as I called, and then when the shipping person read the letter I enclosed with the returned drive, he sent another. Both of these work fine, and I will now return one of them, collect. So there you have it, an unsolicited testimonial. These people have good stuff, and they're really pleasant to deal with. They are located at 1229 South Napa Street, Philadelphia, PA 19146, and their phone number is (215) 468-4645. The person with whom I've spoken on several occasions is Al Meely. If you're in the market for an 8-inch single-sided (Iforgot to mention that) drive, you really ought to check this out. No, he's not my uncle, a friend or anything else to me. I'm just a VERY satisfied customer. Dave towson@amsaa 19-Jan-84 21:04:18-MST,1497;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 21:04:14-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 19 Jan 84 20:31 EST Received: From Hi-Multics.ARPA by BRL via smtp; 19 Jan 84 20:25 EST Date: 19 January 1984 20:20 cst From: DSullivan.CSC_SDO@hi-multics Subject: How to mangle a disk. To: INFO-CPM@brl cc: Pourn@mit-mc It doesn't matter if you use reset all drives (function 13) or reset drive (function 37) the following will muck up files/directories etc given enough disk requests. Step 1) open a file on drive X Step 2) open file2 on drive X Step 3) write data to file x (less than 16k) Step 4) reset the disk. Both function 13 or 37 will do the trick. Step 5) write data to file2, the data will be written over file1's allocated area. Step 6) close the files, and make the damage perminant. What happens is the FCB for file1 is given blocks from the free pool (as kept by the allocation vector) The reset causes the vetor to be re-initialized to the old pattern. The writes to file2 then use the re-initialized map, and re-allocate to the same space as file1. These two files now share a common set of blocks on the disk. Read/write either and it will impact the data of the other. Please note when you have a hard disk, even less checking is done, so it is easier to mangle the disk esp with BIOS that have disk cashes that keep parts of directories around. 19-Jan-84 21:12:35-MST,593;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 19 Jan 84 21:12:32-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 19 Jan 84 20:43 EST Received: From Mit-Xx.ARPA by BRL via smtp; 19 Jan 84 20:41 EST Date: Thu 19 Jan 84 21:26:11-EST From: Ralph W. Hyre Jr. <RALPHW@MIT-XX.ARPA> Subject: "?Public domain version of MODEM in Apple Pascal?" To: info-cpm@BRL.ARPA If there isn't one available, I would appreciate a pointer to the document describing the protocol so I can write one. Thanks. - Ralph Hyre ------- 20-Jan-84 08:45:59-MST,955;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 08:45:50-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Jan 84 2:47 EST Received: From Mit-Mc.ARPA by BRL via smtp; 20 Jan 84 2:46 EST Date: 20 January 1984 04:55 EST From: Jonathan W. Platt <JWP@mit-mc> Subject: TECO for CP/M To: METH@usc-isi cc: INFO-CPM@brl Yes there is one TECO that I know of that runs under CP/M. It has the same command structures as standard DEC TECO. It could be considered as version 29 for the PDP-11. I don't know if it has been updated as DEC updates their own. Contact: Small System Design P.O. Box 4546 Manchester, New Hampshire 03108 (603) 432-7929 They call it TED for Text EDitor. I believe it's only missing a few commands (EG is one missing) of the DEC version. But it does have everything else, including indirect files. 20-Jan-84 08:46:28-MST,771;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 08:46:19-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Jan 84 2:58 EST Received: From Mit-Mc.ARPA by BRL via smtp; 20 Jan 84 2:53 EST Date: 20 January 1984 05:01 EST From: Jonathan W. Platt <JWP@mit-mc> Subject: CP/M PLUS! To: INFO-CPM@brl I really need some info about CP/M 3.x. I sent a message dated 11 January 1984, 04:31 EST with some questions. NO ONE has answered it! It regarded banking tables and drive selection. Would somebody please be kind enough (if they have the time) to answer this one user's questions? In advance appreciation, Jonathan Platt (JWP@MIT-MC) 20-Jan-84 08:47:24-MST,705;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 08:47:14-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Jan 84 3:30 EST Received: From Sri-Unix.ARPA by BRL via smtp; 20 Jan 84 3:27 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 20 Jan 84 2:25-PST Date: 19 Jan 84 10:45:53-PST (Thu) To: info-cpm@brl From: ihnp4!ihuxn!geewhiz@ucb-vax Subject: VAX/VMS XMODEM source? Article-I.D.: ihuxn.511 Does anyone have a source for a XMODEM program for a VAX/VMS. If you have any information, please contact me. 312-979-7910 Jerry 20-Jan-84 09:00:49-MST,472;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 09:00:45-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Jan 84 8:25 EST Received: From Wpafb-Info1.ARPA by BRL via smtp; 20 Jan 84 10:22 EST Date: Fri, 20 Jan 84 10:22:34 EST From: elder@wpafb-info1 Subject: CP/M VT100 Emulator? To: info-cpm@brl Does anyone know of a VT100 terminal emulator for a Z80 machine running CP/M? -Greg 20-Jan-84 09:31:32-MST,1097;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 09:31:28-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Jan 84 8:58 EST Received: From Usc-Isid.ARPA by BRL via smtp; 20 Jan 84 10:49 EST Date: 20 Jan 1984 05:57-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: "?Public domain version of MODEM in Apple Pascal?" From: ABN.ISCAMS@usc-isid To: RALPHW@mit-xx Cc: info-cpm@brl Message-ID: <[USC-ISID]20-Jan-84 05:57:17.ABN.ISCAMS> In-Reply-To: The message of Thu 19 Jan 84 21:26:11-EST from Ralph W. Hyre Jr. <RALPHW@MIT-XX.ARPA> Don't I remember an article or message coming over the net where Christensen explained in detail his protocol? Think I have it at home on the Toad's hard disk, but not here, and don't remember the pointer. Yell if no one else knows and I'll give it to you. Regards, (and YES, PLEASE -- if no one else has done it in Pascal for Public Domain, I VERY MUCH need such a creature! Could save you all beaucoup tax dollars!) David Kirschbaum Toad Hall (ABN.ISCAMS@USC-ISID) 20-Jan-84 10:44:59-MST,3025;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 10:44:51-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Jan 84 10:03 EST Received: From Brl-Voc.ARPA by BRL via smtp; 20 Jan 84 12:05 EST Date: Fri, 20 Jan 84 11:56:24 EST From: "Ferd Brundick (LTTB)" <fsbrn@brl-voc> To: ABN.ISCAMS@usc-isid cc: info-cpm@brl Subject: Re: "?Public domain version of MODEM in Apple Pascal?" Hi, Since Toad Hall has also expressed interest in an Pascal Modem7, I am sending a copy of my original reply to the list at large. - - - - - - - - - - There <IS> a modem3 program written in Apple (SCUD) Pascal. The files are on simtel20 in MICRO:<CPM.PASCAL> and the names are given below. I've never used the program because I don't own an Apple, but I do have the MODEM3.PAS file if you can't get it from simtel20 (I can get and send you the other 2 files if you need them). Anyway, below is the header info from the main file. dsw, fferd Fred S. Brundick USABRL, APG, MD. <fsbrn@brl-voc> PROGRAM modem; {Written by Jack M. Wierda Chicago Illinois This program is in the public domain. LANGUAGE: UCSD Pascal FILES: MODEM3.PAS -- main program MDM3-Z80IO.Z80 -- serial line interface for Z80 MDM3-8080IO.Z80 -- serial line interface for Intel 8080 This program is basically a re-write in PASCAL of Ward Christensen's Modem Program which was distributed in CP/M User's Group Volume 25. Identical and compatible options are provided to allow this program to work directly with Ward's program running under CP/M. One difference is that when sending files the PASCAL or CP/M transfer mode must be selected. The PASCAL mode transfers files between two systems running PASCAL, while the CP/M mode is used when the receiving system is running CP/M. Basically the CP/M mode provides the linefeeds required to make a PASCAL file compatible with CP/M. When CP/M files are received they contain linefeeds, these can be deleted using the editor to make the file compatible with PASCAL. CP/M files may also contain tabs which the PASCAL editor does not expand. External assembly language routines are used to read the status, and read or write the keyboard and modem ports. These routines are available as separate files for the 8080 and Z80 processors. The port and flag definitions, and the timing constant for the one second delay should be changed as required for your particular hardware. The program has been tested with text files only, and may not work correctly for code or other types of files. The PDP-10 mode transfers PASCAL files to a DEC SYSTEM-10 computer.} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 20-Jan-84 13:16:01-MST,1306;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 13:15:56-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Jan 84 12:48 EST Received: From Amsaa.ARPA by BRL via smtp; 20 Jan 84 14:54 EST Date: Fri, 20 Jan 84 14:43:56 EST From: David Towson (CSD) <towson@amsaa> To: ihnp4!ihuxn!geewhiz@ucb-vax cc: info-cpm@brl Subject: Re: VAX/VMS XMODEM source? Jerry - The VAX/VMS modem programs are in the directory "micro:<cpm.vaxvms> on Simtel20. The listing for this directory is attached. If you need help in getting the files, post a request for assistance, and someone on the list will help you. Dave towson@amsaa --------------------------------------------------------------------------- Filename Type Bytes Sectors CRC Directory MICRO:<CPM.VAXVMS> CTOV.FOR.1 ASCII 2821 23 = 17H 6408H QIO.DCK.1 ASCII 115 1 = 1H A2B1H VTOC.FOR.1 ASCII 2730 22 = 16H 747AH XMODEM.COM.1 ASCII 563 5 = 5H 6AAFH XMODEM.DOC.1 ASCII 649 6 = 6H D3A5H XMODEM.HLP.1 ASCII 3656 29 = 1DH 10A9H XMODEM.MSG.1 ASCII 2796 22 = 16H FDAFH XMODEM.NOTE.1 ASCII 7157 56 = 38H 346AH XMODEM2.FOR.1 ASCII 29651 232 = E8H C3A4H 20-Jan-84 15:16:35-MST,1301;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 15:16:31-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Jan 84 14:50 EST Received: From Rochester.ARPA by BRL via smtp; 20 Jan 84 16:55 EST Received: by sen.rochester (3.327.3N) id AA07628; 20 Jan 84 16:54:47 EST (Fri) Received: by cay.Rochester (3.327.3N+) id AA00127; 20 Jan 84 16:51:03 EST (Fri) Message-Id: <8401202154.7628@sen.rochester> Date: 20 Jan 84 16:54:47 EST (Fri) From: Mike Ciaraldi <ciaraldi@Rochester.ARPA> Subject: Re: VAX/VMS XMODEM source? To: ihnp4!ihuxn!geewhiz@ucb-vax.ARPA, info-cpm@brl.ARPA Two comments: 1) I have used the XMODEM in the Simtel libary and it works finewith one proviso: To make it work at 4800 or 9600 baud, we had to give the command which increases the typeahead buffer size on the VAX (something like "ALTBUF", I think). For it to take effect, we then had to log off and back on. There may be a better way to do it permanently, but I think it requires system-administrator privileges. 2) There is an XMODEM written in C available from DECUS. I have not used in myself, but the people at the University of Rochester's Production Automation Project say it works well. Mike Ciaraldi ciaraldi@rochester 20-Jan-84 18:08:15-MST,618;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 18:08:11-MST Received: From Rand-Unix.ARPA by BRL-VGR via smtp; 20 Jan 84 17:40 EST From: tp3!bridger@rand-unix Date: Friday, 20 Jan 1984 16:23-PST To: randvax!info-cpm@brl-vgr Cc: bridger@BRL-VGR.ARPA Subject: ?litepens and software What experience do list-readers have with light-pens on cp/m (or other) systems? Recommendations for both hardware and software would be welcome. Also, pointers to applications notes for programming 6545 & 6845 controllers to support this device. --bridger 20-Jan-84 19:30:33-MST,5128;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 20 Jan 84 19:30:09-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Jan 84 18:52 EST Received: From Mit-Mc.ARPA by BRL via smtp; 20 Jan 84 20:53 EST Date: 20 January 1984 20:52 EST From: Eric Stork <STORK@mit-mc> To: info-cpm@brl cc: STORK@mit-mc Subject: BDOS Function 37 Since I started this discussion, I felt an obligation to try to get to the bottom of the issue. So I spent much of a day reading and experimenting. I think I now understand what Function 37 does and does not do. Frank Wancho pointed out that Function 37 is misnamed. It should be called RESET WRITE PROTECT VECTOR, he said. That is NOT the same as RESET DRIVE, he emphasized. He went on to suggest the use of Function 13 as a correct and safe sequence, with associated use of functions 25 and 14 to get back to the disk one started on. Function 13 is OK if one can close ALL files. But when one wants to continue to work out of a file on Drive A:, one cannot really reset ALL drives. That's necessary wehn one wants to change disks in a drive that holds data for a program. So Function 37 has a legitimate use and seems OK if one is careful. Others suggested that the trick is to close ALL files on the drive to be reset before using Function 37. Failing to do that can result in overwriting files or directories. But it seems that when all file on the drive to be reset are closed, Function 37 can be safely used. The most interesting thing that I demonstrated in my experiments is that Function 37 does NOT reset the diskmap for the drive to be reset, but that the diskmap for that drive is reset by the first file I/O operation following function 37. I do not have a hard disk, which Jerry Pournelle and Frank Wancho said could easily be trashed by Function 37, but maybe someone who does have a hard disk can try the experiment (without writing to the hard disk, just checking out the disk map) and let us know how it goes. It should go OK, from what I could figure out, but I can't be sure. Eric. For those who might want to repeat or expand my experiment, there follows a short ASM file: ******************** * This is a test program * to analyze the results of BDOS Function #37 * * Assemble the program into a COM file, and put that on Drive A:. * Put a disk with files on drive B:, and log it in with ^C. * Then run this program (I call it TEST.COM) and when asked to do so, * put a different disk on Drive B: * * The bitmap (as bytes) starts a 0300h for the first disk, and at * 0330h for the second disk. I use Ward C.'s Q.COM to look at it, * invoking it as Q @300 , and stopping the display with ^S * or with ^C, so that I can compare the bytes. bufbyts equ 31 ;this value is the number of GROUPS/8 ; on your disks. The bitmap copnsists of ; one bit for each group. My system has ; 243 groups. 243/8=30.375, or 31 when ; we round up. Change this value for your ; system. If you have more than 384 groups, ; you must increase the size of BUF1: and BUF2: ; to hold them. ORG 100H MVI c,14 ;select logical disk MVI e,1 ;select disk B: CALL 5 MVI c,27 ;get address of disk alloc vector call 5 ;returns with [HL] pointing to first of a ; block that holds the disk map LXI D,BUF1 ; MVI c,bufbyts ;use [C] as counter LOOP1: MOV A,M ;get byte of data into [A] STAX D ;and store it in BUF1 INX H INX D ;bump the pointers DCR C ;reduce the counter JNZ LOOP1 ;loop until done LXI d,message MVI c,9 CALL 5 xx: mvi c,11 CALL 5 ORA A ;0 if no char, FF if character typed JZ XX MVI c,37 ;now do the individual disk reset function LXI d,0000$0000$0000$0010B ;drive b: call 5 * ********** This is the key. The first disk operation seems to * read the diskmap. Try running the program with the next three * lines commented out -- you'll see that the two disk maps are * the same, so function 37 alone does not reset the disk map. LXI D,FCB mvi c,15 ;open file (find file, or erase file work also) call 5 ********************************************************* MVI c,27 ;get address of disk alloc vector call 5 ;returns with [HL] pointing to first of 'n'-byte ; block with bitmap (31 for my system) LXI D,BUF2 ; MVI c,bufbyts ;use [C] as counter LOOP2: MOV A,M ;get byte of data into [A] STAX D ;and store it in BUF2 INX H INX D ;bump the pointers DCR C ;reduce the counter JNZ LOOP2 ;loop until done JMP 0000h ;and quit message: DB 'Switch disk in B:, then type any key to continue ','$' FCB: db 1 ;drive b: db 'JUNK ' db 0,0,0,0 ;extent, reserved, & records db 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 ORG 300h BUF1: DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 ;plenty of extra space DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 BUF2: DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 DB 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 END 23-Jan-84 09:19:44-MST,831;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:19:23-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Jan 84 23:24 EST Received: From Mit-Mc.ARPA by BRL via smtp; 21 Jan 84 1:28 EST Date: 21 January 1984 01:28 EST From: Jerry E. Pournelle <POURNE@mit-mc> To: STORK@mit-mc cc: info-cpm@brl In-reply-to: Msg of 20 Jan 1984 20:52 EST from Eric Stork <STORK> let me know the results of your experiment. Systems interface just lost another hard disk to #37 this week; directory is dead. I do not know if they closed all files and such as you suggest. incidentally, there is zero warning on that in any document I have read. we now avoid 37 as not worth the risk. perhaps you will have different results. I'd be interested in hearing. 23-Jan-84 09:19:47-MST,4278;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:19:34-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Jan 84 23:25 EST Date: Sat, 21 Jan 84 1:30:32 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: Area code 213 BBS changes --forwarded from the Sysop Clearinghouse RCPM-- (818) Area Code Helper January 17, 1983 (2nd version by Kim Levitt) On Jan. 7th, the 213 area code which used to cover most of Los Angeles County was spilt in two. For the benefit of those who are changing dialing menus or macros, here is a list of the former 213 prefixes which are now 818. If you dial one of them without the 1-818, for the next nine months you will probably get connected, but you might get a recording which may, (probably will), keep your modem from connecting. After Oct. 1st, (or possibly sooner), you will not be connected unless you dial the (818) area code. The prefixes which were changed are listed below. 240-244 Glendale 246-247 Glendale 248-249 La Crescenta 280-282 Alhambra 284-289 Alhambra 300 Alhambra 303 Monrovia 304 Pasadena 307-308 Alhambra 330-339 Covina 340-341 Canoga Park 342-345 Reseda 346-348 Canoga Park 349 Reseda 350 El Monte 351 Sierra Madre 352-353 Sunland-Tujunga 354 La Canada 355 Sierra Madre 356 Pasadena 357-359 Monrovia 360-368 San Fernando 400 Pasadena 440-441 Pasadena 442-444 El Monte 445-447 Arcadia 448 El Monte 449 Pasadena 500 Glendale 501 Van Nuys 502 Glendale 504 Sun Valley 505-506 N. Hollywood 507 Glendale 508-509 N. Hollywood 570-573 Alhambra 574 Arcadia 575 El Monte 576 Alhambra 577-578 Pasadena 579 El Monte 700 Canoga Park 701 Reseda 702-704 Canoga Park 705 Reseda 706-707 Agoura 708 Reseda 709-710 Canoga Park 715-716 Canoga Park 717 Reseda 760-766 N. Hollywood 767-768 Sun Valley 769 N. Hollywood 780-789 Van Nuys 790 La Canada 791-799 Pasadena 810 Covina 812 Covina 814 Covina 817 Covina 840-843 Burbank 845-848 Burbank 880 Canoga Park 881 Reseda 882-884 Canoga Park 885-886 Reseda 887-888 Canoga Park 889 Agoura 890-899 San Fernando 901-908 Van Nuys 912-915 Covina 917-919 Covina 917-919 Covina 951 Sunland-Tujunga 952 La Canada 953-954 Burbank 956 Glendale 957 La Crescenta 960-969 Covina 980 N. Hollywood 981 Van Nuys 982 N. Hollywood 983-984 Van Nuys 985 N. Hollywood 986-990 Van Nuys 991 Agoura 992 Canoga Park 993 Reseda 994-995 Van Nuys 996 Reseda 997 Van Nuys 998-999 Canoga Park The above list was compiled from a listing published in the Santa Monica Evening Outlook, supplemented by several calls to General Telephone Information. Any errors are probably caused by my poor proof reading. (Prefixes 505, 780-789, 790 and 791-799 were omitted on first version of this list. These additional prefixes were listed on page A-80 of the Pacific Telephone June 1983 Los Angeles White Pages, and have been confirmed to be a part of the (818) area code.) (Original version by Henry Dowst - KA6KNJ; revision on 1/17 by Kim Levitt, sysop of Hollywood RCPM/MBBS (213) 653-6398) 23-Jan-84 09:19:58-MST,775;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:19:53-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Jan 84 23:36 EST Date: Sat, 21 Jan 84 1:38:20 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: Need to contact RCPM Sysops All RCPM Sysops who are on the Info-Cpm mailing please reply to me via netmail so I can make up a list for distributing software update and coordination information. Please only those who have access to the net, because I will be sending out periodic notices via netmail to the list. Thanks. Keith Petersen, W8SDZ Arpanet: W8SDZ@MIT-MC or W8SDZ@SIMTEL20 or w8sdz@BRL Usenet: ...!duke!unc!brl-bmd!w8sdz 23-Jan-84 09:20:09-MST,1787;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:20:02-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Jan 84 23:58 EST Received: From Mit-Mc.ARPA by BRL via smtp; 21 Jan 84 1:55 EST Date: 21 January 1984 01:54 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: How to mangle a disk. To: DSullivan.CSC_SDO@hi-multics cc: POURN@mit-mc, INFO-CPM@brl In-reply-to: Msg of 19 Jan 1984 20:20 cst from DSullivan.CSC_SDO at hi-multics thanks; yet (and I have to rely on what others tell me for this) I am told that using 13 is safe; I do know that we have done what looks like what you describe with no bad consequences; the BIOS checks for it. One thing we do a lot is change disks while fioles are in the text editor; this makes backup copies. At one time the system used to go to the A disk once, then stay with the b; the double klunk was a bit slow, so Tony tried to eliminate it by using 37; no disasters with us, but we did get a hang conditin once. He looked into it; then we installed the program on MPM 8/16 systems, and there was a furious rewrite, and now it klunks to the A disk, then to the logged on disk, then the A gain, then writesd to the logged on. I ain't sure what's happening, but it is completely bulletproof; not even Alex can crash it and he can crash almost anything. It was then I was told that 37 could cause disasters, and after I became sensitized to listen for fn 37 horror stories I heard more; and now our wizards refuse to use 37; that is about my last comment on the subject, since I am reporting what others tell me, not what I really know. I have tried to study the documentation for those functions,a and they don't trell me a lot. 23-Jan-84 09:24:24-MST,2251;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:24:16-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 21 Jan 84 11:30 EST Date: Sat, 21 Jan 84 13:32:46 EST From: Bob Bloom (TECOM) <bbloom@brl> To: info-cpm@brl Subject: more fat on the dbase reset fire From my dBase II version 2.4 user manual: RESET [<drive>] The RESET command is used to reset the CP/M bit map after a diskette has been swapped. Normally, if a diskette is swapped, CP/M will not allow writes to take place util after a warm or soft boot has taken place. If <drive> is not specified, then the entire system will be reset. Unfortunately, neithr dBase nor the operating system can detemine which diskettes you may have swapped and I/O errors may result if a disk that has open files is replaced. If <drive> is specified, dBase checks to see whether any of its files are open on that drive and will prevent I/O errors. THE <DRIVE>-LESS FORM SHOULD THEREFORE NOT BE USED AND IS MAINTAINED FOR COMPATIBILITY REASONS ONLY. [Emphasis mine.] Do not swap and RESET the drive which contains the dBase system command files. So, have you tried the RESET <drive> form vs. the vanilla RESET? I'm interested because I'm currently involved in writting a hopefully saleable package that will require a disk reset. Also note that one cannot reset a disk containing a .CMD file that you are running even if no actual swap is made. I may also note that Ashton-Tate has been very helpfull when I call their service number. (Have your REGISTERED serial number handy - they ask for it.) Ask about the "Technical Reference Notes" and the "Technical Support Notes" - these give some hacker type information on some of the bugs that have been found and what to do about them. No notes on the reset command though. I've not had problems using the reset d: form - should I expect any? I am carefull to close all files first, never reset disks with either dbase or a running command file on it. The usual routine is to reset a floppy drive on a HD system in order to read/write back-up files while within dbase command file. bob bloom 23-Jan-84 09:24:35-MST,975;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:24:29-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 21 Jan 84 12:14 EST Received: From Ucb-Vax.ARPA by BRL via smtp; 21 Jan 84 14:19 EST Received: by UCB-VAX.ARPA (4.22/4.19) id AA28439; Sat, 21 Jan 84 11:17:54 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.13/4.10) id AA11683; Sat, 21 Jan 84 11:13:20 pst Received: by D.CC.Berkeley.ARPA (4.13/4.10) id AA23884; Sat, 21 Jan 84 11:09:15 pst Date: Sat, 21 Jan 84 11:09:15 pst From: Phil Lapsley <jlapsley%D.CC@berkeley> Message-Id: <8401211909.AA23884@D.CC.Berkeley.ARPA> Arpa-Address: jlapsley%D.CC@Berkeley To: info-cpm@brl Subject: SMAL/80 comments, anyone? Does anyone have any comments on the SMAL/80 "pseudo"-assembly language? I have seen some advertisements for it and it looks pretty good, but nothing beats feedback. Phil <jlapsley%D.CC@Berkeley> 23-Jan-84 09:29:46-MST,5890;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:29:31-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 22 Jan 84 23:24 EST Date: Sun, 22 Jan 84 23:17:09 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: MDM719 now available MDM719, the latest version in the MODEM7 series, is now available on SIMTEL20 in the MICRO:<CPM.MODEM7> directory and temporarily on MIT-MC in the FJW; directory. The file names are: On SIMTEL20 On MIT-MC MDM719.ASM MDM719 ASM MDM719.COM MDM719 COM (ITS-Binary format) MDM719.HEX MDM719 HEX MDM719.MSG MDM719 MSG (explains recent updates) M7NM-4.ASM M7NM 4ASM (latest phone number overlay which also can configure file transfer buffer size) It's not necessary to get the latest .ASM file. Get the .HEX or .COM file and use your present MDM7xx overlay. Remember to SAVE 69 after patching because recent versions are larger than those explained in the overlay patching instructions. NOTE: If using the phone number overlay to change the phone library numbers, be sure to use M7NM-4.ASM. (previous versions of M7NM will not work with this new version, as the file transfer buffer is now optional length, nominally set for 4k.) CHANGES FOR MDM719 ------------------ Fixed Irv's error in GETACK routine which prevented the robust improvement (added by Bob Plouffe) from working. Changed ACKNAK to NO so default will require valid NAK rather than non-ACK. This is part of the robust improvements, NOT because of any special ArpaNet require- ment. Changed SHOWHEX to true for distribution version so users would have HEX and DECIMAL reporting while transferring files (most users have told me they prefer to see both). Changed PMMI dialing pulse default to 10pps which most exchanges will accept. (This can be set to other pulse rates in the user overlay). - Keith Petersen, W8SDZ CHANGES FOR MDM718 ------------------ Code added to the auto-dial routine for the new Anchor 300/1200 modem which are selling at discount houses for $270 or so. Computer now beeps continuously anytime a connection is made to attract the operator's attention. Made the file transfer buffer length separate from that of the ASCII capture buffer (which remains 16k, one file- extent). Although the file transfer buffer has been 16k for well over a year, some of the newer floppy disk systems are quite slow and timeout errors could occur. The file transfer buffer size is set by default to 4k (32 records, 20H). It can be set at assembly time if using the entire MDM718.ASM file, or can be set in a few seconds with DDT by changing byte 0CFFH. The number library is now fully automatic to insure it always starts on a new page (such as 0D00H) regardless how much the auto-dial section is altered. Now responds to either "single digit" result codes (some Hayes Smartmodem users leave SW2 set that way) as well as the normal "verbose" result codes. To change the file transfer buffer size via DDT, change byte 0CFFH: 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 (then SAVE 69 MDM.COM, etc.) CHANGES FOR MDM717 ------------------ MDM717 allows characters with parity bit set to be properly handled during propagation overruns after an X-off. This occurs during a "save to disk" after the disk buffer fills. (This problem was noticed on Compuserve which sends some characters with the parity bit set.) The disk buffer size was restored to 16k. This is the length of "one file extent". Even slow floppy disks can store 16k in a reason- able amount of time. This should remain 16k for distribution copies of the source code although it can be easily changed to suit the indivi- dual user's own preference. (It could even be lengthened to 32k if you like fewer disk operations. This would make the printer buffer proportionally smaller but most printers are so fast the buffer is rarely filled in any case.) Fixed a stack problem introduced in v716 in the "V" flag routine to allow the user to show ASCII characters on the CRT during a file transfer. Fixed the "L" Logon feature so it should be consistent. At times it would run away without waiting for the echo characters, thus not correctly displaying the Logon message. Restored the ACKNAK feature developed for the exclusive use of the ARPANET networking group. When set normal ("YES") it resends a disk record after any NON-ACK character is received. This has been the normal configuration for all RCPM systems using the XMODEM file transfer program. When set "NO" for ARPANET use, it resends a record only after a NAK has been received. Other characters are ignored. Some systems will resend a NAK after a 10-second TIMEOUT. This slows things considerably, which allows the main frame time to recover if busy. This tends to run the phone bill higher for RCPM use, but is necessary for ARPANET to prevent aborting the file transfer too quickly if the main frame is busy. If a normal TIMEOUT sequence does attempt to abort the transfer with the ACKNAK equate set to NO, it will ask if you want to try again or abort. (RCPM systems would have already timed completely out with 10 consecutive errors, making the question worthless and misleading. ARPANET does not have a similar feature, and the user can manually force the transfer to continue.) - Irv Hoff 23-Jan-84 09:39:57-MST,1092;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 09:39:53-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 23 Jan 84 10:21 EST Date: Mon, 23 Jan 84 8:47:20 EST From: Keith Petersen <w8sdz@brl> To: Richard G Turner <rturner@brl> cc: Info-Cpm@brl-vgr Subject: Why MDM719 was released Irv Hoff continues to ignore our requests for moratoriums. He irresponsibly issued an update which, in my opinion, was not fully tested. Rather than have a "broken" version out there, I elected to fix his broken MDM718 and reissue it as MDM719 so we'd have something that WORKS while we wait for Ron Fowler to finish Beta-testing his new super modem program. I'm sorry if this issuing of a new version upsets anyone, but I've had it with Mr. Hoff's "ignore everyone else" attitude. We on the Info-Modem7 mailing list tried to tell him about some bugs he introduced in MDM717 when he "undid" some of Bob Plouffe's very nice ruggedization of the program because he "didn't agree with it". --Keith 23-Jan-84 10:37:10-MST,949;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 10:37:06-MST Received: From Hi-Multics.ARPA by BRL-VGR via smtp; 23 Jan 84 12:14 EST Date: 23 January 1984 11:14 cst From: Cargo.PD@hi-multics Subject: info-modem7 To: info-cpm@brl-vgr I am a beginning mdm7xx user (just got mdm716 working on my hardware). I would like to be informed of the changes and the reasons for them. How does on get on the info-modem7 newsgroup? If it is open to me I would like to join. My attitude is to wait until the versions of mdm7xx become stable before making a switch. My main concern has to do with the size of the systems required. This is often not stated when people say how great programs of this type are. Not that I don't appreciate the wonderful job you are doing; I just don't want to waste resources by pulling files I can't use. ..David S. Cargo (Cargo -at HI-Multics) 23-Jan-84 11:16:16-MST,992;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 11:16:11-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 23 Jan 84 12:41 EST Date: Mon 23 Jan 84 10:42:14-MST From: Keith Petersen <KPETERSEN@SIMTEL20.ARPA> Subject: Using MDM719 with CDOS To: Info-Cpm@BRL-VGR.ARPA Date: Mon, 23 Jan 84 From: Keith Petersen, W8SDZ To: All Subject: Using MDM719 with Cromemco CDOS CDOS users: Get M7CD-1.ASM, the overlay for Cromemco systems. After you overlay MDM719.COM using DEBUG, patch the following locations to NOPs (binary zeros): 2AB5, 2AB6, 2AB7, 2AB8. This will disable the CP/M disk stat call function 1Fh which is not implemented in the current version of CDOS. The MDM719 DIR function will then work, but will show 0k left on the disk. That's livable, and certainly better than before when CDOS gave an error message and jumped out of MDM719 to return to the system. --Keith ------- 23-Jan-84 13:14:08-MST,1504;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 13:14:03-MST Date: Mon, 23 Jan 84 14:26:19 EST From: Dave Towson (info-cpm) <cpmlist@brl-vgr> To: info-cpm@brl-vgr Subject: Information needed. I received the attached message from EDELHEIT@MITRE requesting information on the availability of a Christensen-protocol program that will run on his main- frames. Knowing nothing about CMS, I have responded with information about the Fortran programs in <cpm.vaxvms>, and the C programs in <unix.cpm>, both on Simtel20, and the KERMIT programs (different protocol) on Columbia-20. If anyone has any other/better ideas please pas them along to Jeff with an info copy to me so I'll know the answer if the question comes up again. Thanks. Date: 23 Jan 1984 0:34:49 EST (Monday) From: Jeffrey Edelheit <edelheit@mitre> Subject: Adding me to the distribution list and a communications question To: info-cpm-request@mit-mc Cc: edelheit@mitre I own an Osborne 1. It currently is a single density machine. I have been using MODEM7 for communications, but have found that I can't transmit files to either the C/70 or 4341, running CMS, that MITRE has here. Does anyone know of a program, preferably in the public domain, that will permit me to pass files from a CP/M machine to a larger, non-CP/M host? Virtually all the files I am attempting to pass are *.prn files. Thanks, Jeff Edelheit 23-Jan-84 13:57:39-MST,1203;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 23 Jan 84 13:57:34-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 23 Jan 84 15:21 EST Received: From Mit-Mc.ARPA by BRL via smtp; 23 Jan 84 15:13 EST Date: 23 Jan 1984 12:08 PST (Mon) Message-ID: <FHSU.11985968021.BABYL@WASHINGTON> From: Sam <FHSU@WASHINGTON.ARPA> Subject: looking for a micro around $300 I have a roomie who is looking at the TRaSh-80 color computer model 2. Does anyone have any comments about whether this is a good starter system? All he wants to do is to do text editing, formatting, and have a spelling checker. He also wants to attach an inexpensive printer (dot matrix?). He is looking to spend around $300-400 total. Can anyone give me suggestions and/or experiences? He is a drama major, so a simple system will do. He is also looking at the Commodore VIC-20 or 64. He has a TV, so if the system wouldn't require a monitor, that'd be a plus. I know there are adaptors for monitor-to-TV, but I've have bad experiences with these. Please reply to me directly, and I'll summarize for the nets if there are others interested. Thanks. 24-Jan-84 13:28:52-MST,907;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 24 Jan 84 13:28:47-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 24 Jan 84 14:41 EST Received: From Rochester.ARPA by BRL via smtp; 24 Jan 84 14:27 EST Received: by sen.rochester (3.327.3N) id AA22157; 24 Jan 84 14:31:18 EST (Tue) Received: by cay.Rochester (3.327.3N+) id AA01846; 24 Jan 84 14:27:39 EST (Tue) Message-Id: <8401241931.22157@sen.rochester> Date: 24 Jan 84 14:31:18 EST (Tue) From: Mike Ciaraldi <ciaraldi@Rochester.ARPA> Subject: CP/M-86 Linker To: info-cpm@brl.ARPA Does anyone know of a CP/M-86 compatible linkage editor which will produce a load map, showing where are the library subroutines and other external names get relocated? LINK-86 doesn't do this. It has a "MAP" option, but it does not give this information. Mike Ciaraldi ciaraldi@rochester 24-Jan-84 13:41:02-MST,1883;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 24 Jan 84 13:40:53-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 24 Jan 84 14:58 EST Received: From Rochester.ARPA by BRL via smtp; 24 Jan 84 14:44 EST Received: by sen.rochester (3.327.3N) id AA22304; 24 Jan 84 14:37:41 EST (Tue) Received: by cay.Rochester (3.327.3N+) id AA01865; 24 Jan 84 14:34:02 EST (Tue) Message-Id: <8401241937.22304@sen.rochester> Date: 24 Jan 84 14:37:41 EST (Tue) From: Mike Ciaraldi <ciaraldi@Rochester.ARPA> Subject: DRI C Compiler Woes To: info-cpm@brl.ARPA The new version of the Digital Research C compiler for CP/M-86 is in. This is the first one to use their new front-end/back-end technique. It shares the back-end (code generator) with the Fortran 77 compiler, and has a different front-end (parser). We received a letter in early December saying the new release would be sent in mid-December. After Christmas we called to ask where it was. They said we had to send in the form enclosed with the letter. There had, naturally enough, been no form with the letter, and no mention of a form in the letter. DRI took the information over the phone (address, serial number, etc., all of which they knew already, since they had sent the letter only to registered owners). The first week in January we called again, and found they were not actually shipping the update yet. It arrived last week and has most of the old bugs. Specifically, the floating-point I/O and floating-point to integer conversions are all messed up. So, we are using our own routines for these, which we had written for use with the old release. If anyone knows of a C compiler that runs under Concurrent CP/M-86 and handles more than 64K of data, we would appreciate knowing about it. Mike Ciaraldi ciaraldi@rochester 24-Jan-84 13:45:17-MST,1031;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 24 Jan 84 13:45:11-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 24 Jan 84 14:56 EST Received: From Rochester.ARPA by BRL via smtp; 24 Jan 84 14:36 EST Received: by sen.rochester (3.327.3N) id AA22387; 24 Jan 84 14:40:06 EST (Tue) Received: by cay.Rochester (3.327.3N+) id AA01869; 24 Jan 84 14:36:26 EST (Tue) Message-Id: <8401241940.22387@sen.rochester> Date: 24 Jan 84 14:40:06 EST (Tue) From: Mike Ciaraldi <ciaraldi@Rochester.ARPA> Subject: Z-100 Concurrent CP/M To: info-cpm@brl.ARPA Zenith has still not sent the preliminary copy of Concurrent CP/M-86 which they promised us for early December. Latest rumor (which they have neither confirmed nor denied) is that Digital Research is doing the port for them. They are using the new version of CCPM, which includes the GSX graphics package, windows, and MS-DOS compatibility. So, it may be worth the wait. Mike Ciaraldi ciaraldi@rochester 24-Jan-84 13:46:25-MST,1080;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 24 Jan 84 13:46:20-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 24 Jan 84 14:58 EST Received: From Rochester.ARPA by BRL via smtp; 24 Jan 84 14:46 EST Received: by sen.rochester (3.327.3N) id AA22668; 24 Jan 84 14:49:12 EST (Tue) Received: by cay.Rochester (3.327.3N+) id AA01893; 24 Jan 84 14:45:34 EST (Tue) Message-Id: <8401241949.22668@sen.rochester> Date: 24 Jan 84 14:49:12 EST (Tue) From: Mike Ciaraldi <ciaraldi@Rochester.ARPA> Subject: Re: Byte finally showed up To: info-cpm@brl.ARPA, info-micro@brl.ARPA, jpm@bnl.ARPA Cc: jpm@BRL.ARPA Mine showed up a while ago, but I was wondering if anyone else has noticed something like this: I see Byte on the stands one day. About a week later, people who have subscriptions in Rochester start to get them, and mine shows up about a week after that! In other words, my copy is consistently among the last that arrive in Rochester over a one-week span. Mike Ciaraldi ciaraldi@rochester 24-Jan-84 14:08:15-MST,947;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 24 Jan 84 14:08:10-MST Received: From Rochester.ARPA by BRL-VGR via smtp; 24 Jan 84 15:05 EST Received: by sen.rochester (3.327.3N) id AA23131; 24 Jan 84 15:06:00 EST (Tue) Received: by cay.Rochester (3.327.3N+) id AA01940; 24 Jan 84 15:02:21 EST (Tue) Message-Id: <8401242006.23131@sen.rochester> Date: 24 Jan 84 15:06:00 EST (Tue) From: Mike Ciaraldi <ciaraldi@Rochester.ARPA> Subject: Re: writing w/o opening To: Info-Cpm@brl-vgr.ARPA, w8sdz@brl.ARPA 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 25-Jan-84 12:34:45-MST,1009;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 25 Jan 84 12:34:40-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 25 Jan 84 8:08 EST Received: From Jpl-Vax.ARPA by BRL via smtp; 25 Jan 84 7:57 EST Date: 24 Jan 1984 2207 PST From: Bruce L. Conroy <BLC@jpl-vax> Subject: response to additional fat To: info-cpm@brl Cc: bbloom@brl Reply-To: BLC@jpl-vax With all deference to Ashton-Tate, I have never been able to make the <drive> form of reset do anything. Here is a CMD file which gives a BDOS EROR on B: R/O * test of reset function use b:dummy list use reset b: ? 'change disk B and hit "return"' wait reset b: create b:test return On the other hand, this CMD file performs as expected and so far has never crashed a directory or even lost a bit of data. * another test of reset function use b:dummy list use ? 'change disk B and hit "return"' wait reset create b:test use b:test list return ------ 25-Jan-84 16:49:42-MST,572;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 25 Jan 84 16:49:39-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 25 Jan 84 18:19 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 25 Jan 84 17:45 EST Date: Wed, 25 Jan 84 13:01 PST From: BillHolland.es@PARC-MAXC.ARPA Subject: Re: SPELL and its DICT.DIC In-reply-to: <[USC-ISID]12-Jan-84 14:03:31.ABN.ISCAMS> To: ABN.ISCAMS@usc-isid.ARPA cc: INFO-CPM@brl.ARPA Where is Simtel20 and how can I download from there using my micro? THANKS BILL 25-Jan-84 20:57:02-MST,874;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 25 Jan 84 20:56:59-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 25 Jan 84 22:36 EST Received: From Mitre.ARPA by BRL via smtp; 25 Jan 84 22:35 EST Date: 25 Jan 1984 22:27:58 EST (Wednesday) From: Jeffrey Edelheit <edelheit@mitre> Subject: Spell & spell.doc To: billholland.es@parc-maxc Cc: info-cpm@brl, edelheit@mitre Simtel20 is at White Sands Missle Range. For what machine are you planning to use Spell on? I have a copy of it for my Osborne and I got it from my local users group. Itt works fine, except that II do not have a 3.0 release of wordstar, so I can't use the automatic correction feature. Re how do you download-try using tcp. My question is, though, how are you going to get it to your pc? Regards, Jeff 26-Jan-84 08:57:58-MST,945;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 08:57:53-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Jan 84 1:24 EST Received: From Uci-750a.ARPA by BRL via smtp; 26 Jan 84 1:13 EST Date: 25 Jan 84 22:08:17 PST (Wed) To: Mike Ciaraldi <ciaraldi@rochester> cc: info-cpm@brl, info-micro@brl, jpm@bnl, jpm@brl, young@uci-750a Subject: Re: Byte finally showed up In-reply-to: Your message of 24 Jan 84 14:49:12 EST (Tue). <8401241949.22668@sen.rochester> From: Michal Young <young@uci-750a> When I lived in Oregon, my Byte consistently showed up about one week after it was on the newsstand. (Since moving I haven't noticed when it hits the newsstands.) The net traffic on this seems to indicate a lot of people dissatisfied with Byte subscription service. Is some concerted action appropriate? Any ideas? --Michal Young, young@uci 26-Jan-84 08:58:56-MST,969;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 08:58:52-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Jan 84 3:15 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 26 Jan 84 3:05 EST Date: Thu 26 Jan 84 00:09:30-PST From: Dan Kent <KENT@SUMEX-AIM.ARPA> Subject: Osborne to mainframe query, DSR sable? To: info-cpm@BRL.ARPA I'm relatively new O-1 user, trying to talk to a DEC 2060 through a Vadic VA3451 modem. I'd like to set the DSR (pin 6 on the O-1's RS232 port) to OFF when I'm just home computing, then toggle it ON (+5) when I load my communications software, to wake up the modem. As things stand now, the O-1 holds DSR high (+5), keeping the modem's DTR light on, and producing a scream on the phone line when I'm home computing andgo to answer an ordinary incoming ctel. call. Can I do it? Is this a general interest problem? Dan Kent ------- 26-Jan-84 09:00:50-MST,1027;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 09:00:46-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Jan 84 5:23 EST Received: From Mit-Mc.ARPA by BRL via smtp; 26 Jan 84 5:13 EST Date: 26 January 1984 05:14 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: help requested To: INFO-CPM@mit-mc I am doing an article for POPULAR on The Operating System Jungle". Part One is on the 8-bit micro world which is dominated by CP/M (and Apple DOS). I would like to be as complete as is required, but I'm not too familiar with many of the 8-bit rivals to CP/M. I'd appreciate SHORT info sketches of: Turbodos Oasis particularly if there are any enthusiasts for those out there. I have touched CDOS and TPM although if there's a TPM enthusiast I'd apprecaited hearing about it's good points. I've mentioned the late unlamented TRS-DOS and its viable successor L-DOS. What have I overlooked that's important? Thanks, JEP 26-Jan-84 09:00:59-MST,781;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 09:00:56-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Jan 84 5:23 EST Received: From Mit-Mc.ARPA by BRL via smtp; 26 Jan 84 5:18 EST Date: 26 January 1984 05:19 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: Byte finally showed up To: young@uci-750a cc: ciaraldi@rochester, info-cpm@brl, info-micro@brl, jpm@brl, jpm@bnl In-reply-to: Msg of 25 Jan 84 22:08:17 PST (Wed) from Michal Young <young at uci-750a> well, one of you might write me at BYTE New Hampshire and I can then (1) print that letter, and (2) m,ention the great whango of othermail on the subject; t hat might cause something to be done. It might not, too. JEP 26-Jan-84 09:04:06-MST,716;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 09:04:03-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Jan 84 8:47 EST Received: From Mit-Mc.ARPA by BRL via smtp; 26 Jan 84 8:40 EST Date: Thu 26 Jan 84 08:41:33-EST From: Willie Lim <WLIM@MIT-XX.ARPA> Subject: SPELL in C To: info-cpm@MIT-MC.ARPA, info-micro@MIT-MC.ARPA I am thinking of implementing Bill Ackerman's SPELL program in C for my IBM PC. He told that someone might have already done that. Will that someone please let me know who he is? If no one has implemented it in C, I'll probably write one and make it a public domain software. Willie ------- 26-Jan-84 09:05:08-MST,1284;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 09:05:03-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Jan 84 9:30 EST Received: From Usc-Isid.ARPA by BRL via smtp; 26 Jan 84 9:27 EST Date: 26 Jan 1984 03:57-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: Spell & spell.doc From: ABN.ISCAMS@usc-isid To: edelheit@mitre Cc: billholland.es@parc-maxc, info-cpm@brl Message-ID: <[USC-ISID]26-Jan-84 03:57:44.ABN.ISCAMS> In-Reply-To: The message of 25 Jan 1984 22:27:58 EST (Wednesday) from Jeffrey Edelheit <edelheit@mitre> Saw your msg on INFO-CPM. I DO have Word* 3.0 -- AND SPELL from SIMTEL20. WHAT auto-correction feature?? Also, re downloading to a PC - if the problem is moving binary files (especially that DICT.DIC) through your data channels -- I solved that (moving through an ornery TAC) with HEXIFYing it to ASCII, moving it down, using Word* to break the HEX file up into memory-sized (about 40KB) segments, MLOAD (or LOAD)ing it back to Binary, reassembling the resultant .COM segments into a nice big DICT.DIC again at the micro, and then ITSCVTing it to strip the ITS-binary header. Worked just fine! (Though what a kludge!) Regards, David Kirschbaum Toad Hall 26-Jan-84 09:13:52-MST,1245;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 09:13:43-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Jan 84 9:43 EST Received: From Sri-Unix.ARPA by BRL via smtp; 26 Jan 84 9:34 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 26 Jan 84 6:30-PST Date: 24 Jan 84 8:39:31-PST (Tue) To: info-cpm@brl From: ihnp4!houxm!hocda!hou3c!burl!clyde!akgua!psuvax!burdvax!bpa!ray@ucb-vax Subject: mpx16 info wanted Article-I.D.: bpa.213 Just wondering, does anyone in netland own an MPX-16 from MicroMint? Just wondered if they've got it running or if there is anything I should look out for. I've modified mine up to rev and am waiting for the operating system. I ord- ered the CPM-86, since I have 8" drives. I was told by their tech that I could not run the msdos with my shugarts. I thought there might be a way to modify it to support them, but I guess not. I'm kind of concerned about the CPM-86, since I'm not at all familiar even with 8 bit CPM. I'm sure this sounds naive but can you run 8 bit CPM (8080) withe CPM-86? I thought it might be possible that you could. Any info would be apprecia- ted. Ray Benash 26-Jan-84 09:34:25-MST,1041;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 09:34:20-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Jan 84 9:30 EST Received: From Usc-Isid.ARPA by BRL via smtp; 26 Jan 84 9:28 EST Date: 26 Jan 1984 04:00-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: Byte finally showed up From: ABN.ISCAMS@usc-isid To: young@uci-750a Cc: ciaraldi@rochester, info-cpm@brl, info-micro@brl Cc: jpm@bnl, jpm@brl Message-ID: <[USC-ISID]26-Jan-84 04:00:47.ABN.ISCAMS> In-Reply-To: The message of 25 Jan 84 22:08:17 PST (Wed) from Michal Young <young@uci-750a> Can't STAND it any more... I got my Byte in a timely fashion, about the same time I usually get it, and before the newstands. I live in North Carolina, which maybe affects delivery procedures and schedules. So here is no complaint. (I am NOT criticizing those who did NOT receive their Byte in a timely fashion, understand -- just that not ALL had that problem.) David Kirschbaum Toad Hall 26-Jan-84 09:48:21-MST,872;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 26 Jan 84 09:48:18-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Jan 84 10:36 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 26 Jan 84 10:27 EST Date: Thu, 26 Jan 84 07:26 PST From: TAFEL.pasa@PARC-MAXC.ARPA Subject: Re: Byte finally showed up In-reply-to: "young@uci-750a.ARPA's message of 25 Jan 84 22:08:17 PST (Wed)" To: Michal Young <young@uci-750a.ARPA> cc: Mike Ciaraldi <ciaraldi@rochester.ARPA>, info-cpm@brl.ARPA, info-micro@brl.ARPA, jpm@bnl.ARPA, jpm@brl.ARPA, young@uci-750a.ARPA I move that we all cancel our subscriptions and boycott the turkeys!!!!!! LETS TAKE A VOTE!!!! AN UPRISING IS THE ONLY WAY TO COMBAT SUCH A TERRIBLE, DEHUMANIZING (HUHHHH!) SITUATION!!! UP IN ARMS A RIOT!!!!!!!!!!! Hugo. 27-Jan-84 11:12:40-MST,595;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:12:37-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Jan 84 14:42 EST Received: From Brl-Vgr.ARPA by BRL via smtp; 26 Jan 84 14:30 EST Date: Thu, 26 Jan 84 14:15:57 EST From: Ron Natalie <ron@brl-vgr> To: ABN.ISCAMS@usc-isid cc: young@uci-750a, ciaraldi@rochester, info-cpm@brl, info-micro@brl, jpm@bnl, jpm@brl Subject: Re: Byte finally showed up Has anyone received their February Byte yet? o o ^ \_____/ 27-Jan-84 11:14:48-MST,2600;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:14:39-MST Date: Thu, 26 Jan 84 17:00:39 EST From: Dave Towson (info-cpm) <cpmlist@brl-vgr> To: info-cpm@brl-vgr, steveh@mit-mc Subject: [Stephen C. Hill: Stickyfying SIMTEL20] I thought this was of sufficiently general interest to pass along to the list. ----- Forwarded message # 1: Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 25 Jan 84 22:31 EST Date: 25 January 1984 22:32 EST From: Stephen C. Hill <STEVEH @ MIT-MC> Subject: Stickyfying SIMTEL20 To: info-cpm-request @ BRL-VGR cc: STEVEH @ MIT-MC Is there any method that can be used, while FTPing, that allows one to not have to keep repeating MICRO:<CPM.xxxx> every time that you GET a file or get a DIRectory listing? ----- End of forwarded messages Steve - Here at Aberdeen Proving Ground, we are running a lot of UNIX systems. This includes the machine from which info-cpm is distributed. UNIX allows for command-language programs, or shell-scripts, and we have used this feature to good advantage in making the job of FTPing much simpler. At present, this system of programs is rather klugey, being composed of many bits and pieces that all have to be available for the whole thing to work. But work it does. If I type the command line "cpmug 029 sap.asm" it automatically calls simtel20 and moves the file "micro:<cpmug.vol029>sap.asm" to a file having the name "sap.asm" in the calling directory. Using the editor, I can create a shell-script with entries on separate lines having the form "x program.name", and then use the search-and-replace feature of the editor to substitute the string "cpmug 029" (adjust for different volume number) in place of "x". That's fairly quick and easy to do. Then if I mark the file just created as executable, I can run it and move a whole batch of stuff automatically. The main file-mover portion of this kluge was written by Fred Brundick <fsbrn@brl-voc>. It creates command strings which are fed to FTP. It uses several "subroutines", which are in separate files. I've never added-up the number of different files that must be present to make what I've just described work, but it could easily be ten or so. It's a real lashup - but it WORKS! Fred is planning to make a nice civilized, all-in-one-hunk version someday, but it is now on the stack. Other than this sort of approach, I don't know of any way to reduce the typing involved in moving a bunch of files via FTP. Dave 27-Jan-84 11:17:07-MST,2117;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:16:57-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Jan 84 0:42 EST Received: From Rochester.ARPA by BRL via smtp; 26 Jan 84 18:14 EST Received: by sen.rochester (3.327.3N) id AA15956; 26 Jan 84 18:14:22 EST (Thu) Received: by cay.Rochester (3.327.3N+) id AA05827; 26 Jan 84 18:10:49 EST (Thu) Message-Id: <8401262314.15956@sen.rochester> Date: 26 Jan 84 18:14:22 EST (Thu) From: Mike Ciaraldi <ciaraldi@Rochester.ARPA> Subject: Re: Byte finally showed up To: ABN.ISCAMS@usc-isid.ARPA, ron@brl-vgr.ARPA Cc: info-cpm@brl.ARPA, info-micro@brl.ARPA, jpm@bnl.ARPA, jpm@brl.ARPA, young@uci-750a.ARPA 1) I am happy to hear that at least someone gets his Byte in a timely fashion. This has been bugging me for years, less so now that I get so many magazines I can't read them all anyway. About four years ago, I complained to Carl Helmers when he was in town. He didn't seem very interseted, and just said, "We send them to the Post Office", ask them. I called the Byte subscription number, and they said, "We send them to the POst Office and the newsstands the same day, so it must be the mail's fault." I asked the Post Office, and they said it probably did not take two weeks to get from NH to NY every month. 2) Cancelling our subscriptions is somewhat like cutting off noses to spite faces. 3) So, I suggest, we take a poll on when the, say February issue shows up, then send the results to Byte, as J. Pournelle suggested. Let's all be on the lookout for newsstand and subscription copies. Has February Byte reached anyone yet? What's on the cover? Mike Ciaraldi, ciaraldi@rochester P.S. Every single person need not sennd mail. Maybe it shoukld be tht the first one to see a newsstand copy in his or her city should post, likewise the first sub, then anyone who gets a sub copy more than a day or two later could follow up with a message. Hopefully, doing this ONCE will generate some statistics without overloading the network. 27-Jan-84 11:17:28-MST,1200;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:17:23-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Jan 84 3:19 EST Received: From Mit-Mc.ARPA by BRL via smtp; 27 Jan 84 3:15 EST Date: 27 January 1984 03:19 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: Byte finally showed up To: ciaraldi@rochester cc: ABN.ISCAMS@usc-isid, info-cpm@brl, info-micro@brl, jpm@brl, jpm@bnl, young@uci-750a, ron@brl-vgr In-reply-to: Msg of 26 Jan 84 18:14:22 EST (Thu) from Mike Ciaraldi <ciaraldi at Rochester.ARPA> 1> I have Feb BYTE sent to me FEDEX from teh printer; the editorial people got theirs also same way same time. 2. They should NOW be in Post Office. Understand: the darned things are so big that only a couple of printers in the country can hanle them. I believe the printer we now use does also Sears roebuck catalogs. 3. St atistcs posted on this net will do NO good. LETTERS to the editorial office -- to me for that matter -- will POSSIBLY get some attention, possibly not. 4. Cancelling subscription seems drastic. Who does better on getting out that much data so regularly? 27-Jan-84 11:18:25-MST,2562;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:18:17-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Jan 84 3:41 EST Received: From Mit-Mc.ARPA by BRL via smtp; 27 Jan 84 3:29 EST Date: 27 January 1984 03:33 EST From: Herb Lin <LIN@mit-mc> Subject: multiple FTP gets from SIMTEL20 for CPM stuff.. To: cpmlist@brl-vgr cc: STEVEH@mit-mc, info-cpm@brl In-reply-to: Msg of Thu 26 Jan 84 17:00:39 EST from Dave Towson (info-cpm) <cpmlist at brl-vgr> From: STEVEH @ MIT-MC Is there any method that can be used, while FTPing, that allows one to not have to keep repeating MICRO:<CPM.xxxx> every time that you GET a file or get a DIRectory listing? The way I automate this process is the following: 1. give FTP the SCRIPT command; this files away the terminal output into a file of your choosing. Call this file FOO. 2. do DIR MICRO:<CPM.xxxx>; this produces a directory listing in FOO. 3. edit FOO using the keyboard macro facility in EMACS to give the appropriate lines. Example: FOO initially contains this: dir micro:<CPM.filutl> <- this is the command I issued List started. <- this is what FTP tells me. micro:<CPM.filutl> <- this is the name of the directory I asked about compare.asm.20 <- this is a file name in the directory. sortv.asm.3 <- this is a second file in the directory. edit this file to look like this: get mc:users2;COMP ASM <- get is the FTP command for getting a local file. MC:USERS2;COMP ASM is the file name for the file you want to get. micro:<cpm.filutl>compare.asm.20 <- COMPARE.ASM is the file name you want to get. get mc:users2;SORT ASM <- this is the local file name. micro:<cpm.filtul>sortv.asm.3 <- SORTV.ASM is the second file you want. The EMACS keyboard macro can be used to place the directory in front of every desired file, and also to build the local file name from the desired file name. For example, on MC you can take the first six characters of the first filename on SIMTEL and the last three characters of the file type on SIMTEL. Save the resulting file as BAR (For example) 4. LAST STEP. issue to FTP the XFILE command. This command takes a command file and executes the contents just as though they were typed in at the keyboard. lemme know if I can help more. Now, if only some version of MODEM would allow taking of files received from a mainframe to a micro froma from a command file... 27-Jan-84 11:19:22-MST,1045;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:19:18-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Jan 84 4:13 EST Received: From Cmu-Cs-A.ARPA by BRL via smtp; 27 Jan 84 4:08 EST Date: 27 Jan 84 0410 EST (Friday) From: George.Wood@cmu-cs-a To: ABN.ISCAMS@usc-isid, ciaraldi@rochester Subject: Re: Byte finally showed up CC: info-cpm@brl, info-micro@brl, POURNE@mit-mc In-Reply-To: <[USC-ISID]26-Jan-84 04:00:47.ABN.ISCAMS> Message-Id: <27Jan84.041012.GW90@CMU-CS-A> Sorry; but I can't stand it either. It's January 26th and I STILL don't have my January BYTE. JEP says the February issues have left the printers. I think he missed the point about statistics: use the net for gathering and reporting them to net users, and uSnail for reporting final results to Byte, the post office, etc. But perhaps someone would volunteer to accept all reports instead of clogging the net bb's, and compile a report at the end of the month. George 27-Jan-84 11:20:04-MST,1024;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:19:59-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 27 Jan 84 4:41 EST Date: 27 January 1984 04:42 EST From: Gail Zacharias <GZ@mit-mc> Subject: [Stephen C. Hill: Stickyfying SIMTEL20] To: cpmlist@brl-vgr cc: STEVEH@mit-mc, info-cpm@brl-vgr In-reply-to: Msg of Thu 26 Jan 84 17:00:39 EST from Dave Towson (info-cpm) <cpmlist at brl-vgr> The FTP protocol has a CWD (change working directory) command. Check the documentation on your FTP program to see whether it provides an interface to it. For instance in TOPS-20 FTP you should be able to say CWD MICRO:<CPM.FILUTL> to change the default directory to micro:<cpm.filutl>. If there is no such command in your FTP, or if it doesn't work, check if there is a "quote" or "verbatim" command, which you can use to send CWD raw. For instance in ITS FTP you should be able to say QUOTE CWD MICRO:<CPM.FILUTL> to get the same effect. 27-Jan-84 11:20:32-MST,1192;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:20:28-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Jan 84 5:01 EST Received: From Sri-Kl.ARPA by BRL via smtp; 27 Jan 84 4:48 EST Date: 27 Jan 1984 01:49-PST Sender: BILLW@sri-kl Subject: Re: multiple FTP gets from SIMTEL20 for CPM stuff.. From: BILLW@sri-kl To: LIN@mit-mc Cc: cpmlist@brl-vgr, STEVEH@mit-mc, info-cpm@brl Message-ID: <[SRI-KL]27-Jan-84 01:49:51.BILLW> In-Reply-To: The message of 27 January 1984 03:33 EST from Herb Lin <LIN@mit-mc> Well, there is a set default directory command specified in the FTP protocol, but it doesnt seem to work on many tops20 sites. The name of the command also depends on your user FTP program. The CMU FTP uses CPATH, as in CPATH MICRO:<CPM.APPLE> If your FTP does not support an equivilent command, you can probably use a quote-like command. If simtel were up, Id test this out. Oh well. By the way, MODEM20 has had wildcard file transfers added to it, and they almost work. An option to take a list of files from an indirect file would be easy to add. Ill look into it. BillW 27-Jan-84 11:21:44-MST,764;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:21:41-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Jan 84 9:37 EST Received: From Brl-Bmd.ARPA by BRL via smtp; 27 Jan 84 9:36 EST Date: Fri, 27 Jan 84 9:28:50 EST From: BRINT <abc@brl-bmd> To: Ron Natalie <ron@brl-vgr> cc: ABN.ISCAMS@usc-isid, young@uci-750a, ciaraldi@rochester, info-cpm@brl, info-micro@brl, jpm@bnl, jpm@brl Subject: Re: Byte finally showed up Has anyone received his/her IEEE Transactions on Computers for November or December, 1983? I have received Scientific American for February, 1984. The NY Times Book Review for 29 January 1984 arrived the other day. 27-Jan-84 11:22:15-MST,1034;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:22:11-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Jan 84 9:48 EST Received: From Utexas-20.ARPA by BRL via smtp; 27 Jan 84 9:41 EST Date: Fri 27 Jan 84 08:41:24-CST From: Kim Korner <CS.KORNER@UTEXAS-20.ARPA> Subject: Re: Byte finally showed up To: info-cpm@BRL.ARPA In-Reply-To: Message from "Jerry E. Pournelle <POURNE@mit-mc>" of Fri 27 Jan 84 03:19:00-CST Do let's remember that ARPANET collected statistics are to be used selectively and generally without attribution to the net. I'm not sure where in the profit/persoanl gain spectrum BYTE delivery dates fall, but this is the stuff of which Proxmireing types make their living (a multimillion dollar DOD network was used to coordinate personal magaine subscriptions....). Info-CPM is too nice a thing to have go away just because we failed to keep the standard arpanet low public profile. -KM< ------- 27-Jan-84 11:23:15-MST,856;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:23:11-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Jan 84 10:26 EST Received: From Usc-Isid.ARPA by BRL via smtp; 27 Jan 84 10:22 EST Date: 26 Jan 1984 20:35-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: Byte finally showed up From: ABN.ISCAMS@usc-isid To: ron@brl-vgr Cc: young@uci-750a, ciaraldi@rochester, info-cpm@brl Cc: info-micro@brl, jpm@bnl, jpm@brl Message-ID: <[USC-ISID]26-Jan-84 20:35:01.ABN.ISCAMS> In-Reply-To: The message of Thu, 26 Jan 84 14:15:57 EST from Ron Natalie <ron@brl-vgr> Now look, Ron -- don't go starting that up! I've purged my poor overflowed directory of 50 bloody Byte messages already. So leave February alone already! (Jeeeez!) David Kirschbaum Toad Hall 27-Jan-84 11:24:25-MST,2663;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 11:24:13-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Jan 84 10:49 EST Received: From Brl-Voc.ARPA by BRL via smtp; 27 Jan 84 10:41 EST Date: Fri, 27 Jan 84 10:24:44 EST From: "Ferd Brundick (LTTB)" <fsbrn@brl-voc> To: Herb Lin <LIN@mit-mc> cc: cpmlist@brl-vgr, STEVEH@mit-mc, info-cpm@brl Subject: Re: multiple FTP gets from SIMTEL20 for CPM stuff.. Haaah, Our local implementation of ftp doesn't have the 'script' or 'xfile' commands, so we have to use re-directed input. I grabbed all the cpmug catalog files (1 per directory) by building a file containing the following commands: verbose tenex get "micro:<cpmug.vol001>catalog" catalog.001 get "micro:<cpmug.vol002>catalog" catalog.002 ... (more of the same) bye I actually built this file with a shell script that used the 'while' construct: i=1 while test $i -lt 10 do echo "get \"micro:<cpmug.vol00$i>catalog\" catalog.00$i" >>ftp.commands i=`expr $i + 1` done (The sequence \" protects the double-quote) Once you have built the ftp command file, you enter the following command: ftp simtel20 <ftp.commands If you are transferring a large number of files, you may want to run the job in the background by putting a '&' after the command line: ftp simtel20 <ftp.commands & If the files require post-processing to remove the ITS header or convert CR/LF to LF (for UN*X compatibility) put the ftp line in a second shell script: ftp simtel20 <ftp.commands for i in list_of_files do behead $i temp del.cr temp $i.fixed done While this method requires a lot of work initially, it is much easier than manually typing lots of 'get' commands. The super-ftp file transfer program that Dave Towson mentioned will (someday) be an interactive C version of the method outlined above (but not this weekend -- I'm patching WordStar). If you have any questions, problems, or suggestions, feel free to write to me: <fsbrn@brl-voc> By the way, an easy way to transfer a small number of files is to put part of the name in a Special Function key (I do this on an hp terminal): get "micro:<cpmug.vol which saves some of the typing (and I don't forget what I'm supposed to use). dsw, fferd Fred S. Brundick USABRL, APG, MD. <fsbrn@brl-voc> 27-Jan-84 13:14:56-MST,992;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 13:14:52-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 27 Jan 84 14:42 EST Date: Fri 27 Jan 84 12:42:04-MST From: Keith Petersen <KPETERSEN@SIMTEL20.ARPA> Subject: Using MDM720 with CDOS To: INFO-CPM@BRL-VGR.ARPA Date: Mon, 27 Jan 84 From: Keith Petersen, W8SDZ To: All Subject: Using MDM720 with Cromemco CDOS CDOS users: Get M7CD-1.ASM, the overlay for Cromemco systems. After you overlay MDM720.COM using DEBUG, patch the following locations to NOPs (binary zeros): 2AB7, 2AB8, 2AB9, 2ABA. This will disable the CP/M disk stat call function 1Fh which is not implemented in the current version of CDOS. The MDM720 DIR function will then work, but will show 0k left on the disk. That's livable, and certainly better than before when CDOS gave an error message and jumped out of MDM720 to return to the system. --Keith ------- 27-Jan-84 16:07:51-MST,970;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 16:07:44-MST Received: From Mit-Multics.ARPA by BRL-VGR via smtp; 27 Jan 84 17:39 EST Received: from CISL-SERVICE-MULTICS.ARPA by MIT-MULTICS.ARPA TCP; 27-Jan-1984 17:33:33-est Received: from HIS-PHOENIX-MULTICS.ARPA by CISL-SERVICE-MULTICS.ARPA dial; 27-Jan-1984 17:27:15-est Date: Fri, 27 Jan 84 15:25 MST From: Dreschel%his-phoenix-multics.arpa@BRL-VGR.ARPA Subject: problem with OMIKRON To: info-cpm@BRL-VGR.ARPA Message-ID: <840127222540.948423@HIS-PHOENIX-MULTICS.ARPA> Help! I mailed an order to Omikron Systems in Berkely, CA in the second week of Oct. 83 and have still not received the hardware and software. They have not responded to my last two letters either. I paid by money order so I am beginning to fear I'll never see my money again. Any suggestions would be greatly appreciated.Z( Bill Dreschel 27-Jan-84 16:48:00-MST,953;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 16:47:53-MST Received: From Amsaa.ARPA by BRL-VGR via smtp; 27 Jan 84 18:22 EST Date: Fri, 27 Jan 84 18:12:20 EST From: David Towson (CSD) <towson@amsaa> To: Dreschel%his-phoenix-multics.arpa@brl-vgr.arpa cc: info-cpm@brl-vgr.arpa Subject: Re: problem with OMIKRON Bill - Here is some information concerning your problem. Good luck! The following is from the February issue of "80 Micro". It is from their "80 Alert" column on page 14. "80 Micro has received complaints from readers that Omikron Systems (1127 Hearst St., Berkeley, CA 94702) has not filled orders or issued refunds. Omikron informed 80 Micro that it was issuing refunds and expected to be shipping within a few weeks. Customers who contacted 80 Micro had received refund checks by press time." Dave towson@amsaa 27-Jan-84 18:37:11-MST,639;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 18:37:07-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Jan 84 20:14 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 27 Jan 84 20:12 EST Date: Fri 27 Jan 84 17:15:59-PST From: William Pearson <PEARSON@SUMEX-AIM.ARPA> Subject: Simtel-20 directories To: info-cpm@BRL.ARPA There seem to be a lot more files available on Simtel-20 than I am aware of, e.g. UNIX.CPM and CPMUG.?. I wonder if there is a more complete list of what is available in MICRO: than CPM.CRCLST? Bill Pearson ------- 27-Jan-84 21:35:18-MST,1553;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 27 Jan 84 21:35:13-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Jan 84 23:11 EST Received: From Mit-Mc.ARPA by BRL via smtp; 27 Jan 84 23:04 EST Date: 27 January 1984 23:05 EST From: Stephen C. Hill <STEVEH@mit-mc> Subject: Making WordStar 3.3 come up faster To: INFO-CPM@mit-mc cc: STEVEH@mit-mc I have significantly increased the speed with which WordStar 3.3 comes up. First of all, I had to get rid of the silly MicroPro advertisements. This was accomplished by using a combination of DDT and ZDASM. I traced the beginning of the program, breakpointing just after each CALL instruction until I discovered the guilty module. Eventually, I narrowed it down to where I replaced the instruction located at 3CEB with a jump relative of 3A, which branched around all of the craziness that MicroPro put up. That just left getting rid of the long delay loops that they had left in there. I could have used the same trick of branching around some code, but the faster fix was to change the three delay-count bytes located at 2B0 through 2B2. I have changed them all to 0, and have noticed no problems of leaving things on the screen with the Molecular MT-100 terminals. Give it a try with larger numbers, if your terminals have any problems, although they probably won't. Someone will probably tell me that there is an option int the WINSTALL menu, but I sure couldn't find it. 30-Jan-84 08:35:33-MST,1178;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 08:35:28-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 30 Jan 84 8:52 EST Date: Sun, 29 Jan 1984 13:27 EST Message-ID: <SJOBRG.11987522481.BABYL@MIT-OZ> From: SJOBRG%MIT-OZ@MIT-MC.ARPA To: Info-Cpm@BRL-VGR.ARPA Subject: Heath/Zenith Z-100 extended video Cc: sjobrg%MIT-OZ@MIT-MC.ARPA In-reply-to: Msg of 14 Dec 1983 20:57-EST from Keith Petersen <w8sdz at brl> The November 1983 issue of Microsystems magazine carries a review of the Zenith Z-100 computer system. The review states: The video board allows an alternate display format, which could be used to provide an interlaced display of 640 by 525 pixels, but no information is provided on specific programming for that purpose. (p. 100) I have often lamented the fact that many video displays (such as the IBM PC) only go up to 400 lines vertically when 480 would have permitted a square aspect ratio (so important when dealing with digitized images as I often do). Does anyone have any information about this capability in the Zenith machine? Thanks. 30-Jan-84 09:07:37-MST,669;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 09:07:32-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Jan 84 9:01 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 29 Jan 84 2:12 EST Date: Sat 28 Jan 84 23:15:51-PST From: Leslie Zatz <ZATZ@SUMEX-AIM.ARPA> Subject: Cat program for CPM 1.4 To: info-cpm@BRL.ARPA The NCATxx programs show the amount of free space on each diskette with CPM 2.x but will not with CPM 1.4 because DSKFRE must bee disabled (BDOS function not available). Does anyone know of a cataloging program that does what NCAT does for CPM 1.4? ------- 30-Jan-84 14:29:44-MST,1244;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:29:39-MST Received: From Usc-Isid.ARPA by BRL-VGR via smtp; 30 Jan 84 8:58 EST Date: 28 Jan 1984 23:22-PST Sender: ABN.ISCAMS@usc-isid Subject: IOBYTE on the Decision I From: ABN.ISCAMS@usc-isid To: INFO-CPM@brl-vgr Cc: ABN.ISCAMS@usc-isid, INFO-MICRO@brl-vgr Message-ID: <[USC-ISID]28-Jan-84 23:22:48.ABN.ISCAMS> I think I have succeeded in implementing the IOBYTE on my Decision I. I adapted the original North Star segments of Morrow's CBIOS&, and it seems to work just fine (though haven't figured out many applications for the additional capability yet). Gotta fire up GENERIC KERMIT and try out the IOBYTE configuration to see if that application works. Any Decision I owners out there interested -- yell, and I'll work up the patches in a document. (But give me a few days.) Still no luck on adapting the BIOS to run soft sector 5 1/4" floppy drives (as opposed to the N* hard sector ones it was written for) - but I'm told I'll need a newer (Ver. 2.5) DJ/DMA PROM and am inquiring about that through my vendor now. I'll keep you posted. David Kirschbaum Toad Hall (ABN.ISCAMS@USC-ISID) 30-Jan-84 14:29:52-MST,1014;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:29:48-MST Received: From Usc-Isid.ARPA by BRL-VGR via smtp; 30 Jan 84 8:58 EST Date: 29 Jan 1984 18:33-PST Sender: ABN.ISCAMS@usc-isid Subject: IOBYTE on the Decision I From: ABN.ISCAMS@usc-isid To: INFO-CPM@brl-vgr Cc: abn.iscams@usc-isid Message-ID: <[USC-ISID]29-Jan-84 18:33:44.ABN.ISCAMS> Yep -- my IOBYTE implementation works (couldn't be absolutely sure at 0400 when things were kind of stupid out). Now, gentlesirs and madams -- what do I do with it? Neat, I guess to list a document to printer or screen, but I could do that anyway! What neat, wonderful, otherwise impractical/impossible tricks can I do with an IOBYTE that I couldn't do before? (The Toad, for some reason, doesn't seem surprised that such strange redirection is occurring in its innards - computers can be so complacent sometimes!) Regards, David Kirschbaum Toad Hall (ABN.ISCAMS@USC-ISID) 30-Jan-84 14:30:03-MST,972;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:29:58-MST Received: From Sri-Nic.ARPA by BRL-VGR via smtp; 30 Jan 84 9:04 EST Received: from USC-ECLB by SRI-NIC with TCP; Sun 29 Jan 84 20:29:41-PST Date: 29 January 1984 20:29-PST (Sunday) Sender: TLI@usc-eclb From: Tony Li <Tli@usc-eclb> To: Info-Cpm@brl-vgr Subject: Re: CP/M 68K Reply-to: Tli@usc-eclb Home: 1275 W. 29th #211, Los Angeles, Ca. 90007 (213) 737-8168 Hi, There is another release of CP/M-68K on the way. It includes some fixes to the C compiler and the OS. I have played with it in-house. From what I have heard on the net, it may take quite a while to get distributed. As far as DRI compilers go, there seems to be a wide variation in quality. Some are very good, and some are very poor. The release that I know of for the in-house C compiler falls into the latter category. Sigh. Cheers, Tony ;-) 30-Jan-84 14:30:31-MST,1378;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:30:22-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Jan 84 9:02 EST Received: From Sri-Unix.ARPA by BRL via smtp; 29 Jan 84 5:09 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 29 Jan 84 2:11-PST Date: 4 Feb 84 7:37:18-EST (Sat) To: info-cpm@brl From: hplabs!hao!seismo!philabs!rdin!perl@ucb-vax Subject: Re: Function 37 - drive door open Article-I.D.: rdin.347 Willard Korfhage suggests that the index hole sensor can be used as a drive door sensor since the disk stops spinning when you open the door. This would not work on most 5.25" drives since the disk times out and stops spinning whenever it is not being accessed. (nice try) As a point of interest to this discussion, Hewlett-Packard used to make a machine called the HP250. Although it didn't run CP/M or anything like it, it had a kind of 8" floppy drive I have never seen elsewhere. The drive door could be locked by software so the user could be physically prevented from removing the disk! Also, when you closed the door, you could hear the machine accessing the disk; probably reading the directory. (Note that the HP250 was a multi-tasking multi-user system.) Robert Perlberg Resource Dynamics Inc. New York philabs!rdin!rdin2!perl 30-Jan-84 14:31:05-MST,1385;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:30:57-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Jan 84 10:59 EST Received: From Stl-Host1.ARPA by BRL via smtp; 29 Jan 84 11:09 EST Date: 29 Jan 1984 10:10 CST (Sun) Message-ID: <WANCHO.11987497510.BABYL@STL-HOST1> From: WANCHO@stl-host1 To: "Stephen C. Hill" <STEVEH@mit-mc> Cc: INFO-CPM@brl Subject: Making WordStar 3.3 come up faster In-reply-to: Msg of 27 Jan 1984 22:05-CST from Stephen C. Hill <STEVEH at mit-mc> Steve, Several years ago someone else also came up with the idea of changing the delay bytes to zero, as well as a couple of other items. He since discovered that zero was NOT correct, although it appears to work. The correct value for each of those delay bytes should be one. About a year ago, I received verbal permission to publish his patch file, stripped of identification, but I forgot to actually do so until you brought the subject up. I will upload the file to the SIMTEL20 tomorrow. Look for PATCHWS.ASM in MICRO:<CPM.WSTAR>. It applies to WS 3.0, and may have to be slightly modified for 3.3. The remainder of the patch concerns itself with intercepting the console status calls, and making the actual calls every 16th. This significantly improves the screen updates! --Frank 30-Jan-84 14:31:19-MST,1477;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:31:11-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Jan 84 10:59 EST Received: From Stl-Host1.ARPA by BRL via smtp; 29 Jan 84 11:35 EST Date: 29 Jan 1984 10:35 CST (Sun) Message-ID: <WANCHO.11987502112.BABYL@STL-HOST1> From: WANCHO@stl-host1 To: William Pearson <PEARSON@SUMEX-AIM.ARPA> Cc: INFO-CPM@brl Subject: Simtel-20 directories In-reply-to: Msg of 27 Jan 1984 19:15-CST from William Pearson <PEARSON at SUMEX-AIM.ARPA> There are four major directories in MICRO: accessible via FTP. Each has its own dir.CRCLST file in the major directory. They are: MICRO:<CPM.*> - all the archives formerly on MC, updated MICRO:<CPMUG.VOLnnn> - nnn = 001-054, 078-090 MICRO:<SIGM.VOLnnn> - nnn = 000-145 MICRO:<UNIX.*> - a fledgling repository of UNIX-related files BTW, contributions of public domain software are always actively solicited. Submissions to MICRO:<CPM.*> are coordinated by Keith Petersen, W8SDZ@SIMTEL20. Submissions to MICRO:<UNIX.*> are coordinated by Rick Conn, RCONN@SIMTEL20 (or rconn@BRL). Incidentally, MICRO: is the name of a nearly full RP06. We are anticipating additional large collections of UNIX software to be available soon. At that point, we expect another site may be online, and the UNIX files moved to their new home. Look for another announcement. --Frank 30-Jan-84 14:31:32-MST,936;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:31:28-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Jan 84 11:00 EST Received: From Usc-Isid.ARPA by BRL via smtp; 29 Jan 84 11:45 EST Date: 28 Jan 1984 22:52-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: Heath/Zenith Z100 Newsletter From: ABN.ISCAMS@usc-isid To: hplabs!hao!seismo!ut-sally!ut-ngp!knutson@ucb-vax Cc: info-cpm@brl Message-ID: <[USC-ISID]28-Jan-84 22:52:11.ABN.ISCAMS> In-Reply-To: The message of 19 Jan 84 19:51:18-PST (Thu) from hplabs!hao!seismo!ut-sally!ut-ngp!knutson@ucb-vax Jim (et al), I too am quite interested in the INFO-HZ100 Digest. I saw a single first edition come over the net weeks ago from a student (?) at some university (Clarkson?), but nary a peep since. Please inform if anyone has a pointer. David Kirschbaum Toad Hall (ABN.ISCAMS@USC-ISID) 30-Jan-84 14:31:44-MST,1303;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:31:37-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Jan 84 11:01 EST Received: From Usc-Isid.ARPA by BRL via smtp; 29 Jan 84 11:45 EST Date: 28 Jan 1984 22:58-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: Zenith 100 From: ABN.ISCAMS@usc-isid To: hplabs!hao!seismo!ut-sally!ut-ngp!garey@ucb-vax Cc: info-cpm@brl Message-ID: <[USC-ISID]28-Jan-84 22:58:17.ABN.ISCAMS> In-Reply-To: The message of 19 Jan 84 18:48:41-PST (Thu) from hplabs!hao!seismo!ut-sally!ut-ngp!garey@ucb-vax Ref your question on the correctness of the Z100's S100 bus -- I closely queried a sales team recently here at Ft Bragg (including the area manager or some such from Charlotte). They confirm (for what it's worth) a true S100 bus, but could give absolutely no information or recommendations on what (if anything) else would run on it beside Zenith boards. I'm watching this myself, since I'd like to stay with S100 to maintain compatibility/backup with my Toad (a Morrow Decision I). No word yet from the USAF or USN - not enough of them out there yet, I guess, or not enough adventuresome people to stick alien boards in a Govt-owned machine! David Kirschbaum Toad Hall 30-Jan-84 14:32:46-MST,616;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:32:42-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Jan 84 11:20 EST Received: From Mit-Mc.ARPA by BRL via smtp; 30 Jan 84 5:31 EST Date: 30 January 1984 05:31 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: Zenith 100 To: hplabs!hao!seismo!ut-sally!ut-ngp!garey@ucb-vax cc: info-cpm@brl In-reply-to: Msg of 19 Jan 84 18:48:41-PST (Thu) from hplabs!hao!seismo!ut-sally!ut-ngp!garey at ucb-vax buy it quick that's a good machine, and for a Kaypro price... grab it 30-Jan-84 14:34:16-MST,3902;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:34:03-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Jan 84 11:33 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 30 Jan 84 9:57 EST Date: Mon, 30 Jan 84 09:50 EST From: Phillips.henr@PARC-MAXC.ARPA Subject: Apple Modem Program To: "Ferd Brundick (LTTB)" <fsbrn@brl-voc.ARPA> cc: Phillips.henr@PARC-MAXC.ARPA, ABN.ISCAMS@usc-isid.ARPA, info-cpm@brl.ARPA Is this program available in this area ?? I am in desperate need ! (or better yet, can I send you a disc ??) I am looking for a way to send CP/M files between Apple Super Serial and an 820-II. Thanks for any help you can offer !! Mark --------------------------- Received: from BRL-VGR.ARPA by PARC-MAXC.ARPA; 20 JAN 84 09:41:50 PST Redistributed: XeroxInfo-CPM^.wbst Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Jan 84 10:03 EST Received: From Brl-Voc.ARPA by BRL via smtp; 20 Jan 84 12:05 EST Date: Fri, 20 Jan 84 11:56:24 EST From: "Ferd Brundick (LTTB)" <fsbrn@brl-voc.ARPA> To: ABN.ISCAMS@usc-isid.ARPA cc: info-cpm@brl.ARPA Subject: Re: "?Public domain version of MODEM in Apple Pascal?" Hi, Since Toad Hall has also expressed interest in an Pascal Modem7, I am sending a copy of my original reply to the list at large. - - - - - - - - - - There <IS> a modem3 program written in Apple (SCUD) Pascal. The files are on simtel20 in MICRO:<CPM.PASCAL> and the names are given below. I've never used the program because I don't own an Apple, but I do have the MODEM3.PAS file if you can't get it from simtel20 (I can get and send you the other 2 files if you need them). Anyway, below is the header info from the main file. dsw, fferd Fred S. Brundick USABRL, APG, MD. <fsbrn@brl-voc> PROGRAM modem; {Written by Jack M. Wierda Chicago Illinois This program is in the public domain. LANGUAGE: UCSD Pascal FILES: MODEM3.PAS -- main program MDM3-Z80IO.Z80 -- serial line interface for Z80 MDM3-8080IO.Z80 -- serial line interface for Intel 8080 This program is basically a re-write in PASCAL of Ward Christensen's Modem Program which was distributed in CP/M User's Group Volume 25. Identical and compatible options are provided to allow this program to work directly with Ward's program running under CP/M. One difference is that when sending files the PASCAL or CP/M transfer mode must be selected. The PASCAL mode transfers files between two systems running PASCAL, while the CP/M mode is used when the receiving system is running CP/M. Basically the CP/M mode provides the linefeeds required to make a PASCAL file compatible with CP/M. When CP/M files are received they contain linefeeds, these can be deleted using the editor to make the file compatible with PASCAL. CP/M files may also contain tabs which the PASCAL editor does not expand. External assembly language routines are used to read the status, and read or write the keyboard and modem ports. These routines are available as separate files for the 8080 and Z80 processors. The port and flag definitions, and the timing constant for the one second delay should be changed as required for your particular hardware. The program has been tested with text files only, and may not work correctly for code or other types of files. The PDP-10 mode transfers PASCAL files to a DEC SYSTEM-10 computer.} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ------------------------------------------------------------ ------------------------------------------------------------ 30-Jan-84 14:36:33-MST,1577;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:36:18-MST Received: From Gunter-Adam.ARPA by BRL-VGR via smtp; 30 Jan 84 12:16 EST Date: 30 Jan 1984 1116-CST Subject: Z-100 graphics.. From: Doug <HUNEYCUTT@gunter-adam> To: Info-CPM@brl-vgr The Z-100 dedicates 3 64K banks to RGB video display RAM. The 6845 CRT controller is highly programmable. You can program the beast to display other than the standard 225 scan lines, but you have to go into interlace mode to do it. Zenith's new catalog has a slow-decay color monitor for use with interlace applications (the standard B&G and RGB monitors flicker noticeably when interlaced mode is used). A point to make is that the Z-100 is always in graphics mode. All displays are software (or firmware) controlled. When programmed with the standard boot-up parameters, each character consists of 9 bytes (one per scan line). You <can> program the controller to use up to 16 scan lines without changing too much, which gives 400 lines/screen (25 text lines). To go higher than 400 lines, you need to take into account the ROM address mapping scheme used by the Z-100 to simplify screen memory accesses. One of the engineers said that, with 64K RAMs installed, you could technically go higher than 800 scan lines per screen. Don't know exactly how you'd do that, but no matter...no screen could handle that density. HUG has some demo software (SARTC, etc) that demonstrates the interlace/high density modes. Doug ------- 30-Jan-84 14:37:01-MST,769;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:36:56-MST Received: From Hi-Multics.ARPA by BRL-VGR via smtp; 27 Jan 84 23:53 EST Date: 27 January 1984 21:49 mst From: Bill Vaughan <VaughanW@hi-multics> Subject: cpmug/sigm file format on simtel20 To: info-cpm@brl-vgr cc: VaughanW@hi-multics Can anyone tell me something about the format of the CPMUG and SIGM files on Simtel20? When I FTP them I get a binary format that I haven't been able to decipher, even those that should be in ASCII such as catalogs and .DOC files. Are they compressed or something? Perhaps someone on a Multics somewhere has already figured out how to FTP these things comprehensibly. Bill Vaughan 30-Jan-84 14:37:15-MST,681;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:37:12-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Jan 84 0:24 EST Received: From Mit-Mc.ARPA by BRL via smtp; 28 Jan 84 0:15 EST Date: Sat 28 Jan 84 00:13:31-EST From: DVW.KJB%MIT-OZ@MIT-MC.ARPA Subject: MDM715/6/7/8/9.... overlay for Apple To: info-cpm@BRL.ARPA I would like to know if there's anyone out there that would be interested in getting the Apple overlay for MDM7xx to work for the DC Hayes Micromodem. I'd hack it to work myself, but I'm relatively new to CP/M and 8080/Z-80 programming. Thanks! - Kevin ------- 30-Jan-84 14:38:29-MST,2034;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:38:21-MST Received: From Amsaa.ARPA by BRL-VGR via smtp; 28 Jan 84 8:43 EST Date: Sat, 28 Jan 84 8:31:22 EST From: David Towson (CSD) <towson@amsaa> To: Bill Vaughan <VaughanW@hi-multics> cc: info-cpm@brl-vgr, VaughanW@hi-multics Subject: Re: cpmug/sigm file format on simtel20 Bill - ALL sigm and cpmug archive files on Simtel20 are stored in ITS binary format, which uses four bytes per 36-bit word (that includes four junk-zeros per word). If you use plain binary mode in FTP, you will get the 36-bit words as-is, which will comeout looking pretty strange on an 8-bit system. To get the files moved correctly in bytes, use TENEX mode if your FTP has it (just type "tenex" at the FTP prompt, and if the program doesn't complain, you're in). Otherwise, try typing "type L8" to notify the sender that the local user (you) wants bytes not 36-bit words. (Can someone tell me whether this is necessary for a TOPS-to-TOPS transfer?) After setting tenex or type L8 mode, then do your gets. Due to the ITS format, you will have four ITS "header bytes" hanging on the front of the file you receive. These can be stripped using a utility on the receiving machine (e.g., DD on UNIX), or you can go ahead and move the files to your CP/M machine and use Keith Petersen's ITSCVT, which can be found in "micro:<cpm.hex>itscvt.hex" on Simtel20. That is an ASCII file. If you are using a UNIX system (which expects lines in ASCII files to be ended with only a line feed) you will find that after you move an ASCII file to the CP/M machine, you may have the CRLF's that were already in the file (and were not changed to LF-only by the receiving FTP because this was a binary transfer) have been changed to CRCRLF. (You may be able to turn this off.) If you do have this problem, the CP/M ED command mf^L^Z-3cd2c will remove the extra CR's. Dave towson@amsaa 30-Jan-84 14:41:43-MST,1016;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:41:39-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Jan 84 11:38 EST Received: From Sri-Unix.ARPA by BRL via smtp; 28 Jan 84 11:32 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 28 Jan 84 6:43-PST Date: 19 Jan 84 19:51:18-PST (Thu) To: info-cpm@brl From: hplabs!hao!seismo!ut-sally!ut-ngp!knutson@ucb-vax Subject: Re: Heath/Zenith Z100 Newsletter Article-I.D.: ut-ngp.243 In-Reply-To: Article <118@5941ux.UUCP> Sorry for sending this to everyone but our mailer has problems. Where did you see that there was an Info-HZ100 Digest? I have searched all over ARPANET for it and can't find it. Also, if you have a copy of the Newsletter or have a net address for David Gubbins, please send them to me. I am extremely interested in any H/Z100 info you have. -- Jim Knutson ARPA: knutson@ut-ngp UUCP: {ihnp4,seismo,kpno,ctvax}!ut-sally!ut-ngp!knutson 30-Jan-84 14:44:43-MST,959;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:44:38-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Jan 84 11:38 EST Received: From Sri-Unix.ARPA by BRL via smtp; 28 Jan 84 11:31 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 28 Jan 84 6:41-PST Date: 19 Jan 84 18:48:41-PST (Thu) To: info-cpm@brl From: hplabs!hao!seismo!ut-sally!ut-ngp!garey@ucb-vax Subject: Zenith 100 Article-I.D.: ut-ngp.242 There is a deal here at Univ. of Texas to get a Zenith 100 with 2 drives, 128K ram etc for $1975.00. This seems like a great deal but I need to know if the S-100 bus in that machine is really standard. For example will standard Compupro boards fit? Could I pop in a hard disk, more memory, and a 68K board (say from compu- pro) in the near future and off I go to Unix land? Or does the thing require special things from Heath/Zenith? ut-ngp) 30-Jan-84 14:45:02-MST,806;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:44:59-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Jan 84 11:38 EST Received: From Sri-Unix.ARPA by BRL via smtp; 28 Jan 84 11:31 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 28 Jan 84 6:40-PST Date: 19 Jan 84 18:41:12-PST (Thu) To: info-cpm@brl From: hplabs!hao!seismo!ut-sally!ut-ngp!garey@ucb-vax Subject: SIMTEL CP/M ARCHIVES Article-I.D.: ut-ngp.241 A few months ago someone posted a message on how to ftp files from SIMTEL CP/M archives. The message was quite long and included examples. I have managed to misplace this message and can't find it locally. Could someone send me a copy? Thanks, Jim Garey (garey@ut-ngp) 30-Jan-84 14:45:14-MST,2235;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:45:08-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Jan 84 12:12 EST Date: Sat, 28 Jan 84 12:04:02 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: Kaypro 10 undocumented features The following is a file relayed from the Sysop Clearinghouse RCPM. --- Jan 5, 1984 UNDOCUMENTED VIDEO FEATURES FOR THE KAYPRO 10 By Ron Mozer The KAYPRO 10 has several undocumented features available to the user which are undocumented in any of the Kaypro manuals. These features include a 25'th line and the ability to save and recall the cursor possition. If you look at the owners manual for the computer you will find a section which describes character attri- butes commands. These commands allow inverse video, blinking, reduced intensity, etc. This is documentation on two more of the commands. The table of commands can be updated to the following: To Turn ON: To Turn OFF: Inverse Video ESC,"B0" ESC,"C0" Reduced Intensity ESC,"B1" ESC,"C1" Blinking ESC,"B2" ESC,"C2" Underlining ESC,"B3" ESC,"C3" Cursor ESC,"B4" ESC,"C4" Save Cursor Pos. ESC,"B6" To Recall ESC,"C6" <--- New 25'th line ESC,"B7" ESC,"C7" <--- New As you can see there is an obvious gap for the "B5" - "C5" attri- butes. I have not found out what these do and would be interested in hearing from anybody that does via the Mesilla Valley RCP/M (505)522-8856. What follows is a sample MBASIC program which demostrates these features: 10 REM THIS PROGRAM WILL DEMONSTRATE THE 25'TH LINE AND OTHER FEATURES 20 REM OF THE KAYPRO 10. 50 REM 110 PRINT CHR$(27);"B6" : REM SAVE CURSOR POSITION 120 PRINT CHR$(27);"B7" : REM ENABLE 25'TH LINE 130 PRINT CHR$(27);"=8 "; : REM MOVE CURSOR TO 25'TH LINE 140 PRINT "THIS IS THE 25'TH LINE" : REM SHOW USER WE CAN DO IT! 150 PRINT CHR$(27);"C6" : REM RECALL CURSOR POSSITION 160 REM WHEN YOUR DONE WITH THE 25'TH LINE IT MAY BE DISABLED 170 REM WITH THE FOLLOWING 180 PRINT CHR$(27);"C7": REM DISABLE 25'TH LINE 30-Jan-84 14:45:39-MST,6933;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:45:20-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Jan 84 12:12 EST Date: Sat, 28 Jan 84 12:05:21 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: MDM720 now available MDM720, the latest version in the MODEM7 series, is now available on SIMTEL20 in the MICRO:<CPM.MODEM7> directory (and temporarily on MIT-MC in the FJW; directory). The file names are: SIMTEL20 MIT-MC MDM720.ASM MDM720 ASM MDM720.COM MDM720 COM (in ITS-binary format on both hosts) MDM720.HEX MDM720 HEX MDM720.MSG MDM720 MSG M7NM-5.ASM M7NM 5ASM (phone number overlay - see note below) NOTE: This program when assembled is 69 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 MDM720 use: SAVE 69 MDM720.COM. NOTE: If using the phone number overlay to change the phone library numbers, be sure to use: M7NM-5.ASM (Previous versions of M7NM will not work with this new version, as the file transfer buffer is now optional length, nominally set for 4k and there is an option to show/not show the both the decimal and HEX record count.) Most users will not need the lengthy (154k) source code. Just get MDM720.COM and then check one of the associated overlay programs to obtain the overlay for your particular computer. Merge that with MDM720.COM according to the instructions near the start of the overlay file, using DDT.COM, etc. (See above note relative to saving 69 sectors. STAT.COM would then show 138 records for 18k.) CHANGES FOR MDM720 ------------------ Changed the printer routine - a number of people had problems with the printer working properly. It now works correctly for several who previously had problems. Increased the stack depth. Now have the ability to select "SHOWHEX" via DDT with a byte two ahead of NUMBLIB. This requires using M7NM-5.ASM if you want to change the telephone number library. 0CFEH - HEXSHOW 00 = do not show hex record count FF = show both hex and decimal count 0CFFH - SAVSIZ 20 = 4k file transfer buffer size 40 = 8k file transfer buffer size 80 = 16k file transfer buffer size 0D00H - NUMBLIB (start of telephone number library) - Irv Hoff CHANGES FOR MDM719 ------------------ Fixed error in GETACK routine which prevented the robust improve- ment (added in MDM716) from working. Changed ACKNAK to NO so default will require valid NAK rather than non-ACK. This is part of the robust improvements, not because of any special ArpaNet requirement. Changed SHOWHEX to true for distribution version so users would have HEX and DECIMAL reporting while transferring files (most users have told me they prefer to see both). Changed PMMI dialing pulse default to 10pps which most exchanges will accept. (This can be set to other pulse rates in the user overlay.) - Keith Petersen, W8SDZ CHANGES FOR MDM718 ------------------ Code added to the auto-dial routine for the new Anchor 300/1200 modem which are selling at discount houses for $270 or so. Computer now beeps continuously anytime a connection is made to attract the operator's attention. Made the file transfer buffer length separate from that of the ASCII capture buffer (which remains 16k, one file-extent). Although the file transfer buffer has been 16k for well over a year, some of the newer floppy disk systems are quite slow and timeout errors could occur. The file transfer buffer size is set by default to 4k (32 records, 20H). It can be set at assembly time if using the entire MDM720.ASM file, or can be set in a few seconds with DDT by changing byte 0CFFH. The number library is now fully automatic to insure it always starts on a new page (such as 0D00H) regardless how much the auto-dial section is altered. Now responds to either "single digit" result codes (some Hayes Smartmodem users leave SW2 set that way) as well as the normal "verbose" result codes. To change the file transfer buffer size via DDT, change byte 0CFFH: 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 (then SAVE 69 MDM.COM, etc.) CHANGES FOR MDM717 ------------------ MDM717 allows characters with parity bit set to be properly handled during propagation overruns after an X-off. This occurs during a "save to disk" after the disk buffer fills. (This problem was noticed on Com- puserve which sends some characters with the parity bit set.) The disk buffer size was restored to 16k. This is the length of "one file extent". Even slow floppy disks can store 16k in a reason- able amount of time. This should remain 16k for distribution copies of the source code although it can be easily changed to suit the individual user's own preference. (It could even be lengthened to 32k if you like fewer disk operations. This would make the printer buffer proportion- ally smaller but most printers are so fast the buffer is rarely filled in any case.) Fixed a stack problem introduced in v716 in the "V" flag routine to allow the user to show ASCII characters on the CRT during a file trans- fer. Fixed the "L" Logon feature so it should be consistent. At times it would run away without waiting for the echo characters, thus not cor- -rectly displaying the Logon message. Restored the ACKNAK feature developed for the exclusive use of the ARPANET networking group. When set normal ("YES") it resends a disk re- cord after any NON-ACK character is received. This has been the normal configuration for all RCPM systems using the XMODEM file transfer pro- gram. When set "NO" for ARPANET use, it resends a record only after a NAK has been received. Other characters are ignored. Some systems will resend a NAK after a 10-second TIMEOUT. This slows things considerably, which allows the main frame time to recover if busy. This tends to run the phone bill higher for RCPM use, but is necessary for ARPANET to pre- vent aborting the file transfer too quickly if the main frame is busy. If a normal TIMEOUT sequence does attempt to abort the transfer with the ACKNAK equate set to NO, it will ask if you want to try again or abort. (RCPM systems would have already timed completely out with 10 consecutive errors, making the question worthless and misleading. ARPANET does not have a similar feature, and the user can manually force the transfer to continue.) - Irv Hoff --end-- 30-Jan-84 14:45:51-MST,1401;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:45:45-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Jan 84 12:13 EST Date: Sat, 28 Jan 84 12:08:51 EST From: Keith Petersen <w8sdz@brl> To: Info-Cpm@brl-vgr Subject: MDM720 and the Racal-Vadic modem Relayed from the Sysop Clearinghouse RCPM. M720RV.ASM is available on SIMTEL20 in the MICRO:<CPM.MODEM7> directory. --- Date: 1/25/84 From: Dave Mabry To: All Re: M720RV.ASM I have just uploaded M720RV.ASM. It is a modification of the file M7RV-1.ASM from M7OVLx.LBR. It is an overlay that supports the Racal-Vadic PA212 "smart" modem similar to the way the Hayes is supported by MDM720. The previous version (M7RV-1.ASM) was set for MDM712 I think and would not work with ANY other version. I have done some significant modifications that should make it easier to use with specific hardware, but it is still VERY specific to the version of MDM7xx it works with. Hence, the MDM7xx full version number in its name (M720RV.ASM). It needs to be overlayed AFTER overlaying the user's normal M7XX-1 file. Read the comments inside for more details, but it Seems to work very nicely with the Vadic PA212 modem. Please remove the original (M7RV-1.ASM) from the overlay library and replace it with this one. Thanks. 30-Jan-84 14:46:48-MST,1490;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:46:42-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Jan 84 12:23 EST Received: From Sri-Unix.ARPA by BRL via smtp; 28 Jan 84 12:17 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 28 Jan 84 9:11-PST Date: 18 Jan 84 18:51:55-PST (Wed) To: info-cpm@brl From: ihnp4!alberta!ubc-vision!uw-beaver!tektronix!tekred!billr@ucb-vax Subject: mdm71x - missing feature/bug Article-I.D.: tekred.23 There exists what I think is an important oversight in the design of the Smartmodem dialing code for MDM712 (and I assume, later versions). That is, if you select Pulse dialing in the configuration file, it will not let you use alternate dialing (i.e. SPRINT, MCI). The other item that goes along with this is that the dialing routine will not let you switch from pulse to tone dialing in mid-stream. What I want to do is this: 555-5555,,,,,T999,777 ^ ^ ^ ^ ^ ^ -------- ---- --- pulse dial tone dial for for switchboard access code and extension As it stands now, I have to use Terminal mode and type the long string in each time. I wish one of the maintainers of MDM7xx would fix this problem and send me a copy (I don't have the source or I'd fix it myself; I discovered this Tracing with DDT - ugh!). -Bill Randle tektronix!tekred!billr UUCP billr.tektronix@rand-relay ARPA 30-Jan-84 14:46:59-MST,599;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:46:55-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 28 Jan 84 12:31 EST Date: 28 January 1984 12:32 EST From: Keith Petersen <W8SDZ@mit-mc> Subject: MDM719.ASM->MDM720.ASM DIF file available To: Info-Cpm@brl-vgr Anyone who already has MDM719.ASM and wants MDM720.ASM can get a DIF file (for use with SSED2 on CP/M) which will create MDM720.ASM. The file is available on SIMTEL20 as MICRO:<CPM.MODEM7>M719720.DIF and temporarily on MIT-MC as FJW;719720 DIF --Keith 30-Jan-84 14:47:19-MST,1609;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:47:12-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Jan 84 12:55 EST Received: From Sri-Unix.ARPA by BRL via smtp; 28 Jan 84 12:49 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 28 Jan 84 9:40-PST Date: 27 Jan 84 0:37:48-PST (Fri) To: info-cpm@brl From: hplabs!hao!seismo!uwvax!heurikon!jeff@ucb-vax Subject: Re: DRI C Compiler Woes Article-I.D.: heurikon.185 In-Reply-To: Article <15918@sri-arpa.UUCP> Your report was on CP/M-86 'C' compiler bugs and DRI's failure to fix them in the second release. I don't think DRI concentrates too much on their compilers. We were a beta test site for CP/M-68K. The O/S worked fine, but wow(!) were there ever a lot of 'C' compiler bugs. They've acknowledged all of them and pointed out that they are relying on their supplier to fix them, since they didn't write the thing. (I'll tell you who did if you ask, but not on the net.) There's only been one release of CP/M-68K so far, and I'm waiting to see if the bugs are fixed in the next release. But, frankly, I won't be too surprised it they aren't. Fortunately, all of the bugs have work-arounds. But I'm slightly bald now from pulling hair, and I've gotten very good at reading the cryptic *.s files produced by the compiler to find out what the 68K is *really* doing. -- /"""\ Jeffrey Mattox, Heurikon Corp, Madison, WI |O.O| {harpo, hao, philabs}!seismo!uwvax!heurikon!jeff (news & mail) \_=_/ ihnp4!heurikon!jeff (mail) 30-Jan-84 14:48:15-MST,1585;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 14:48:10-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Jan 84 15:14 EST Received: From Gunter-Adam.ARPA by BRL via smtp; 28 Jan 84 15:12 EST Date: 28 Jan 1984 1412-CST Subject: Z-100/IEEE-696 (S-100) From: Doug <HUNEYCUTT@gunter-adam> To: Info-CPM@brl cc: Huneycutt@gunter-adam The S-100 bus in the Z-100 is indeed IEEE-696 engineered. The system supports 5 slots, one of which is taken by the floppy disk controller, another by the Winchester controller (if you have one). You can plop any IEEE-696 card into the machine, with one noteable exception....(sigh) You see, even the motherboard of the Z-100 is broken into logical parts. The memory circuitry is a 'logical' S-100 card, the video circuitry another, and so on. Accordig to the designer, you could DMA video pictures into the display memory if you have a DMA device driver (which the floppy controller is NOT) PROBLE: The CPU circuitry is configured as an IEEE-696 PERMANENT MASTER!! This precludes the addition of a standard S-100 CPU card, as it will also want to be a permanent master. The Zenith folks are thinking about it. (Note: for those of you with a Z-100 already, look at the back. There is a very long cut-out at the top (about the length of a standard S-100 card). Yup, they actually thought about extending the S-100 outside the main box. Just think what your RFI sources could do with that!!) Doug ------- 30-Jan-84 20:24:23-MST,918;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 20:24:19-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 30 Jan 84 21:48 EST Date: 30 Jan 1984 19:49 MST (Mon) Message-ID: <WANCHO.11987875908.BABYL@SIMTEL20> From: "Frank J. Wancho" <WANCHO@simtel20> To: INFO-CPM@brl-vgr cc: INFO-MICRO@brl-vgr Subject: TRS-80 II Parallel Printer Routines Wanted! After trying all available versions of various modem programs, such as MDM720, which claims to have printer buffering fixed, I've come to the depressing conclusion that our ancient Lifeboat BIOS' LISTAT is broken - i.e., returns always ready, and thus overruns. So, I'm asking if anybody can spare a working LISTAT and LSTOUT routine to let me drive the parallel printer directly, and I'll wedge it into one of these programs. CP/M or anyDOS routines welcome! Thanks, Frank 30-Jan-84 20:36:36-MST,648;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 20:36:28-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 30 Jan 84 21:53 EST Date: 30 Jan 1984 17:41 MST (Mon) Message-ID: <WANCHO.11987852742.BABYL@SIMTEL20> From: "Frank J. Wancho" <WANCHO@simtel20> To: INFO-CPM@brl-vgr Subject: RBBS4 (in BDS-C!) Available A version of RBBS, written in BDS-C, is now available in [SIMTEL20]MICRO:<CPM.RBBS4>. Note that it requires BDS-C 1.50a due to the use of the index function. It has not been tested with any prior version. Bug reports, etc., directly to me. --Frank 30-Jan-84 21:14:14-MST,932;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 30 Jan 84 21:14:01-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Jan 84 22:55 EST Received: From Rochester.ARPA by BRL via smtp; 30 Jan 84 22:53 EST Received: by sen.rochester (3.327.3N) id AA06410; 30 Jan 84 22:53:08 EST (Mon) Received: by cay.Rochester (3.327.3N+) id AA01196; 30 Jan 84 22:49:49 EST (Mon) Message-Id: <8401310353.6410@sen.rochester> Date: 30 Jan 84 22:53:08 EST (Mon) From: Mike Ciaraldi <ciaraldi@Rochester.ARPA> Subject: Re: DRI C Compiler Woes To: hplabs!hao!seismo!uwvax!heurikon!jeff@ucb-vax.ARPA, info-cpm@brl.ARPA Thanks for the info. Did outsiders do the C compiler for both CP/M-68K and 86, or do you only know for sure on the 68K? So, who did it? You can send to me privatley as "ciaraldi@rochester", or I can give you US mail or phone if you want. Mike Ciaraldi 31-Jan-84 08:10:05-MST,779;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 31 Jan 84 08:09:58-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Jan 84 23:47 EST Received: From Rochester.ARPA by BRL via smtp; 30 Jan 84 23:39 EST Received: by sen.rochester (3.327.3N) id AA06805; 30 Jan 84 23:39:04 EST (Mon) Received: by cay.Rochester (3.327.3N+) id AA01296; 30 Jan 84 23:35:46 EST (Mon) Message-Id: <8401310439.6805@sen.rochester> Date: 30 Jan 84 23:39:04 EST (Mon) From: Mike Ciaraldi <ciaraldi@Rochester.ARPA> Subject: Re: DRI C Compiler Woes To: Mike Ciaraldi <ciaraldi@Rochester.ARPA>, hplabs!hao!seismo!uwvax!heurikon!jeff@ucb-vax.ARPA, info-cpm@brl.ARPA Whoops! Preceding message was supposed to have been private. 31-Jan-84 08:10:51-MST,1781;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 31 Jan 84 08:10:22-MST Received: From Sri-Nic.ARPA by BRL-VGR via smtp; 31 Jan 84 3:09 EST Received: from USC-ECLB by SRI-NIC with TCP; Tue 31 Jan 84 00:09:15-PST Date: 30 January 1984 23:24-PST (Monday) Sender: TLI@usc-eclb From: Tony Li <Tli@usc-eclb> To: Info-Cpm@brl-vgr Subject: DRI 'C'. Reply-to: Tli@usc-eclb Home: 1275 W. 29th #211, Los Angeles, Ca. 90007 (213) 737-8168 Hi, The 8086 version of the DRI 'C' compiler was done by Mike Lehman (of Pascal-MT+) fame. It is supposedly a fairly complete implementation. I am very much not impressed with the code that it generates, however. I have also had problems with this compiler under CCP/M. If you switch consoles while it's running, use some memory, and then it goes to allocate some memory that isn't available, it turns off interrupts and goes away. This of course, may be a feature of the version of CCP/M that I was using. Also, I was using the Engr. Dept. release of 6-July-1983. I don't know what that corresponds to in a retail version, but I do know that it was significantly improved (!!!) over the version that was available at the time of the product's announcement. The CP/M-68K compiler was done by an outside company. It does have a few bugs. My favorite was the lack of flagging of an error when you set up a data structure that doesn't sit on a longword boundary. Got bit by that several times. All in all, I would say that it is a fairly good compiler. The code generation is not bad, and the error messages are reasonable. Having the four phases patched together by an external SUBMIT file, though, is something of a drag. Sigh. Cheers, Tony ;-) 31-Jan-84 08:11:03-MST,603;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 31 Jan 84 08:10:58-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 31 Jan 84 3:13 EST Received: From Mit-Multics.ARPA by BRL via smtp; 31 Jan 84 3:05 EST Date: Tue, 31 Jan 84 03:03 EST From: Schauble@MIT-MULTICS.ARPA Subject: Function 37 - drive door open To: info-cpm@BRL.ARPA Message-ID: <840131080333.111355@MIT-MULTICS.ARPA> Program lockable doors on 8 inch drives are not that uncommon. My Qume DT8's have them. Unfortunately, my disk controller doesn't know about it. 31-Jan-84 08:12:46-MST,1658;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 31 Jan 84 08:12:14-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 31 Jan 84 4:35 EST Received: From Mit-Mc.ARPA by BRL via smtp; 31 Jan 84 4:23 EST Date: 31 January 1984 04:24 EST From: Jerry E. Pournelle <POURNE@mit-mc> Subject: help needed To: INFO-CPM@mit-mc, INFO-MICRO@mit-mc Back before the big ARPA split, I could download files to my system with MITE, which sends XMODEM protocol (and could also do PLINK and I guess a couple of others). Now I get nothing, and it is a comprehensive drag since I have to reset the machine to break the losing send, then find a free TIP, then log back on to kill that failed job. Sigh. If there is anything a science fiction writer/columnist could do in return, I would like a favor from o someone: from time to time could download some of my files to 8" disk (SSSD IBM format to be sure we don't get problems) and send by US Snail. I will gladly pay for the service, and perhaps an autographed book or two would be useful as thanks? I do not really understand TIPS and su ch, and MITE tells you NOTHING other than "T" for "timed out" or "R" for retry; MModem gets the R's in quantity , Lmodem (which also used to work for me) gets 2 r's and a string of T's. Neither seems a very useful message. Maybe my enthusiasm for MITe (because when it's working it is really easy to use) is misplaced. Anyway, I could use help, if theres anyone with time and capability of downloading files. This is insanity; there has to be a way to do this, but I don't know it. JEP 31-Jan-84 08:13:51-MST,1430;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 31 Jan 84 08:13:32-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 31 Jan 84 8:32 EST Received: From Sri-Unix.ARPA by BRL via smtp; 31 Jan 84 8:11 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 31 Jan 84 5:10-PST Date: 30 Jan 84 6:40:32-PST (Mon) To: info-cpm@brl From: ihnp4!ihuxq!covert@ucb-vax Subject: Needed:8088 x-assembler for cpm-80 Article-I.D.: ihuxq.562 I need a cross assembler for the Intel 8088 CPU which runs under cpm-80. I have a small 8088 controller board which I bought at a Hamfest. I would like to be able to write some small 8088 assembly language programs for it. I have a z-80 based cpm system with an eprom programmer. If I could get a cross assembler that would generate Intel HEX files then I could burn my own proms. Can anyone out help me locate such at tool (BTW I need something in the public domain or else inexpensive). Also, has anyone ever heard of a version of basic called TBASIC written for the 8088?? I got an 8755 with TBASIC burned into it with the controller. Also, any ideas about a good assembly language programming book for the 8088?? Please mail your repsonses to me unless they are of interest to the net. -- Richard Covert BTL Indian Hills West, Room 1E-408 ...ihnp4!ihuxq!covert (312) 979-7488 31-Jan-84 08:14:16-MST,1094;000000000000 Return-Path: <info-cpm-request@BRL-VGR.ARPA> Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 31 Jan 84 08:14:10-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 31 Jan 84 8:59 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 31 Jan 84 8:46 EST Date: Tue, 31 Jan 84 08:44 EST From: Westfall.Henr@PARC-MAXC.ARPA Subject: Re: Heath/Zenith Z100 Newsletter In-reply-to: <[USC-ISID]28-Jan-84 22:52:11.ABN.ISCAMS> To: ABN.ISCAMS@usc-isid.ARPA cc: hplabs!hao!seismo!ut-sally!ut-ngp!knutson@ucb-vax.ARPA, info-cpm@brl.ARPA I believe that the person that mentioned the info-hz100 digest was Dave Gubbins (Gubbins@Radc-Tops20). Last time I checked, he was working for Rome Air Development Center at Griffis AFB in Rome, NY. The school that both he and I graduated was Clarkson College, who recently required all incoming freshmen to purchase Z100 computers. I believe that they currently have about 1600 machines on campus, and a computer networking is being implemented to interconnect the whole lot of them. Rob Westfall Xerox Corp Westfall.Henr@Parc-maxc