3-Jan-84 16:18:08-MST,1024;000000000000 Return-Path: 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 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: 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 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: 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 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: 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 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: 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 Return-Path: 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: 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 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: 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 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 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: 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 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: 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 To: Keith Petersen 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: 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: 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: 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 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: 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 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: 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: 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 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: 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 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: 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: 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: 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: 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: 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 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: 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: 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 To: Info-Cpm@brl-vgr Subject: ERAQ15.ASM now available ERAQ15.ASM is now available on SIMTEL20 in the MICRO: 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: 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 To: Info-Cpm@brl-vgr Subject: BYE3-16.ASM now available BYE3-16.ASM is now available on SIMTEL20 in the MICRO: 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: 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 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 To: Richard Kawala 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: 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? 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)" To: Mike Simpson 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. 6-Jan-84 09:01:34-MST,2257;000000000000 Return-Path: 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: 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: 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. 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, 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 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: 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 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: 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 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: 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) 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 tac-user-guide. You might also like to get a directory listing for the 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: 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) 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: 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) 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: 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) 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 "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) 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 tac-user-guide. You might also like to get a directory listing for the 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: 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 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: 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 To: Eric Stork 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: 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 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 10-Jan-84 12:48:39-MST,1060;000000000000 Return-Path: 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 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: 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 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 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 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: 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 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: 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 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: 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: 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: 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 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: 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: 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: 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) 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: 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 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: 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: 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 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: 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 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 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: 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 To: Info-Cpm@brl-vgr Subject: SD-79 now available SD version 7.9 is now available in SIMTEL20's MICRO: 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: 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: 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: 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) 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: 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 To: Charlie Strom (NYU) 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: 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: 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 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: 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 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: 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 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: 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 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: 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 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: 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 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: 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 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: 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 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: 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: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 directory. David Kirschbaum Toad Hall (ABN.ISCAMS@USC-ISID) 16-Jan-84 09:41:54-MST,2750;000000000000 Return-Path: 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 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: 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 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: 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: From: "Frank J. Wancho" 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:) CPMUG #001 - 054 (MICRO:) #078 - 090 Enjoy! --Frank 16-Jan-84 09:44:00-MST,487;000000000000 Return-Path: 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: 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: 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 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: 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: 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" 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: 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)" To: Mike Simpson , Pete Criqui 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. 16-Jan-84 09:51:48-MST,1012;000000000000 Return-Path: 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: 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 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: 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 To: Richard G. Turner 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: 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: 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 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: 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: 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 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: 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 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 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: 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 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: 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 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 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: 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 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: 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: 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: 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: 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 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: 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 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: 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: 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 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: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 16 Jan 84 10:10:29-MST Received: From Sri-Nic.