1-Nov-83 08:57:30-MST,862;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 1 Nov 83 08:57:26-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 31 Oct 83 23:27 EST Received: From Mit-Mc.ARPA by BRL via smtp; 31 Oct 83 23:22 EST Date: Mon 31 Oct 83 20:22:50-EST From: Edward Huang Subject: 16-bit MODEM program To: info-cpm@BRL.ARPA cc: rms.g.eh%MIT-OZ@MIT-MC.ARPA DOes any one know of a XMODEM/MODEM7 compatible program for 16-bit machines? At Univ. of Santa Clara, we have the Artelonics 750 and 1000's and I would like to find out how we can put a XMODEM/MODEM program on it. (my computers and the SCU 2060 can handle XMODEM/MODEM) **** Please REPLY to me DIRECTLY as I am not on the list Thank you, Edward Huang EH@MC, RMS.G.EH@MIT-OZ, E.HUANG@SCU (not arpa) ------- 1-Nov-83 08:57:47-MST,1503;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 1 Nov 83 08:57:41-MST Date: Tue, 1 Nov 83 1:11:29 EST From: R. Bruce Natalie (CTAB) To: info-micro@brl-vgr, info-cpm@brl-vgr Subject: [lauren: status report message] Lauren Weinstein has sent me the following message regarding the MARC software package. For those of you who don't know, MARC is an attempt to get as much of UNIX as you can on a 8080 based system. This message was forwarded to me as list maintainer because he was uncertain whether it would be viewed as a commercial statement and thus be a prohibitted use of the DDN. I find this note to be of the informational type, which is one of the primary purposes of this list and therefore am forwarding it on his behalf. Mr Weinstein's mailing address is: Ron Natalie INFO-MICRO-REQUEST@BRL-VGR INFO-CPM-REQUEST@BRL-VGR --------- A very brief status report on MARC: Due to various technical problems, the rapidly advancing state of the art in software and affordable hardware, and a variety of marketing considerations, the MARC software project has been terminated. No further work is taking place on the software, and the MARC software package will henceforth not be sold or distributed in any manner. Persons with specific questions on this topic may feel free to contact me, but the decision is irrevocable. Thanks much. --Lauren-- 1-Nov-83 12:06:42-MST,640;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 1 Nov 83 12:06:38-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 1 Nov 83 13:36 EST Received: From Usc-Eclb.ARPA by BRL via smtp; 1 Nov 83 13:21 EST Date: 1 Nov 1983 1020-PST From: Dick Subject: QUASI-DISK info wanted To: info-micro@brl, info-cpm@brl I have been seeing quite a few adds (Microsystems V4,N11,p111) for an S100 ram disk from Canada, by Electralogics. The 512k basic unit is advertised for $799.00.. Does anyone on have any further info/experience with this company/device? ------- 1-Nov-83 12:52:27-MST,617;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 1 Nov 83 12:52:20-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 1 Nov 83 14:05 EST Received: From Rutgers.ARPA by BRL via smtp; 1 Nov 83 14:01 EST Date: 1 Nov 83 13:59:25 EST From: Seymour Subject: Modem7 on the rainbow To: info-cpm@BRL.ARPA Can anyone out there in netland tell me if the standard DEC Rainbow comes with an RS232 serial port? If so, does anyone have the MODEM7 program or something compatible running on a Rainbow? Thanks Seymour ------- 2-Nov-83 08:33:12-MST,954;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 2 Nov 83 08:32:57-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 1 Nov 83 21:14 EST Date: 1 Nov 1983 19:12 MST (Tue) Message-ID: <[SIMTEL20].KPETERSEN. 1-Nov-83 19:12:08> Sender: KPETERSEN@simtel20 From: Keith Petersen To: David Towson (CSD) Cc: Info-Cpm@brl-vgr Subject: Source for MDM712.ASM In-reply-to: Msg of 31 Oct 1983 14:38-MST from David Towson (CSD) The source for MDM712 is now available on SIMTEL20 in both squeezed (binary) and normal ASCII format: MICRO:MDM712.AQM (the squeezed file) MICRO:MDM712.ASM (the unsqueezed file) A reminder to all: you don't normally need the source (very large file) to bring up MDM712. All you need is MDM712.COM and the appropriate user overlay for customizing it to your system. --Keith 2-Nov-83 08:33:43-MST,1156;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 2 Nov 83 08:33:35-MST Received: From Mit-Multics.ARPA by BRL-VGR via smtp; 1 Nov 83 23:52 EST Date: 1 November 1983 2224-est From: Paul Schauble Subject: C Compiler for 6809 To: Human-Nets@rutgers, Info-Micro@brl-vgr, Info-CPM@brl-vgr I am looking for information to assist in selecting a microprocessor for a new application. The application is almost entirely character manipulation, with absolutely no requirement for floating point arithmetic or any number crunching. The chief criterion will be the space occupied by generated code. 1. Does anyone have any information, good or bad, on C compilers for the 6809? Comments on the quality of generated code are particularly wanted. 2. Does anyone have any information on relative code sizes generated by a HLL compiler for any of the 6809, 68000, z80, and 8086. Information comparing the relative sizes on two or more of these processors is especially wanted. As usual, I will post a summary to the list if I receive any useful replies. 2-Nov-83 08:33:51-MST,742;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 2 Nov 83 08:33:47-MST Received: From Hi-Multics.ARPA by BRL-VGR via smtp; 2 Nov 83 0:31 EST Date: 1 November 1983 23:29 cst From: Eaton.HFED@hi-multics Subject: newcomer To: info-cpm@brl-vgr I am new to the net and am therefore not quite sure where this message is going or how it is going to get there. I would like whomever is resposible for forwarding this if it is indeed being forwarded, to ack this so that I can get on to saying what I would really like to say. Pardon me all but this is only a test. Meaningful stuff to come later...... This is really scary stuff..... Thanx.... Eaton.HFED at hi-multics 2-Nov-83 08:34:20-MST,2991;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 2 Nov 83 08:34:08-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 2 Nov 83 2:34 EST Date: 2 November 1983 02:35 EDT From: Keith Petersen Subject: Fixing MAC for lower case To: Info-Cpm@brl-vgr The following is forwarded from my RCPM: --- TOPIC : HOW TO MODIFY MAC.COM TO NOT CHANGE LOWER-CASE TO UPPER-CASE FROM : IRVIN M. HOFF DATE : 22 OCT 82 MAC.COM (by Digital Research) is one of the most popular assemblers used with CP/M. It has one feature that most people do not like -- when making a print file (FILENAME.PRN) it automatically converts any lower- case characters to upper-case. Neither ASM.COM nor RMAC.COM by the same firm does that. There are two ways to modify MAC.COM to approach this problem. Changing address 165C from C8 to D0 will convert any lower-case source code to upper, leaving DB strings and comments alone. (1st example below). Changing 1663 from E6 to 5F will leave all the lower case comments alone, will convert all DB strings to upper case, but will toss out any lower case code that does not agree with labels that are also lower case. (second example.) 1st example: leaves all comments and DB strings alone =================================================== 1655 47 MOV B,A 1656 3A 05 30 LDA 3005 1659 FE 03 CPI 03 165B 78 MOV A,B 165C C8 RZ Change the RZ (C8) to a RNC (D0) Using DDT or SID: 165C C8 D0 A>SAVE 46 MAC.COM This will convert any source code not in a string from lower to upper, and not bother any comment areas or DB strings. It's as close as you can get easily, to leaving all lower case alone. 2nd example: leaves all comments alone, but throws out lower case source code including strings that do not match. =================================================== 1663 E6 5F (ANI 5FH) Using DDT or SID, change to: 1663 E6 7F (ANI 7FH) A>SAVE 46 MAC.COM (new, normal version) This prevents the lower-case from being changed to upper-case. For a complete disassembly of that area: 1655 47 MOV B,A ;Put the char. into 'B' temporarily 1656 3A 05 30 LDA ABORT ;See any request to quit 1659 FE 03 CPI 03 165B 78 MOV A,B ;Get the char. back again 165C C8 RZ ;Exit with the char. if a 03 165D FE 61 CPI 61H ;Less than lower-case alpha char.? 165F D8 RC ;If less, ignore 1660 FE 7B CPI 7AH+1 ;More than lower-case alpha char.? 1662 D0 RNC ;If more, ignore 1663 E6 5F ANI 5FH ;Otherwise change to upper-case 1665 C9 RET ;Finished --end-- 2-Nov-83 09:19:01-MST,484;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 2 Nov 83 09:18:56-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Nov 83 10:52 EST Received: From Usc-Isib.ARPA by BRL via smtp; 2 Nov 83 10:46 EST Date: 2 Nov 1983 0742-PST Subject: CPM Files From: MCCRARY@usc-isib To: Info-cpm@brl cc: McCrary@usc-isib Where are the files containing CPM public domain programs? Are they still at MIT? Frank ------- 2-Nov-83 10:13:30-MST,1056;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 2 Nov 83 10:13:26-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Nov 83 11:43 EST Received: From Simtel20.ARPA by BRL via smtp; 2 Nov 83 11:38 EST Date: 2 Nov 1983 09:35 MST (Wed) Message-ID: <[SIMTEL20].WANCHO. 2-Nov-83 09:35:11> From: Frank J. Wancho To: INFO-CPM@brl Subject: Slash "/" in SIMTEL20 filenames The slash (or slant) character in TOPS-20 is a special character. It and others that may appear in the filenames stored in MICRO: must be quoted with ^V. To FTP such files, like MICRO:SIG/M.CAT, simply precede the slash with ^V (a real CTL-V). If your OS or FTP program can't handle certain characters, try surrounding the entire filename in double-quotes. Note: the requirement for quoting the slash character is why the directory name is "SIGM" rather than "SIG/M". However, the slashes in the individual filenames have been retained to maintain some order. --Frank 2-Nov-83 13:02:03-MST,1394;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 2 Nov 83 13:01:56-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 2 Nov 83 14:25 EST Date: 2 Nov 1983 12:22 MST (Wed) Message-ID: <[SIMTEL20].KPETERSEN. 2-Nov-83 12:22:05> Sender: KPETERSEN@simtel20 From: Keith Petersen To: JOEL ROBERTSON/EE/ROBINS TAC Cc: Info-Cpm@brl-vgr Subject: MDM712 and other Hoff updates In-reply-to: Msg of 1 Nov 1983 20:32-MST from JOEL ROBERTSON/EE/ROBINS TAC Sorry, MDM712 doesn't support the MM100. Don't spend any time trying to change it since Irv Hoff removed nearly all the comments from the source code, thus making it impossible for anyone other than him to update the program. He has done this to several other public-domain programs (such as NCAT) and the RCPM Sysops are starting to talk about not supporting any of the programs he has done this to. We've had numerous complaints about the stripping of comments and updates for cosmetic reasons or the removal of features he "doesn't like". Irv has become very popular with end-users who don't have any interest in modifying or improving programs, but he is incurring the wrath of public-domain programmers and RCPM Sysops. There is a serious confrontation brewing over this. --Keith 2-Nov-83 14:01:24-MST,618;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 2 Nov 83 14:01:20-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Nov 83 15:25 EST Received: From Hi-Multics.ARPA by BRL via smtp; 2 Nov 83 15:15 EST Date: 2 November 1983 14:12 cst From: Ronald W. Subject: Re: Newcomer To: info-cpm@brl cc: Eaton.HFED@hi-multics Please do not clutter the net with responses to Eaton.HFED at HI-Multics on where his message went or with flames about it. I will educate him/her locally for you all. Sorry. Ron . 3-Nov-83 08:20:08-MST,891;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 3 Nov 83 08:20:03-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 2 Nov 83 21:28 EST Received: From Mit-Ml.ARPA by BRL via smtp; 2 Nov 83 21:19 EST Date: 2 November 1983 21:21 EDT From: Andrew Scott Beals Subject: BASCOM patch To: pourne@mit-mc, w8sdz@brl, info-cpm@brl . . . if anyone remembers, long, long ago, someone broadcasted a patch to the Osborne version of BASCOM that fixed the "security" bug. The fix should be fairly trivial, as the patch that you needed to make in the Osborne version was within the first 1/4k of the code (after, of course, it jumped up around the data area, as microsoft's linker likes to arrange things). You should have to spend only 15 minutes looking at the file with ddt. Yours for insecurity, Andy (-: 3-Nov-83 09:33:51-MST,593;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 3 Nov 83 09:33:42-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 3 Nov 83 11:04 EST Received: From Cmu-Cs-G.ARPA by BRL via smtp; 3 Nov 83 10:54 EST Date: Thursday, 3 November 1983 10:54:15 EST From: James.Wendorf@cmu-cs-g To: Info-CPM@brl Subject: Batch file uploading query Does there exist a terminal program (such as MDM712) which runs on a Heathkit H89 and is able to upload a batch of files to a VAX/UNIX system? The UMODEM program does not provide batch mode. 3-Nov-83 10:40:00-MST,934;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 3 Nov 83 10:39:54-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 3 Nov 83 12:15 EST Date: 3 Nov 1983 10:12 MST (Thu) Message-ID: <[SIMTEL20].KPETERSEN. 3-Nov-83 10:12:01> Sender: KPETERSEN@simtel20 From: Keith Petersen To: Herb Lin Cc: Info-Cpm@brl-vgr Subject: Finding commented source for MDM7xx In-reply-to: Msg of 2 Nov 1983 14:09-MST from Herb Lin I don't know what the last version of MDM7xx was that had comments in it. No, the old versions are not on line anywhere. Irv has made a mess of things by releasing non-commented versions of source. I'm going to try to track down an older version that has comments in it. If you'd like to call Irv to ask him to release a commented version (he won't talk to me about it) call (415) 948-2166. --Keith 3-Nov-83 11:06:55-MST,1525;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 3 Nov 83 11:06:49-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 3 Nov 83 12:35 EST Date: 3 Nov 1983 10:33 MST (Thu) Message-ID: <[SIMTEL20].KPETERSEN. 3-Nov-83 10:33:18> Sender: KPETERSEN@simtel20 From: Keith Petersen To: Charles Garthwaite Cc: Info-Cpm@brl-vgr Subject: MDM712 printer and terminal problems In-reply-to: Msg of 26 Oct 1983 16:38-MDT from Charles Garthwaite The ^P in the terminal mode SHOULD work correctly IF you have LISTSTAT implemented correctly in your CBIOS. This is the new CP/M 2.2 vector in the CBIOS jump table that tests to see if the printer is ready. MDM712 relies on this routine to prevent loss of characters. MDM712 should issue an X-OFF (^S) to the mainframe when the 16k printer buffer is full and then it should gather up to 128 ADDITIONAL characters in an auxilary overflow buffer while waiting for the mainframe to honor the X-OFF request. This feature has been in MDM7xx for a number of versions and there have been no problems reported. Your problem with the terminal mode not allowing use with screen-oriented text editors is caused by an option in the user overlay not being set correctly. The distributed overlays all have a "filter control characters while in terminal mode" option TURNED ON. You must re-assemble your overlay with a NO there instead of a YES. --Keith 3-Nov-83 16:22:16-MST,1064;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 3 Nov 83 16:22:12-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 3 Nov 83 16:43 EST Received: From Nosc-Cc.ARPA by BRL via smtp; 3 Nov 83 16:30 EST Date: 3 Nov 1983 13:24:09-PST From: Bob Van Cleef Reply-to: CCVAX.revc@nosc To: info-cpm@brl Subject: PRN: and PIP ------- I've seen at least a half dozen systems were the PRN: function of PIP does not work. These include an Osborne-I, Discovery, and various S-100 systems. I would like to know where PRN: is defined. All the references that I have seen infer that it is PIP that recognizes it and changes its options before sending the output to LST:. If that is the case, than it should not be hardware dependant. - Bob Bob Van Cleef Naval Ocean Systems Center UUCP sdcsvax!noscvax!revc Computer Sciences Corp ARPA revc@nosc NOSC - Bldg. 1 CompuServe 71565,533 4045 Hancock Street analog (619) 442-7967 San Diego, CA 92110 ------- 3-Nov-83 18:42:16-MST,1213;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 3 Nov 83 18:42:12-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 3 Nov 83 20:20 EST Date: Thu, 3 Nov 83 20:10:46 EST From: Rick Conn To: info-cpm@brl cc: info-unix@brl Subject: UNIX S/W Repositories on SIMTEL20 SIMTEL20 now contains a directory. The programs related to file transfers between UNIX and CP/M are located in MICRO:, the MENU programs are in MICRO:, and general utilities like CLMAN and DIR are in MICRO:. There are now new versions of CLMAN, UC, DIR, and MENU in these directories. Posting will probably be make to net.sources on USENET. The new version of CLMAN corrects the problem with user-specified underscores in a line. The new version of DIR is a minor cleanup of the code. The new version of MENU is a reflection of changes made on USENET. The new version of UC adds a debug mode, in which packet contents are dumped in a manner similar to the DDT D command, and incorporates a bug fix. Posting of the new files will probably be made to net.sources on USENET. Rick 3-Nov-83 19:09:02-MST,736;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 3 Nov 83 19:08:59-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 3 Nov 83 20:31 EST Date: Thu, 3 Nov 83 20:23:09 EST From: Rick Conn To: info-cpm@brl cc: info-unix@brl Subject: More on UNIX Stuff The dir also contains UCBOOT.C now. This is a short program (relatively) which can be buffer dumped or typed into a UNIX system, and it can be used to receive the full body of UC.C (ala MBOOT3.ASM). All of the new programs are running under UNIX SYSTEM V, which is what I've switched over to. They have also been compiled and executed under BRL's JHU UNIX. Rick 4-Nov-83 08:31:39-MST,3093;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 4 Nov 83 08:31:25-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 3 Nov 83 22:57 EST Received: From Mit-Mc.ARPA by BRL via smtp; 3 Nov 83 22:49 EST Date: 3 November 1983 22:49 EST From: Allan D. Plehn Subject: BASIC Program to generate "by-area code" files from PAMS list. To: W8SDZ@mit-mc cc: INFO-CPM@mit-mc I've modified the program that you and Jim Petersen wrote, so that it is easier to use-no editing required. Here is the modified program (original line numbering preserved): 10 REM PAMSAREA.BAS ver. 1.0, 9/8/83 11 'Modified by Al Plehn 3 Nov 1983. "INPUT" statements added so 12 'that the program can be used without need to edit it for each 13 'new area code. 20 REM by James Petersen, WD8CLE and Keith Petersen, W8SDZ 30 REM This program is for use with OTHERSYS (Bill Blue's PAMS list) 40 REM to make an output file which contains the phone numbers of 50 REM only a single area code. It was used to make AREA-313.BBS 60 REM on this system. Written for Microsoft Basic-80 ver. 5.x 65 INPUT "What is the name of the input file?", INFILE$ 66 INPUT "For what Area Code?",AREACODE$ 70 OPEN "I",1,INFILE$ 80 OPEN "O",2,"AREA-"+AREACODE$+".BBS" 90 PRINT #2," Extracted from Bill Blue's latest PAMS list" 100 PRINT #2,"" 110 WHILE NOT EOF(1) 120 LINE INPUT #1,A$ 130 L=INSTR(1,A$,"("+AREACODE$+")") 140 IF L<>0 THEN PRINT #2,A$ 150 WEND 160 PRINT #2,"" 170 PRINT #2," * denotes 24-hour operation" 180 PRINT #2," + denotes 8-12 hour DAYTIME operation ONLY" 190 PRINT #2," - denotes 8-12 hour NIGHTTIME operation ONLY" 200 PRINT #2," ! new system or new number to existing system" 210 PRINT #2," $ Supports VADIC 1200 baud operation" 220 PRINT #2," & Supports 212A 1200 baud operation" 230 PRINT #2," % Supports BAUDOT operation" 240 PRINT #2," #1 denotes original system of that type" 250 PRINT #2," dd. denotes game oriented messages" 260 PRINT #2," dl. download/program exchange system" 270 PRINT #2," ml. mail/information exchange only" 280 PRINT #2," rb. denotes call, let ring once and call back" 290 PRINT #2," rl. religious orientation" 300 CLOSE 310 INPUT "Do you want an output file for another area code?",REPLY$ 320 IF LEFT$(REPLY$,1)="Y" OR LEFT$(REPLY$,1)="y" THEN 66 325 PRINT:PRINT:FILES:PRINT:SYSTEM If one does not wish to fool around with MBASIC, and you need just a printed list by area code, try this instead: FP (703) BYNAME.PAM ...to get a list for area code 703, for example, from the PAMS list called BYNAME.PAM (Bill Blue's OTHERSYS) FP, of course, is that wonderful utility called findpattern but named simply FP.COM. I find it very useful for scanning disk files for patterns (it prints the whole line on which the pattern is found). It even accepts wildcard filespecs so you can search all the files on a disk with one command. Al Plehn 7-Nov-83 08:36:52-MST,891;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 7 Nov 83 08:36:45-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 5 Nov 83 1:19 EST Received: From Mit-Mc.ARPA by BRL via smtp; 5 Nov 83 1:16 EST Date: 4 November 1983 23:52 EST From: Jerry E. Pournelle Subject: PRN: and PIP To: CCVAX.revc@nosc-cc cc: info-cpm@brl In-reply-to: Msg of 3 Nov 1983 13:24:09-PST from Bob Van Cleef PRN: should be connected to an honest-to-Phred device. I too have noticed that many machines have an "easy" BIOS. I even have heard the excuse that "we didn't implement those extra devices because it saves memory" (!!!) Other machines with "Easy" BIOSes includ the entire TeleVideo line. I'm mystified by this approach, with so many model BIOSes around. --Alex Pournelle e 7-Nov-83 08:39:56-MST,578;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 7 Nov 83 08:39:53-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 6 Nov 83 3:49 EST Received: From Sri-Unix.ARPA by BRL via smtp; 6 Nov 83 3:39 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 6 Nov 83 0:24-PST Date: 29 Oct 83 19:22:06-PDT (Sat) To: info-cpm@brl From: harpo!eagle!hou5h!hou5g!hou5f!ariel!vax135!cornell!uw-beaver!uw-june!palmer@ucb-vax Subject: Re: Adam Article-I.D.: uw-june.701 In-Reply-To: Article <12905@sri-arpa.UUCP> 7-Nov-83 08:50:38-MST,1109;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 7 Nov 83 08:50:33-MST Received: From Brl-Bmd.ARPA by BRL-VGR via smtp; 6 Nov 83 17:57 EST Date: Sun, 6 Nov 83 17:51:00 EST From: Charlie Strom (NYU) To: Jeffrey Shulman cc: INFO-CPM@brl-vgr Subject: Re: Coleco's Adam I havehad an Adam for several days and am quite please with it thus far. The keyboard is real, the word processor (in rom) is adeequate (not Wordstar, but then look at the price), and the printer actually prints! It is a daisywheel (96 char diablo plastic I think and Hytype-I ribbons?) and is SLOW and NOISY, supposedly will super and subscript utilizing half linefeeds (have not tried yet). Lots of future expansion planned, like RS232, centronics port, CP/M (IOS?) compatibility, modem, 64K extra memory, etc. I hope it all comes to fruition. Right now there is NO technical info and no way to get into the operating system (assuming there is one or at least a rom monitor). Have I covered all questions? 7-Nov-83 08:50:59-MST,622;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 7 Nov 83 08:50:55-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Nov 83 0:45 EST Received: From Hi-Multics.ARPA by BRL via smtp; 7 Nov 83 0:41 EST Date: 6 November 1983 21:42 cst From: Chan.CST@hi-multics Subject: CP/M Educational Programs To: info-cpm@brl Acknowledge-To: Chan.CST at HI-MULTICS Does anyone has a list of Educational programs written for CP/M? There are a lot for Apple, TI, etc. but I don't seem to see a lot for CP/M. Is my impression true? Is there any in the P.D. ? 7-Nov-83 08:51:59-MST,1078;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 7 Nov 83 08:51:54-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 7 Nov 83 8:22 EST Received: From Mit-Mc.ARPA by BRL via smtp; 7 Nov 83 7:38 EST Date: 7 November 1983 07:26 EST From: Eric Stork To: info-cpm@brl Subject: Need Advice on Using CP/M Function 13 Of course, when changing disks one should always do a ^C. But sometimes I forget, and then if I use my editor I get a R/O message when I try to save the file (and of course lose my work). As an experiment, I patched a CALL to CP/M Function 13 (Disk Reset) into the initialization routine for the editor. Only five bytes are added by that, and it seems to work like a charm. But that is so obvious a solution that I cannot imagine that the authors of editors had not thought of it. Perhaps the did NOT include that for that may come nd bite me. So my question: What, if anything, is wrong with this approach? Where are the gotchas? Thanks, Eric 7-Nov-83 11:22:37-MST,3737;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 7 Nov 83 11:22:24-MST Received: From Brl-Bmd.ARPA by BRL-VGR via smtp; 7 Nov 83 12:46 EST Date: Mon, 7 Nov 83 12:39:42 EST From: Keith Petersen To: Info-Cpm@brl-vgr Subject: Dysan disk diagnostic program Dysan Corp. has released their disk diagnostic program to the public domain, thanks to Dave Hardy for suggesting it to them. The program is available on SIMTEL20 as: MICRO:DDD.ASM MICRO*DDD.DOC It has to be modified for different hardware but is an excellent starting point if you can add the code for your system. Here is the short DOC file that explains: --- Following is the documentation provided by Dysan Corporation for use with their Digital Diagnostic Diskette (DDD). Using the DDD, it is possible to align most floppy drives with no test equipment - other than your computer and a screwdriver or two. The program DDD.ASM is a generic one, and is useless until modified for a specific computer or controller board. We will be maintaining copies of all of these "specific" versions on Technical CBBS ( (313) 846-6127 ), so if you modify this program for your own use, please pass a copy along to us there, so that others may also benefit from Dysan's contribution of this program to the public. -Dave Hardy, CDP Corp., Technical CBBS <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> Requirements for using Dysan's Diagnostic Program DYSAN CORPORATION CE DIVISION DRIVE DIAGNOSTIC PROGRAM for CP/M-80 The Drive Diagnostic Program is a sample program showing how the Digital Diagnostic Diskette (DDD) can be used for Floppy Drive checking. The program requires the following hardware to run: CRT with cursor positioning and clear screen commands. (The program is currently configured for a Hazeltine 1500.) CP/M-80 system with at least 32k of memory. At least one 8" or 5.25" floppy disk drive. This source program is provided on an 8" single density, one- sided diskette that is compatible with the CP/M-80 operating system. The program provided will not run "as-is"; it must be modified by someone experienced in 8080 Assembly language, CP/M-80 and disk drive controller interfacing. In order to make the program run with the target system, there are four assembly language subroutines that must be modified to interface with the system's disk controller/drive(s): 1) "SELECT" - Selects and Homes the drive. 2) "TRACK" - Seeks to the track number found in register A. 3) "HOME" - Restores the selected drive's head to track 0. 4) "READ" - Reads sector in register "A" and exits with error status. The above routines must be coded within the Diagnostic Program, instead of calling the routines through the BIOS, because the BIOS may interfere with disk I/O operation (either by trapping disk errors or deblocking sector calls, i.e. where sector sizes are greater than 128 bytes). The sample program was coded for use with the Western Digital FD-1793 floppy disk controller IC. The program will work with other controllers (i.e. NEC uPD765 and Intel 8272 FDCs) by modifying the source program, as indicated above. Because some disk controllers don't allow programmed access to the drive's INDEX signal (i.e. NEC and Intel), "Index Timing" and "Spindle Speed" testing are not possible with the current program. 7-Nov-83 12:56:01-MST,3859;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 7 Nov 83 12:55:41-MST Date: Mon, 7 Nov 83 14:19:19 EST From: Dave Towson (info-cpm) To: info-cpm@brl-vgr Subject: Information for new list members. As the new list-maintainer for this list, I have just sent the attached text to a new list member who requested information concerning the archives of public domain software. It occurs to me that perhaps it would be useful to post this information to the net periodically. What do you think? Have I omitted anything important? Did I make any mistakes? Text follows: ---------------------- There is a collossal amount of free public domain CP/M software in three archives on SIMTEL20, a PDP-20 running TOPS-20 at White Sands Missile Range. To get directory listings, crank up FTP with user-name ANNONYMOUS and password FTP (or any non-null string) and then do the following: get "micro:cpm.dirlst" local_file_name get "micro:cpmug.dirlst" local_file_name get "micro:sigm.dirlst" local_file_name bye The first will get you a directory of the archive that was recently moved from mit-mc. This is the one to watch for the very latest offerings as it is updated frequently. The second is the full offering of the CP/M Users Group. It (and the third archive) will be updated as new disks are issued. The third is the full offering of the Special Interest Group for Microcomputers, a service of the Amateur Computer Group of New Jersey. There are many overlaps in the three archives, but you will find the lastest versions in the archive. In general, the archived software is very good, having been worked-over and refined by multiple users. The comments tend to be complete and imformative. Examples of typical file retrievals follow: get "micro: mdm712.com" mdm712.com get "micro:assign.asm" assign.asm get "micro:ad.com" ad.com All files in the CPMUG and SIGM archives have been stored in a binary format that had its roots at mit-mc. To retrieve any of these files you must use FTP in TENEX mode. If your FTP server doesn't do TENEX use type L8 (which does the same thing). You will have to discard the first four bytes from every program you obtain from either of these archives. This is because the binary format used for storage has the identifier DSK8 in sixbit code at the beginning of each file. To strip the first four bytes, you can use either your host's utilities or a CP/M program called ITSCVT.HEX, which can be found in directory . Files in the archive are stored in two formats, ASCII for DOC, HEX and ASM files, and ITS binary (as described above) for COM and "squeezed" files. Squeezed files have been compressed using the programs available in directory to obtain approximately a 35-percent size reduction. These files, which can be identified by the letter Q in the filetype field (for example, the file micro:z2con.wq is a squeezed file) must be transferred as binary files and then unsqueezed. The unsqueezing can be done on the CP/M system using USQ-20.COM (or whatever is the current version) from directory , or there are several host-based unsqueezers in the archive (see for example, directory ). One last comment: In all of the above examples the quote-characters are there for the benefit of UNIX users. Other operating systems may not need (or may have trouble with) these quotes. Happy hacking! Dave Towson info-cpm-request@brl-vgr <-- please note proper machine address 7-Nov-83 15:18:55-MST,503;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 7 Nov 83 15:18:47-MST Received: From Sri-Nic.ARPA by BRL-VGR via smtp; 7 Nov 83 16:27 EST Received: from USC-ECLB by SRI-NIC with TCP; Mon 7 Nov 83 13:26:15-PST Date: 7 Nov 1983 1324-PST From: FCDSSASD Subject: NET MAIL To: INFO-CPM@brl-vgr cc: FCDSSASD%USC-ECLB@sri-nic 1. REQUEST TO BE ADDED TO THE NET MAILING LIST FOR INFO-CPM. THANKS, BRAD ------- 7-Nov-83 19:23:34-MST,1305;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 7 Nov 83 19:23:28-MST Received: From Parc-Maxc.ARPA by BRL-VGR via smtp; 7 Nov 83 20:57 EST Date: Mon, 7 Nov 83 15:24 PST From: Thomka.es@PARC-MAXC.ARPA Subject: Re: Coleco's Adam In-reply-to: "strom@brl-bmd.ARPA's message of Sun, 6 Nov 83 17:51:00 EST" To: Charlie Strom (NYU) cc: Jeffrey Shulman , INFO-CPM@brl-vgr.ARPA By what I have heard about the Adam in some various computer rags, I thought that the BASIC computer language was in ROM, and built into the Adam. Not that the word processor runs on BASIC, (very unlikely!) but that both packages were resident in ROM and available. Can you get the BASIC working? If so would you try this simple program and tell me the results? 10 N=0: INPUT "How many loops to do? "; L 20 FOR C = 1 TO L: N=N+1: N= TAN( ATN( EXP( LOG( SQR( N*N))))): NEXT C 30 PRINT "The end value is "; N On two different times, input values 1000 and 2500 and let me know what the resulting numbers were and the time it took to compute them. The reason I want the information is that I'm compiling a list of various computers' (Apple, IBM, Radio Shack, etc.) answers and their times. Thanks, Chuck 8-Nov-83 11:27:07-MST,1741;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 8 Nov 83 11:27:00-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 8 Nov 83 1:35 EST Received: From Rand-Relay.ARPA by BRL via smtp; 8 Nov 83 1:32 EST Date: Mon, 7 Nov 83 03:53:51 CST From: Stan Hanks Return-Path: Subject: FDC's for truly ancient S100 machines Received: by RICE (AA02630); Mon, 7 Nov 83 04:24:43 CST To: info-cpm@brl Message-Id: <1983.11.07.03.53.51.600.15460@Rice-vms.rice> Via: Rice; 7 Nov 83 17:26-PST A friend of mine recently acquired an ancient IMSAI in the throes of decrepitude. Rather than pitch the CPU and re-populate the bus, he has elected to retain the current card set and "enhance" it. Problem with this particular machine is that it has no FDC; the current mass storage is a Tarbell cassette interfacer board (remember when that was about as good as a home hacker could do?? sigh....) Anyway, as this is a pre-696 machine, he is wondering what controller he can attach to it without having to really modify either the FDC or the CPU/memory/whatever. The optimal solution will be a 5.25/8 controller that will do everything from SSSD to DSDD; he will settle for 8 inch DSDD. BIOS for CP/M 2.2 is helpful but not required if sufficient documentation is available. Any help will be greatly appreciated. Please reply directly to me; I'll summarize to the list if sufficient response is made. Thanks much! Stan Hanks Department of Computer Science Rice University Houston TX stan.rice@rand-relay (arpanet) stan@rice (csnet) ...!lbl-csam!rice!stan (uucp) 8-Nov-83 11:29:45-MST,1476;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 8 Nov 83 11:29:40-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 8 Nov 83 8:48 EST Date: Tue, 8 Nov 83 8:27:56 EST From: Keith Petersen To: Stan Hanks cc: Info-Cpm@brl-vgr Subject: Re: FDC's for truly ancient S100 machines Stan, I use a Morrow DJ2D floppy disk controller with two 8" drives. It allows double-density double-sided (1.2 megabytes on one 8" disk!). It comes with CP/M 2.2, Microsoft Basic-80 (MBASIC 5.21), and source code for the CBIOS. If you use the memory-mapped console port on the FDC board, you can bring up CP/M immediately without having to do any CBIOS configuration. The FDC uses memory-mapped I/O and comes standard with a starting address of E000h. There is an option (I recommend it) to have F800h as the starting address. This would use up F800-FFFFh which isn't too bad. Dave Hardy has modified his DJ2D to bank switch, thus allowing it to reside outside of the main system RAM, but this requires a modification to the CBIOS software. The DJ2D uses CPU transfers instead of DMA, so it does not conflict with other boards that use DMA. Mine has been used sucessfully with both an IMSAI-8080 and a generic S-100 box that has a Cromemco ZPU (Z80 CPU) card. I do NOT use dynamic memory because I've had problems with it when using the Z80. --Keith 8-Nov-83 11:35:47-MST,4147;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 8 Nov 83 11:35:36-MST Received: From Columbia-20.ARPA by BRL-VGR via smtp; 8 Nov 83 10:26 EST Date: Tue 8 Nov 83 10:25:58-EST From: Frank da Cruz Subject: KERMIT for CP/M-80 To: Info-CPM@BRL-VGR.ARPA, Info-Micro@BRL-VGR.ARPA cc: Info-Kermit@COLUMBIA-20.ARPA A few months ago, I announced the file transfer protocol KERMIT to the Info-CPM and Info-Micro lists. I never got very much feedback about it, though I have seen it mentioned now and then on both lists. For those of you who missed the announcement, the KERMIT distribution area is on host COLUMBIA-20, in the area KER:, accessible with anonymous FTP. It's a big area (but nothing to rival the size of the CPM archives, of course), so if you're interested, you should look first at the file KER:00README.TXT, which lists what versions are available and describes the naming conventions. KERMIT is available for a wide variety of micros and mainframes. KERMIT for CP/M provides terminal emulation and file transfer. Versions for about 15 different systems are built from a common source file, written in standard DR ASM for the 8080, using conditional compilation, either on the micro itself or on a DEC-10 or -20 using the cross assembler MAC80 (which is itself available in the KERMIT area). A few weeks ago, a new version of CP/M-80 KERMIT, v3.5, was announced to the Info-Kermit list, with a plea that users of the various systems supported by KERMIT-80 (as it's called) report back as to whether the new version worked on their systems. I had hoped to get the bugs ironed out before announcing it to the world at large. Unfortunately, I got very few reports. Since we lack examples of most of these systems at Columbia to try the new KERMIT-80 out on, I'm announcing it now anyway. If you have any of the systems listed below, please try to get KERMIT for your machine, try it out, and: (a) let me know if it works; (b) if it doesn't, describe the symptoms; (c) if you can provide a fix, please do so (you'll be given full credit). Here are the systems: System: Filename: Status: DEC VT-180 KER:CPMROBIN.HEX Tested, works up to 4800 baud DEC Rainbow-100 KER:CPMRAINBO.HEX Tested, works up to 1800 baud DEC DECmate II KER:CPMDMII.HEX Tested, works up to 9600 baud Heath/Zenith 89 KER:CPMHEATH.HEX Not tested Heath/Zenith 100 KER:CPMZ100.HEX Not tested Apple II* KER:CPMAPPLE.HEX Not tested TRS-80 II** KER:CPMTRS80.HEX Not tested Osborne 1*** KER:CPMOSBORN.HEX Tested, doesn't seem to work at all Intertec Superbrain KER:CPMBRAIN.HEX Not tested Kaypro II KER:CPMKAYPRO.HEX Tested, mostly works OK. Telcon Zorba KER:CPMTELCON.HEX Not tested Vector Graphics KER:CPMVECTOR.HEX Not tested Ohio Scientific KER:CPMOSI.HEX Not tested Generic CP/M 2.x KER:CPMGENERI.HEX Tested OK on Rainbow, DECmate, VT180 Generic CP/M 3.0 KER:CPMPLUS.HEX Not tested *With Z80 soft card, Hayes micromodem II **With CP/M 2.25 ***Can you fix it? You can download the .HEX file with MODEM, or your old version of KERMIT, or any other technique that works, and then load it using the CP/M LOAD command, to produce a runnable .COM file. The generic versions are supposed to run on any CP/M-80 system, since they don't use only CP/M calls for device manipulation. The 2.x generic version depends on the system having fully implemented the "option" IOBYTE business, and the user setting the values of the IOBYTE correctly and re-building. The 3.0 generic version should run as-is on any CP/M 3.0 system; it has been reported to work (in an earlier version of KERMIT-80) on the Osborne Executive and the Micro Mate. The source for all these versions is in KER:CPMBASE.M80. There's also a file KER:CPMKERMIT.DOC which explains the situation in greater detail. - Frank da Cruz, Columbia University ------- 8-Nov-83 11:36:40-MST,886;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 8 Nov 83 11:36:35-MST Received: From Sri-Nic.ARPA by BRL-VGR via smtp; 8 Nov 83 12:22 EST Received: from USC-ECLB by SRI-NIC with TCP; Tue 8 Nov 83 09:14:52-PST Date: 8 Nov 1983 0914-PST From: FCDSSASD Subject: FORMS PROGRAMS FOR CPM-80 HOST To: INFO-CPM@brl-vgr cc: FCDSSASD%USC-ECLB@sri-nic DOES ANYONE KNOW OF EXISTING SOFTWARE THAT WILL ALLOW THE GENERATION AND HANDING OF FORMS EITHER PUBLIC DOMAIN OR COMMERCIAL. The requiremens are as follows: 1. Flexibility. Can it handle various form lengths and widths 2. simplicity. Does it take forever to program one form THATS IT !!! I would really appreciate any information oFORMS SOFTWARE for a CPM-80. Send responses to FCDSSASD@USC-ECLB Thanks, BRAD ------- 9-Nov-83 08:33:38-MST,582;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 9 Nov 83 08:33:30-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 8 Nov 83 21:20 EST Date: Tue, 8 Nov 83 21:12:29 EST From: Harold Carter (AFIT) To: info-cpm@brl Subject: 6800 cross-assembler needed We need a 6800 cross-assembler which runs on a cpm machine (preferable) or a VAX running VMS to support a robotics project at AFIT. Does a public domain beast exist? Would like a cross disassembler as well. Thanks.... Hal 9-Nov-83 08:35:49-MST,1021;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 9 Nov 83 08:35:34-MST Received: From Brl-Bmd.ARPA by BRL-VGR via smtp; 9 Nov 83 6:36 EST Date: Wed, 9 Nov 83 6:34:36 EST From: Charlie Strom (NYU) To: Thomka.es@parc-maxc.arpa cc: INFO-MICRO@brl-vgr, INFO-CPM@brl-vgr Subject: Re: Coleco's Adam The BASIC supplied with the Coleco is on tape, not in rom. It is a Z80 basic one would assume since that is the CPU ship used, but it claims Apple basic compatibility on the source level. There is no peek or poke or any other way I can figure out to get a look at ram (that's compatible??) I will indeed run the benchmark for you and report back. P.S. I am cc'ing the Adam information to INFO-CPM since there will definitely be a CP/M capability in the Adam in the near future. If I am incorrect that the list is interested in this machine, please advise and I will stop clogging the net with unwanted messages. 10-Nov-83 09:01:04-MST,1055;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 10 Nov 83 09:00:59-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 9 Nov 83 18:48 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 9 Nov 83 18:31 EST Received: from ISL by SUMEX-AIM with Pup; Wed 9 Nov 83 15:31:57-PST Date: Wednesday, 9 Nov 1983 15:32-PST To: hcarter@brl, info-cpm@brl Subject: 6800 xasm Reply-to: kevinw@su-dsn From: kevinw@su-dsn Sender: kevinw%isl@BRL.ARPA there is a set of xasms for the 1802 and 6800 in the c users group. these are for bds c and are public domain. no info on how they work, but i have the disk somewhere. also contains rt11 copy stuff. c users group is in yates, kansas (see issue of dr dobbs for address (not for c users group but same place -- they sell the compiler there too) you should be able to modify them for vms-c if you can get copies there. cpmutl works for unix from /dev/floppy, but i don't know if there is a version for vms. cheers. --Kevin kevinw@su-dsn 10-Nov-83 09:03:38-MST,827;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 10 Nov 83 09:03:35-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Nov 83 3:11 EST Received: From Sri-Unix.ARPA by BRL via smtp; 10 Nov 83 3:05 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 9 Nov 83 23:55-PST Date: 9 Nov 83 0:33:58-PST (Wed) To: info-cpm@brl From: hplabs!hp-pcd!craig@ucb-vax Subject: Re: Orphaned Response - (nf) Article-I.D.: hp-pcd.2376 #R:sri-arpa:-1277700:hp-kirk:17700001:37777777600:227 hp-kirk!craig Nov 7 09:55:00 1983 about MARC I talked to George x at Vortex (who have taken over MARC) and they have no plans for CP/M or 8 bitters. MARC will be for (I think) the 68000 only and will be bundled with a machine. Craig Durland hp-cvd!craig 10-Nov-83 09:10:16-MST,1145;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 10 Nov 83 09:10:11-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 9 Nov 83 18:44 EST Received: From Sri-Unix.ARPA by BRL via smtp; 9 Nov 83 17:59 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 5 Nov 83 6:28-PST Date: 2 Nov 83 7:14:12-PST (Wed) To: info-cpm@brl From: ihnp4!houxm!houem!gtp@ucb-vax Subject: CPM prog. to change fcb wanted Article-I.D.: houem.184 I am looking for a cpm program that will change the "user" entry in the cpm file directory. What I want to do is be able to set up a work area (maybe user 0 or user 15) and be able to have files moved in and out of the work area without the overhead of physically copying them. I am not so concerned with copying one or two files, but am thinking in terms of entire user areas. I.e. change all files in user 3 to the chosen work area. Looking at the fcb block it seems that I should only have to change the first byte. Any information would be helpful. Also looking for any other disk utilities that might be useful. Thanks 10-Nov-83 09:12:27-MST,807;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 10 Nov 83 09:12:22-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Nov 83 5:31 EST Received: From Sri-Unix.ARPA by BRL via smtp; 10 Nov 83 5:26 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 10 Nov 83 2:24-PST Date: 8 Nov 83 4:19:21-PST (Tue) To: info-cpm@brl From: menlo70!nsc!jima@ucb-vax Subject: Are there Modula-2 compilers for Z80+CP/M ? Article-I.D.: nsc.483 ... Are there any modula-2 *compilers* (not interpreters) for Z80 (or 8080) running CP/m 2.2? If anyone has experience with such, are they practical in small (64K) machines? Can large programs be processed in a reasonable time? Jim Avera (408) 984-4846 ...decvax!menlo70!nsc!jima 10-Nov-83 12:47:39-MST,1248;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 10 Nov 83 12:47:32-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Nov 83 13:13 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 10 Nov 83 12:57 EST Date: Thu 10 Nov 83 09:57:31-PST From: Sam Hahn Subject: Re: CPM prog. to change fcb wanted To: ihnp4!houxm!houem!gtp@UCB-VAX.ARPA cc: info-cpm@BRL.ARPA, SHahn@SUMEX-AIM.ARPA In-Reply-To: Message from "ihnp4!houxm!houem!gtp@ucb-vax" of Wed 2 Nov 83 07:14:12-PST Re: fcb modification program. There's a public domain program (I forget whether it's in CP/MUG or SIG/M) called MAKEUSER that modifies the user number of selected files. As implemented, it does NOT look at user numbers of files before user-number- modification, but the source is (I think) included on the disk, so it should be an easy enough mod to include a filter on the input filespecs. The reason I'm unclear is that I don't have the original disk close at hand, since I just modified it, and keep only the .COM around nearby. Someone may be able to pick up on this reference before I get around to finding it myself. -- sam hahn [shahn@sumex-aim] ------- 10-Nov-83 13:35:24-MST,1454;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 10 Nov 83 13:35:18-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 10 Nov 83 13:48 EST Date: Thu 10 Nov 83 13:47:25-EST From: PGA%MIT-OZ@MIT-MC.ARPA Subject: BDOS ERROR R/O, ARCHIVE BITS To: info-cpm@BRL-VGR.ARPA, pga%MIT-OZ@MIT-MC.ARPA I could use some general information about how the BDOS decides a file or drive is R/O. I have been trying to use the ARCHIVE program, but I find that when I try to copy a file from hard disk to floppy, if the archive bit on the file on hard disk is set, then the next extent I try to copy, finds the drive write protected and gets a BDOS R/O error. This happens both with PIP and other copying programs. The result is that once I've archived a file I can't read the original without calling archive and resetting the archive bit. Has anyone had any similar problems with ARCHIVE or the archive bit? Several points: The same thing happens whether I use the archive patch or my own modified (recompiled) BDOS patch. It even happens if I use a vanilla BDOS, once the archive bits have been set. My system has two MORROW m26 drives and 2 SSDD Floppy drives running off a CCS controller. The processor and memory are CCS. There only seems to be a problem when going from hard disk to floppy. Copying between the two hard disks is unimpeded. Any ideas? Phil ------- 10-Nov-83 18:39:57-MST,577;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 10 Nov 83 18:39:50-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Nov 83 19:51 EST Received: From Mit-Ml.ARPA by BRL via smtp; 10 Nov 83 19:44 EST Date: 10 November 1983 19:46 EST From: Herb Lin Subject: other people running on G&G systems... To: info-cpm@brl are there other people out there running on G&G systems? if so, let's share experiences. I have a bunch of information specific to G&G I will share with interested parties.. 10-Nov-83 18:50:17-MST,4408;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 10 Nov 83 18:50:06-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Nov 83 20:02 EST Received: From Rand-Unix.ARPA by BRL via smtp; 10 Nov 83 19:58 EST Date: Thursday, 10 Nov 1983 16:56-PST Realname: Lauren Weinstein To: INFO-CPM@brl Subject: Erroneous information from hp-pcd!craig about MARC From: lauren@rand-unix I sincerely hope that this will be my last message on this topic. I don't know what hp-pcd!craig has been smoking, but his information regarding MARC is absolutely and totally wrong and confused. There isn't any "George" at Vortex. I AM VORTEX. VORTEX IS ME. Period. I will NOT be selling or distributing MARC in any manner. The MARC software project has been terminated. MARC was designed only for the 8080/Z80 processors and there have never been any plans to distribute a MARC for the 68000 or any other processors. In point of fact, the overwhelming percentage of software in the MARC software package is written in a non-standard 8080 assembler and is most decidedly NOT portable in any manner. To be blunt, the system was not really usable as other than a toy. Performance with floppies was miserable and could not be reasonably improved. Even with hard disks, many operations were extremely slow. The system could NOT make use of additional memory over 64K in any manner, and the useful workspace for user programs ended up being only around 30K, sometimes even less. CP/M compatibility did not function properly for about 75% of currently tested CP/M programs. The MARC software package is fundamentally limited by its original design parameters, and has no future beyond hardware which is rapidly heading into oblivion -- and, as I stated, it doesn't work well enough even on that hardware. There are a variety of software products from various vendors on the market which can provide much of the MARC functionality in a much more reasonable manner, and which won't ignore the entire base of existing CP/M software in the process. Microshell and Software Tools are two obvious examples of reasonable approaches to the problem of providing such an environment on limited machines. There are also packages which can make effective use of bank-switched memory and provide for much faster disk access, which should help to provide functionality for that hardware which MARC could not and cannot provide. MARC was a good effort but is just too fundamentally limited by the underlying hardware base for which it was designed and written. It is just "too much" for such hardware -- the operating system takes up so much of the memory and disks that there just isn't anything reasonable left for the humans! Also very important is the fact that MARC's being written mostly in 8080 assembler made it difficult to maintain and modify and essentially impossible to take forward into the future in the rapidly changing micro marketplace. You might be interested to know that of the people I've talked to about the termination of the project, the vast majority admitted that they were planning to try upgrade to newer hardware (usually with lots more memory and usually running a fullblown multiprocess Unix or real multiprocess Unix look-alike system) in the near future. Most of the people (few as they were) who sounded the most disappointed were those with hardware that would not reasonably run MARC in any case. However, the bottom line is that bugs and poor performance would require so much more code to fix properly that the remaining memory space would be made even smaller and less useful! I don't sell *or* distribute software with which I am not happy. I never sold a single copy of the MARC software package because I refused to send out buggy and limited software. It doesn't matter whether the package was going to cost $0 or $500, I simply refuse to distribute software with which I am dissatisfied. I've spent a large amount of time on the project, and I'm not happy about the final outcome -- but it's time to face reality on this topic. It was fun trying, anyway, but I've made my decision and it is final -- I need to get on with my life and try to make a living! I really have nothing more to say about this. That's all, folks. --Lauren-- 10-Nov-83 19:34:26-MST,1885;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 10 Nov 83 19:34:17-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Nov 83 20:58 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 10 Nov 83 20:46 EST Date: Thu, 10 Nov 83 17:46 PST From: MMOON.ES@PARC-MAXC.ARPA Subject: Re: CPM prog. to change fcb wanted In-reply-to: "ihnp4!houxm!houem!gtp@ucb-vax.ARPA's message of 2 Nov 83 7:14:12 PST (Wed)" To: ihnp4!houxm!houem!gtp@ucb-vax.ARPA cc: info-cpm@brl.ARPA DUPUSR2.ASM OR DUPUSR21.ASM are floating around on various RCP/Ms & will do what you want with a little extra effort. This program creates a *duplicate* directory entry in a comand-line specified user area. One must then go back and delete the file in the original user area if access to it from that user is not desired. This second delete must be followed by a -C to force a fresh read of the allocation vectors into memory. The sectors where the program or data reside have not, of course, been physically nulled by the erasure, but by marking them as deleted in *any* user area which has a directory entry for the particular file, you have caused an update of the in-memory allocation vector which will cause those sector bits in the bit mapped to toggle, thus marking these sectors as free to be written into, which they are not. The -C thus avoids a potential overwrite problem by renewing the allocation vector. I have been using DUPUSR21 for several months to very good effect under ZCPR2, using it also to move files into different user areas as well as making duplicate entries for the same file. The program documents the above mentioned side effect in the commented code. Also, it will accept wildcard file designations so an entire directory could be moved in this manner. Enjoy. MMoon.es 14-Nov-83 08:50:52-MST,791;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 08:50:48-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 10 Nov 83 21:36 EST Date: 10 Nov 1983 19:34 MST (Thu) Message-ID: From: "Frank J. Wancho" To: INFO-CPM@brl-vgr Subject: New CPM.DIRLST A new format for the .DIRLST files has been developed. The first of this new format is [SIMTEL20]MICRO:CPM.DIRLST. Here's a sample: Filename (MICRO:) Type Size CRC (bytes) 6502.SIMLBR COM 75904 074AH 6DASM.MAC ASCII 2659 3E16H D6502.MAC ASCII 11753 C978H APBDSC.PATCHS ASCII 7371 F65EH APBOOT.MAC ASCII 1173 CF3AH ... --Frank 14-Nov-83 08:51:01-MST,1270;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 08:50:57-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Nov 83 22:17 EST Received: From Mit-Mc.ARPA by BRL via smtp; 10 Nov 83 22:06 EST Date: 10 November 1983 22:03 EST From: Allan D. Plehn Subject: Program to change User Area of files. To: ihnp4!houxm!houem!gtp@ucb-vax cc: MMOON.ES@parc-maxc, Shahn@sumex-aim, INFO-CPM@brl At SIMTEL20, in MICRO:, you will find MAKE.ASM and MAKE.COM. I believe that these are just what you are looking for. Checking against versions available on a local RCPM, I find that the ones on SIMTEL20 are old versions. I have placed the new version of the asm file, MAKE15.ASM, on MIT-MC in GUEST4;PLEHN MAKASM. Also, the newer version has an accompanying .DOC file (in addition to built-in help in the the .COM file). The documentation file is in GUEST4;PLEHN MAKDOC. If you have any difficulty FTPing the new version from MIT-MC, let me know and I will mail them to you. The checksums are: 9E21 for the .DOC file A7Af for the .ASM file. SIMTEL20 list maintainer: Kindly pick up these files and add them to MICRO:. Thanks. Al Plehn 14-Nov-83 08:51:14-MST,1533;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 08:51:07-MST Received: From Parc-Maxc.ARPA by BRL-VGR via smtp; 10 Nov 83 22:17 EST Date: Thu, 10 Nov 83 19:16 PST From: SSalzman.ES@PARC-MAXC.ARPA Subject: Re: BDOS ERROR R/O, ARCHIVE BITS In-reply-to: "PGA%MIT-OZ@MIT-MC.ARPA's message of Thu, 10 Nov 83 13:47:25 EST" To: PGA%MIT-OZ@MIT-MC.ARPA cc: info-cpm@BRL-VGR.ARPA Hi. There is a bug in the archive patch to the BDOS and there is a fix for it (ARCHIVE.FIX). The note in ARCHIVE.FIX describes what you're talking about. The fix is as follows: force$r$w equ bdos$entry+05BAh ;force read write disk org force$r$w ret ; return from 'check changed disk' I'm really not sure where in the patch that belongs but here is where I put it and I've had no problems: wrt$dir equ bdos$entry... scratch equ bdos$entry... ; INSERT FIX HERE... org wrt$dir . . . Try it out. It should work. I've tried to get to Kelly Smith and get the latest version of the program but he's moving and his system is down. If you want a good rigid backup utility a friend of mine here reccomended QBAX. It's only $30 and it has I/O redirection and a few other nifty things. The new version of that should be out in a while and it will even handle breaking up large files onto several floppies (so I'm told). I'll be ordering it myself soon for a project I'm working on. Good Luck. Isaac Salzman. SSalzman.es@PARC-MAXC 14-Nov-83 08:58:38-MST,4483;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 08:58:19-MST Received: From Sri-Unix.ARPA by BRL-VGR via smtp; 13 Nov 83 1:40 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 12 Nov 83 2:55-PST Date: 9 Nov 83 5:35:04-PST (Wed) To: info-cpm@brl From: harpo!floyd!clyde!burl!hou3c!hocda!machaids!djj@ucb-vax Subject: CRC information, summary Article-I.D.: machaids.661 About a month ago I put a request for CRC (Cyclic Redundancy Codes) information on this net. I received in a number of good programs and comments, and several requests to forward whatever I discovered. Since I have not been able send mail to several of the people who made requests, I'll put this summary on the net. It appears that CRC calculations are based on a polynomial that is not standardized, so it is possible to have several different valid CRC values for the same file simply by using different polynomials. There is an article in the June 83 issue of IEEE Micro which gives a little background on CRC and on a method for calculating same. Unfortunately, the examples are given in assembler. One of the C programs I received, and modified slightly produces CRC values identical to those produced by CRCK.COM and "uc" the UNIX/CPM communications program that is intended to replace "umodem". Here is the source code ---- "crck.c" (118 lines; 493 words; 2874 bytes): /* * ---- crck.c ---- * * Version 1.0 - 4/9/83 * * This UN*X program performs a file hashsum calculation consistent * with the de facto standard (but misnamed) "CRCK" program for CP/M. * * Usage: crck [-w] filename... * * The -w flag suppresses the warning message that normally * is printed when a file is found not to be a multiple of * 128 bytes in size. (Such a file cannot be a faithful copy * of a CP/M file, since CP/M files are always a multiple of * 128 bytes). * * Notes: * 1. Two versions of the CRCK program exist in the CP/M * world. Variants of Keith Petersen's original program * are the de facto standard, even though they misuse the * underlying CRC calculation subroutine and therefore don't * really perform a "CRC" function. This program produces * hashsums consistent with Petersen's scheme, currently * found in the "CRCK4x.ASM" series. * * 2. In order for valid comparisons to be made between the * CP/M and UNIX copies of a file, the file must, of course, * have been transferred intact; i.e., with the "-rb" option * of umodem, or the "-b" option of rb. * * Jeff Martin * Naperville, Il. * 4/9/83 * Version 1.1 -- djj Oct 13, 1983 * Changed output print format, to make it more readable! * Don Jackowski, Mine Hill, NJ */ #include #include #define CPMSEC 128 main(argc, argv) int argc; char *argv[]; { int c, fdi, warn, wflg; char *s, *in_file; char cbuf[CPMSEC]; unsigned crc, crck(); warn = 1; while (--argc > 0 && (*++argv)[0] == '-') { for (s = argv[0]+1; *s != '\0'; s++) { switch (*s) { case 'w': warn = 0; break; default: printf("illegal option: '%c'\n", *s); argc = 0; break; } } } if (argc < 1) { printf("Usage: crck [-w] filename...\n"); exit(1); } while (argc-- > 0) { in_file = (argv++)[0]; fdi = open(in_file, O_RDONLY); if (fdi < 0) { printf("Cannot access %s\n", in_file); continue; } crc = wflg = 0; while ((c = read(fdi, cbuf, CPMSEC)) > 0) { if ((c != CPMSEC) && warn) { wflg++; } crc = crck(cbuf, c, crc); } printf("%14s --> %04X", in_file, crc); if(wflg)printf(" <-- not CP/M sector sized.\n"); else printf("\n"); close(fdi); continue; } } /* * The only good thing to be said about the following function is that * it faithfully emulates the 8080 code in the CRCK4x.ASM series. It * does NOT perform a CRC calculation, but does a rather bizarre hash * sum. */ unsigned crck(buf, size, oldcrc) char *buf; int size; unsigned oldcrc; { register unsigned newcrc, tmp; register int i, qbit; newcrc = oldcrc; for (i = 0; i < size; i++) { qbit = newcrc & 0x8000; newcrc <<= 1; tmp = (newcrc + *buf++) & 0xff; newcrc = (newcrc & 0xff00) | tmp; if (qbit) { newcrc ^= 0xA097; } } return (newcrc); } 14-Nov-83 09:00:12-MST,1150;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 09:00:04-MST Received: From Sri-Unix.ARPA by BRL-VGR via smtp; 13 Nov 83 1:43 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 12 Nov 83 6:28-PST Date: 10 Nov 83 18:34:47-PST (Thu) To: info-cpm@brl From: ihnp4!clyde!floyd!cmcl2!lanl-a!bb@ucb-vax Subject: CRC-16 byte-wise algorithms in the June 1983 IEEE Micro Article-I.D.: lanl-a.3619 ================================== I just finished converting the assembler programs given in that article into C and 8086 assembler. The C version is table driven and is very simple. The 8086 code is the on-the-fly version and should be faster and does take up less space than the compiled C version. I will send them to anyone who wants them, though it only took me about 50 minutes to do the C version, including writing the program to generate the table. The versions I have use the CRC-16 standard, that was what was used in the article. b2 Bryan Bingham ucbvax!lbl-csam!lanl-a!bb cmcl2!lanl-a!bb 14-Nov-83 09:02:47-MST,1453;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 09:02:39-MST Received: From Sri-Unix.ARPA by BRL-VGR via smtp; 13 Nov 83 1:44 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 12 Nov 83 20:11-PST Date: 8 Nov 83 13:02:52-PST (Tue) To: info-cpm@brl From: ihnp4!zehntel!varian!david@ucb-vax Subject: Re: Batch file uploading query Article-I.D.: varian.181 In-Reply-To: Article sri-arpa.13304 Kermit (from Columbia University - public domain, but they ask a $100 handling fee for a tape containing all versions) does bulk file transfers - the command you give to the receiver is "RECEIVE", and the sender sends the file name as part of the protocol (this has the disadvantage that you can't choose different names for the received files, but you can always change these later). There exist versions for UNIX and CP/M amongst many others, and among the CP/M versions is one for the H89. Kermit is available from Columbia University in the City of New York, Center for Computing Activities, 612 West 115th Street, New York, NY 10025. Point of contact is Daphne Tzoar, telephone 212-280-3703. David Brown Varian Instruments 2700 Mitchell Dr. Walnut Creek, Ca. 94598 (415) 945-2199 {ihnp4,tektronix,sytek,dual}!zehntel!varian!david {amd70,fortune}!varian!david ...!decvax!sytek!zehntel!varian!david ...!ucbvax!menlo70!sytek!zehntel!varian!david 14-Nov-83 09:06:14-MST,1321;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 09:06:09-MST Received: From Brl-Bmd.ARPA by BRL-VGR via smtp; 13 Nov 83 9:53 EST Date: Sun, 13 Nov 83 9:41:50 EST From: Charlie Strom (NYU) To: Herb Lin cc: INFO-CPM@brl-vgr Subject: Re: other people running on G&G systems... Herb, I have a 4 user (5 counting a line to a modem) G&G system we are using primarily as a Wordstar system with some use of DBASE and Supercalc. Would be happy to share information and experiences. I don't know whether this of general enough interest to share with INFO-CPM, but will solicit comments from the net and not copy that list if people are not interested. A current bit of news here is that we are waiting for a minifloppy add-on controller and drive. This will enable us to exchange info on both Morrow micro-Decision and IBM formats (I'm not sure what else). We are about to purchase several of the former machines to use as stand-alone word processing systems. This hardware has been delayed since I requested that they hold off delivery until they can supply the newest release of MP/M-816. As of Friday, this was two weeks away, though the Gifford folks said that two weeks ago! -Charlie 14-Nov-83 09:06:38-MST,1569;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 09:06:31-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 13 Nov 83 15:07 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 13 Nov 83 14:54 EST Date: Sat 12 Nov 83 13:39:33-PST From: Sam Hahn Subject: Re: other people running on G&G systems... To: LIN@MIT-ML.ARPA cc: SHahn@SUMEX-AIM.ARPA, info-cpm@BRL.ARPA Herb: I'm not currently using a G&G system, but am thinking of upgrading my S-100 system, which is now basically SD SYSTEMS boards in a new version of the IMSAI box. Thinking this mostly because I want compatibility with my existing software while gaining another world (16/32?? bit). MP/M 8-16 looks really good to me, but the reason I haven't made the move yet is that I don't know if it'll be around and supported. Unix looks, for whatever set of reasons, like it'll be the OS of choice for >8-bit systems. Extrapolating: I'd like to see on the S-100 some set of boards (Compupro??) and software which takes the idea further. Put CP/M, CP/M 86, DRI/VMS, Unix, etc compatibility in a system with smart software. Problems exist, but I see great potential for somebody willing to play around. Anyway, the point is I'd like to learn what you've got on Compupro systems, plans, and impressions/experiences. -- sam hahn [shahn@sumex-aim] PS. I'd like to hear from others with advice/information who are willing to exchange thoughts. Thanks. ------- 14-Nov-83 09:10:44-MST,7462;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 09:10:12-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 13 Nov 83 15:29 EST Received: From Mit-Ml.ARPA by BRL via smtp; 13 Nov 83 15:15 EST Date: 12 November 1983 16:26 EST From: Herb Lin Subject: review of experience with Gifford Computer systems (long) To: info-cpm@brl, info-micro@brl The following is a report to Netland about one person's experience with Gifford Computer Systems (GCS). The system in question is essentially a Godbout 816 system: 256 K memory, 2 DDDS 8 inch QUME disks, a 20MB Fujitsu Winchester disk, Epson FX-80 printer, and a 8085/8088 dual processor board. Supplied software includes MP/M8-16 (allowing both 8 and 16 bit software to be run simultanuously), MBASIC, SUPER-CALC, and dBASE II. Not bought from GCS but used in my system are an Ann Arbor Ambassador terminal, and a VADIC 3451 modem. It should be noted that I am not a hacker - I am interested in machines that make my professional life easier, and I take little pleasure in hacking for the sake of hacking; thus, service and reliability are of paramount importance to me. I have spent several years as a systems programmer in a previous life (on an IBM 1130, of all things!!), and I have a PhD in physics, so I have a good general background knowledge about matters technical, but I am/was not current in my computer knowledge about micros, CP/M, etc. Initial Pre-purchase Inquiries I made many many inquiries about different systems before deciding on GCS. Micheal Gifford (of sales) at GCS was enormously helpful, and quite straightforward about answering questions, always returning phone calls promptly, and providing useful information, both about limitations and strengths of GCS hardware. He tolerated a rather long period of questions on my part (four or five months), with a few long stretches of no contact because I was out of town - however, I got no pressure tactics from him, and that was greatly appreciated. Spontaneously, I also got a bunch of references of other GCS customers, with phone numbers and names, who proved rather useful in assessing GCS service. Actual purchase/delivery I decided to purchase in Feb or March 1983 (I think), but could not accept delivery until around May or so; they said no problem - that was twice as long as they needed to integrate my system. In my purchase letter, I enclosed a 25% deposit, but specified that for every day after the scheduled arrival day that the system was late, they would credit my account with a certain percentage of the total system cost. They did not cash my deposit check (which would have indicated acceptance of this condition as legally binding), but they nevertheless said that my system would be ready on time. It was. The initial shipment was missing a few items, and a call back to them provided these items in a week or so. A mountain of documentation was provided, except for manuals for the floppy drives; GCS told me that they themselves could not get them. Shakedown period I had considerable hardware trouble in the initial couple of months. After several days, my Winnie or controller began to flake out intermittently, sending not ready signals and other strangeness to the CPU. I had a great deal of difficulty determining that the hardware was in fact at fault, because the errors at first did not appear in the diagnostics that GCS provided - they happened only when I was using MINCE, and was getting SEEK errors. I consulted GCS about this difficulty, and they said that if the diagnostics didn't pick it up, it was probably in the software. A few calls to Mark of the Unicorn persuaded me that MINCE was not at fault, but I still had no concrete evidence that the hardware was flaky. Fortunately, the diagnostics did eventually pick up errors, at first intermittently, and then consistently. At that point, a phone call to GCS was sufficient to get a replacement Winnie and controller board in the mail, even before I returned the Winnie I had, i.e., we both put our disks in the mail at the same time. The replacement arrived in three days, and I was back up. A few weeks later, I had my second difficulty: the enclosure gave out - something in the power supply died, and only the fan was getting power. I originally thought it was the floppy disk unit that was flaky, since the floppies would not boot. A phone call to GCS helped me to determine that in fact the enclosure was at fault, and once again, a replacement enclosure was sent out promptly. A very praise-worthy point in favor of GCS - ALL my hardware service calls were returned promptly (1 day or less). Aside from these hardware hassles, I have been pleased. The shakedown seems to be over, and I have been running for many weeks now with minimial hitches (knock on wood). Beyond the shakedown I believe that my hardware hassles were essentially the luck of the dice, and I don't really hold GCS responsible - certainly they have been quite responsive when I needed hardware help. I have had a bit of trouble with radio-frequency interference with wireless telephones here, but certainly GCS isn't responsible for that - I am apparently the first person who has reported such difficulties to them, and they report being baffled too. A few annoying quirks/bugs in the software provided, but nothing unmanageable. For example, a SUB file does not allow me to change default disks; I must do this from command level manually. Other comments I withheld a non-trivial part of my payment for the system when the initial order was not complete, because some pieces were missing: the Basic interpreter, but most importantly, cabling for integrating my modem into the system. While this is an unusual thing to request, I had in my letter stated that they would integrate the terminal and modem that I already owned into the system I was buying, and this they agreed to by cashing my check. However, it was at this time that my Winnie began to flake out, and system integration of non-GCS components took second priority (and properly so). GCS was willing to replace my Winnie even without total payment, and in light of that action, I suspect that my subsequent demand that they follow through on the unusual provision of my letter concerning integration of non-GCS components might have seemed a bit excessive. They pointed out that they had indeed supported me in the absence of complete payment, and I agreed to complete the payment. The one complaint I have is that it took all told, five or six months, to finally get the modem integration stuff, and I accomplished this by asking my sales person (not customer support - which had been so good in hardware support) to stick a pin into customer support. That produced action rather quickly. Overall reactions I have no hesitation about recommending GCS as an outfit to take care of complete systems. I am convinced that if you want to buy a complete system from them, they will take very good care of you, and very promptly. If you have equipment already that you want to integrate, my experience is that they will still help, but not with the same vigor that they would otherwise. Herb Lin 14-Nov-83 09:15:33-MST,1167;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 09:15:23-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 13 Nov 83 16:03 EST Received: From Mit-Ml.ARPA by BRL via smtp; 13 Nov 83 15:47 EST Date: 12 November 1983 22:24 EST From: Herb Lin Subject: other people running on G&G systems... To: info-cpm@brl From:Sam Hahn MP/M 8-16 looks really good to me, but the reason I haven't made the move yet is that I don't know if it'll be around and supported. as far as I can tell, MP/M 8-16 is likely to be around for a while. G&G seems to have a deserved reputation for quality serviceand they do support pretty well their software. Anyway, the point is I'd like to learn what you've got on Compupro systems, plans, and impressions/experiences. From what I have heard of Compupro, I am impressed. Apart from my shakedown period, I have had zero hardware trouble. Keep your eyes peeled for my report to netland on my entire experience. if you don't get it, I will send you a copy. herb lin 14-Nov-83 09:16:17-MST,607;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 09:16:14-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 13 Nov 83 18:39 EST Received: From Lll-Mfe.ARPA by BRL via smtp; 13 Nov 83 18:34 EST Date: Sat, 12 Nov 83 22:26 PST From: "Webb Mike"@LLL-MFE.ARPA Subject: USR Password ? To: info-cpm@brl.arpa i would like to hear from anyone using a U.S. Robotics PASSWORD modem. i am thinking of buying one and would like to hear the pro's and con's. direct replys to me and i will copy net with anything of intrest. thnx, mike 14-Nov-83 09:18:38-MST,903;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 09:18:34-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 13 Nov 83 23:35 EST Received: From Hi-Multics.ARPA by BRL via smtp; 13 Nov 83 23:33 EST Date: 13 November 1983 22:28 cst From: Ronald W. Subject: BDS-C CDB package help? To: info-cpm@brl cc: cpm.sv I am having some difficulty in bringing up the CDB package that comes with BDS-C 1.50a. I believe that I have configured the debugger and linker per the instructions, but get very odd results when I try to debug some of the sample programs such as SIEVE.C and TAIL.C. I am using an Apple ][ with Microsoft Softcard and 56K CP/M. If anybody has some experience with CDB (especially on the Softcard), please let me know. Thanks. Ron . 14-Nov-83 09:19:39-MST,813;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 09:19:35-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Nov 83 2:20 EST Received: From Mit-Mc.ARPA by BRL via smtp; 14 Nov 83 2:12 EST Date: Mon, 14 Nov 1983 02:12 EST Message-ID: From: STRAZ%MIT-OZ@MIT-MC.ARPA To: info-cpm%MIT-OZ@MIT-MC.ARPA, pga%MIT-OZ@MIT-MC.ARPA I'm about to get a Kaypro on long term loan. It will probably come with word processing, spreadsheet, and modem software, but I'm looking for more stuff, namely, does anyone know where I can get (or at least recommend a version of) a C compiler any flavor of Lisp Logo games a 1200 baud modem (I have a 300 by DC Hayes) Thanks in advance, Steve Strassmann 14-Nov-83 09:20:50-MST,846;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 09:20:46-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Nov 83 2:55 EST Received: From Mit-Mc.ARPA by BRL via smtp; 14 Nov 83 2:51 EST Date: 14 November 1983 02:57 EST From: Jerry E. Pournelle Subject: other people running on G&G systems... To: LIN@mit-ml cc: info-cpm@brl In-reply-to: Msg of 12 Nov 1983 22:24 EST from Herb Lin MPM 8/16 will certainly be around. Compupro has got tony Pietsch working on some new BIOS materials for it, and 8/16 will be the system for the new Shirley machine at Compupro. WRITE will be available on 8/16 within weeks; I should have my copy with my Shirley next week or so. I have seen 8/16 working with Shirley and it works good. 14-Nov-83 09:22:36-MST,840;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 09:22:31-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 14 Nov 83 2:57 EST Date: 14 November 1983 03:03 EST From: Keith Petersen Subject: Hoff situation resolved To: Info-Cpm@brl-vgr Irv Hoff has had a change of mind concerning providing fully-commented source for MDM713, NCAT37, NEAT2, etc. Watch Info-Cpm for announcements about the new fully-commented files as they become available. I would appreciate it very much if people considering updating these programs would check with me first to make sure they have the latest versions and that someone else isn't already working on the next version. I keep close contact with other RCPM Sysops via the Sysop Clearinghouse RCPM. --Keith 14-Nov-83 09:26:26-MST,653;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 09:26:22-MST Received: From Sri-Unix.ARPA by BRL-VGR via smtp; 13 Nov 83 1:42 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 12 Nov 83 8:28-PST Date: 11 Nov 83 12:49:39-PST (Fri) To: info-cpm@brl From: decvax!ittvax!ittral!hinnant@ucb-vax Subject: UMODEM under VMS l s Article-I.D.: ittral.320 Does anyone know of an implementation of UMODEM (or "UC" now I suppose) that runs under VAX/VMS? Any pointers will be appreciated. Thanks, David Hinnant ITT - Telecom decvax!ittvax!ittral!hinnant 14-Nov-83 09:35:09-MST,651;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 14 Nov 83 09:35:06-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 14 Nov 83 3:18 EST Received: From Mit-Mc.ARPA by BRL via smtp; 14 Nov 83 3:09 EST Date: 14 November 1983 03:14 EST From: Jerry E. Pournelle Subject: Erroneous information from hp-pcd!craig about MARC To: lauren@rand-unix cc: INFO-CPM@brl In-reply-to: Msg of 10 Nov 1983 16:56-PST from lauren at rand-unix Sorry to hear of MARC's demise after all the expectations, but it looks as if you've made a reasonable decision. Condolances to all. 15-Nov-83 08:38:07-MST,846;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 15 Nov 83 08:38:03-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 15 Nov 83 0:04 EST Received: From Hi-Multics.ARPA by BRL via smtp; 14 Nov 83 23:38 EST Date: 14 November 1983 22:38 cst From: Ronald W. Subject: BDS CDB To: info-cpm@brl cc: LEOR@mit-mc I decided that things were behaving just too strangely last night. So, I re-did the whole works and compared what I got last night with what I just got. Seems I made a typo specifying the location of the externals for CDB2.OVL (heavy blush). Now, almost everything is pretty normal. (Still can't debug TAIL.C. It exits to the CCP before it loads in CDB2, I think.) It really looks slick!!! Quite impressed. Ron . 15-Nov-83 08:38:21-MST,558;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 15 Nov 83 08:38:18-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 15 Nov 83 0:45 EST Received: From Mit-Ml.ARPA by BRL via smtp; 15 Nov 83 0:38 EST Date: 15 November 1983 00:40 EST From: Herb Lin Subject: 8080 disassemblers... To: info-cpm@brl i asked before about cpm-80 disassemblers, and I got pointers to the ZDASM stuff. However, it seems to be runnable on z-80 only. anyone know of 8080 disassemblers? tnx.. 15-Nov-83 08:38:52-MST,1046;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 15 Nov 83 08:38:46-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 15 Nov 83 3:12 EST Received: From Sri-Unix.ARPA by BRL via smtp; 15 Nov 83 3:07 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 14 Nov 83 23:53-PST Date: 14 Nov 83 8:36:14-PST (Mon) To: info-cpm@brl From: hplabs!hao!kpno!allan@ucb-vax Subject: help for FTP please Article-I.D.: kpno.267 I am a relative newcomer to CP/M and I was very interested to see the item about public domain software on the simtel-20. The problem that I have is that I do not know what FTP is (other than it is obviously a file transfer program). Can someone tell me where I can get FTP to run on unix 4.1, or how I can access the software using KERMIT from either unix or a VMS vax. Also some information on how to use FTP would be appreciated. Thanks in advance, Peter Allan kpno!allan Kitt Peak National Observatory Tucson, Az. 15-Nov-83 08:44:11-MST,842;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 15 Nov 83 08:44:07-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 15 Nov 83 4:59 EST Received: From Cmu-Cs-A.ARPA by BRL via smtp; 15 Nov 83 4:58 EST Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 15 Nov 83 04:43:45 EST Date: 15 Nov 83 0450 EST (Tuesday) From: George.Wood@cmu-cs-a To: Herb Lin Subject: Re: 8080 disassemblers... CC: info-cpm@brl In-Reply-To: "Herb Lin's message of 15 Nov 83 00:40-EST" Message-Id: <15Nov83.045052.GW90@CMU-CS-A> I have used RESOURCE, a CPMUG disassembler by Ward Christiansen (I think); it comes in vanilla 8080 and z-80 varieties, at least one of which is called REZ.COM/ASM. It took me a while to get used to, but is quite powerful. George Wood 15-Nov-83 15:20:18-MST,845;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 15 Nov 83 15:20:12-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 15 Nov 83 16:21 EST Received: From Ucla-Locus.ARPA by BRL via smtp; 15 Nov 83 16:16 EST Date: Tue, 15 Nov 83 13:03:38 PST From: Jody Paul To: Herb Lin CC: info-cpm@brl Subject: Re: 8080 disassemblers... In-reply-to: Your message of 15 November 1983 00:40 EST The best 8080/Z80 disassembler I have ever used is called REVAS, and used to be advertised in Dr. Dobbs and similar magazines. If you are unable to locate the ads or reviews (I think it got reviewed a while back in either Dr. Dobbs or MicroSystems) send me a message and I can elaborate. --Jody Paul 15-Nov-83 19:26:05-MST,928;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 15 Nov 83 19:25:59-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 15 Nov 83 20:45 EST Received: From Rochester.ARPA by BRL via smtp; 15 Nov 83 20:41 EST Received: by sen.rochester (3.327.3N) id AA17285; 15 Nov 83 12:41:11 EST (Tue) Received: by cay.Rochester (3.327.3N+) id AA09286; 15 Nov 83 12:34:11 EST (Tue) Message-Id: <8311151741.17285@sen.rochester> Date: 15 Nov 83 12:41:11 EST (Tue) From: Mike Ciaraldi Subject: Apple Pascal--Unix file transfer To: info-cpm@brl.ARPA, net.micro.apple@Rochester.ARPA Does anyone know of programs that will do file transfer by phone or direct line between Apple II running Pascal and a VAX/Unix system? We already have umodem running (XMODEM for the VAX/Unix). Please respond directly to me. Mike Ciaraldi ciaraldi@rochester 15-Nov-83 20:10:01-MST,1512;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 15 Nov 83 20:09:56-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 15 Nov 83 21:17 EST Received: From Mit-Ml.ARPA by BRL via smtp; 15 Nov 83 21:16 EST Date: 15 November 1983 21:18 EST From: Herb Lin Subject: ummary of 8080 disassembler responses... To: info-cpm@brl Re: 8080 disassemblers... In the same directory at SIMTEL20 you'll find Ward Christensen's RESOURCE. It's an excellent 8080 disassember. --- I have used RESOURCE, a CPMUG disassembler by Ward Christiansen (I think); it comes in vanilla 8080 and z-80 varieties, at least one of which is called REZ.COM/ASM. It took me a while to get used to, but is quite powerful. --- THE THING YOU ARE LOOKING FOR IS 'RESORC' BY WARD C. IT WAS THE ROOT OF DASMZ, AND BEHAVES IN MUCH THE SAME WAY. I THINK IT IS ON SIMTEL-20. --- I agree with George Wood. I downloaded RESOURCE from MIT-MC and have used it primarily to disassemble by CBIOS. Ward Christensen's user's guide was extremely helpful in getting me started. Since my system uses a Z-80 clone, and the CBIOS was full of Z-80 opcodes, I downloaded ZDASM (which I believe is a modified version of RESOURCE) and ran it with the symbol table and control files I had built using RESOURCE. My favorite features are the ability to save the symbol table, command, and comment files and to have RESOURCE find the DBs. 16-Nov-83 11:58:59-MST,1148;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 16 Nov 83 11:58:54-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Nov 83 6:27 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 16 Nov 83 6:25 EST Date: Wed 16 Nov 83 03:27:18-PST From: Sam Hahn Subject: Diablo-compatible printers To: info-cpm@BRL.ARPA cc: info-micro@BRL.ARPA I just got a package (TechType) which manages multi-font printers, one of them being the Diablo 630 (or 630ECS). I'm almost willing to sprint for the $$$ that the Diablo will require, but first would like to know if anyone knows of Diablo 630-compatible printers that are of comparable quality. Would especially like precise page-range reverse linefeeding, incremental head movement, lots of fonts, reasonable price. Speed secondary. Have heard rumors regarding Qantex, C. Itoh, NEC 7715, Juki, Transtar, and DTC, but most of these that I've followed up on are 1610-compatible, not 630. Anyone out there had a similar interest? Be happy to let everyone know what I find -- sam [shahn@sumex] ------- 17-Nov-83 12:05:29-MST,532;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 17 Nov 83 12:05:26-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Nov 83 19:53 EST Received: From Mit-Ml.ARPA by BRL via smtp; 16 Nov 83 19:51 EST Date: 16 November 1983 19:53 EST From: Herb Lin To: info-cpm@brl hi. can someone tell me how to turn the doc files on many SIGM and CPMUG files into real ascii? To my terminal, they are just a bunch of control characters... help? tnx.. 17-Nov-83 12:05:58-MST,880;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 17 Nov 83 12:05:54-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Nov 83 21:40 EST Received: From Usc-Isid.ARPA by BRL via smtp; 16 Nov 83 21:38 EST Date: 16 Nov 1983 15:20-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: 8080 disassemblers... From: ABN.ISCAMS@usc-isid To: v.jody@ucla-locus Cc: LIN@mit-ml, info-cpm@brl Message-ID: <[USC-ISID]16-Nov-83 15:20:12.ABN.ISCAMS> In-Reply-To: The message of Tue, 15 Nov 83 13:03:38 PST from Jody Paul Roger on REVAS as a good 8080/Z80 disassembler. I use it regularly, and though the manual is not the best, I find REVAS a very useful tool (ever disassemble MBASIC?). Price is right too (forget what, but pretty reasonable). David Kirschbaum Toad Hall 17-Nov-83 12:06:14-MST,1120;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 17 Nov 83 12:06:09-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Nov 83 21:51 EST Received: From Mit-Mc.ARPA by BRL via smtp; 16 Nov 83 21:44 EST Date: 16 Nov 1983 15:49-PST Sender: ABN.ISCAMS@usc-isid From: ABN.ISCAMS@usc-isid To: STRAZ%MIT-OZ@mit-mc Cc: info-cpm%MIT-OZ@mit-mc, pga%MIT-OZ@mit-mc Message-ID: <[USC-ISID]16-Nov-83 15:49:16.ABN.ISCAMS> In-Reply-To: Steve: Suggest (if you only want to introduce yourself to C) the Small-C out in Public Domain (SIMTEL20 is, of course, the treasure trove of such things). I read again and again good things of the US Robotics line (Passport for the real cheap way to go, its big brother (forget the model) if you like shiny cases and flashing lights). Recent very good summary of modems on the net discussed these things. I have it on file if you missed it; don't want to overflow the net with it again. Please message if you want it. Regards, and good luck. David Kirschbaum Toad Hall 17-Nov-83 12:06:27-MST,1620;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 17 Nov 83 12:06:20-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Nov 83 22:33 EST Received: From Cmu-Cs-A.ARPA by BRL via smtp; 16 Nov 83 22:28 EST Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 16 Nov 83 22:14:22 EST Date: 16 Nov 83 2225 EST (Wednesday) From: George.Wood@cmu-cs-a To: Herb Lin Subject: doc files CC: info-cpm@brl In-Reply-To: "Herb Lin's message of 16 Nov 83 19:53-EST" Message-Id: <16Nov83.222506.GW90@CMU-CS-A> re: control-chars & garbage in cpmug & sigm doc files Herb; There are at least two possibilities: 1. the file is a squeezed file. if so, the middle letter in its filename extension is probably 'Q'; so blah.doc is blah.dqc. For these, use USQ.COM (I think its on one of the bds user group disks, included in both CPMUG and SIGM libraries). USQ creates an unsqueezed version of the file. If you just want to read it, and don't mind keeping the file squeezed, use TYPESQ.COM. (there is another squeezer, pack.com & unsqueezer, unpack.com, but (a) I don't know where they are, and (b) they aren't as popular as sq, usq, and typesq.) 2. the doc file was created with wordstar or some other editor using control-characters and high-bits; to get rid of high-bits, use the [z] option on pip; for file blah, try pip blah.new=blah[z] this filters off high-bits, but leaves control chars. Of course, there are other possibilities, but these are the one's I've experienced on cpmug disks. George 17-Nov-83 12:06:45-MST,2223;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 17 Nov 83 12:06:37-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Nov 83 22:34 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 16 Nov 83 22:32 EST Date: Wed 16 Nov 83 19:34:25-PST From: Sam Hahn Subject: Re: Diablo-compatible printers To: strom@BRL.ARPA cc: SHahn@SUMEX-AIM.ARPA, info-cpm@BRL.ARPA In-Reply-To: Message from "Charlie Strom (NYU) " of Wed 16 Nov 83 18:40:15-PST Charlie, I looked at CharTech also, and liked it for what it was, ie a multi- font text formatting system for dot-matrix printers. Unfortunately, I needed something that would handle the Diablo/NEC/Qume fontsets, and be able to format mathematical equations. TechType seems to fit the bill quite well, the biggest drawback being that a special character "\" (alterable) must precede characters to be printed with alternate fonts, which makes on-line editting and draft-proofing difficult in your favorite WP/editor. Techtype comes with three programs, each about 38K big. They are DRAFT, DISPLAY, and PRINT. Each are semi-customizable with a *.DAT file which sets the parameters of your terminal, draft printer, final-copy printer, etc. Cost is $300.00 (yes, Ouch!), but the capability is worth it for me, and the package is well put-together, with some fair amount of thought given to user-customizability of the software, though I wouldn't recommend it for someone without knowledge of character codes, printer head movement... ie it's not for a general user to put together for himself. Such a one should get the standard systems, either for Diablo or NEC printers. The NorthStar Advantage is capable of displaying close-to-copy text, due to its graphics capabilities (or so I'm told by the Raabs', the authors). The package has been regularly advertised in MicroSystems the last couple of months. Green Mountain Radio Research Company 240 Staniford Road Burlington, Vermont 05401 (802) 862-0997 Fred and Rebecca Raab were very helpful and patient with my many questions. -- sam hahn [shahn@sumex] ------- 17-Nov-83 12:07:05-MST,832;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 17 Nov 83 12:07:01-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Nov 83 22:44 EST Date: Wed, 16 Nov 83 22:38:05 EST From: Rick Conn To: decvax!ittvax!ittral!hinnant@ucb-vax cc: info-cpm@brl Subject: Re: UMODEM under VMS l s David, Yes, there is a program called XMODEM.FOR (requiring another file called QIO.DCK) which runs nicely under VAX VMS (I have it up and running locally). It does not have all of the features of UC, but it DOES provide the MODEM2 protocol and VMS-to-CP/M text file conversion. The programs (XMODEM and other helpful utilities) are on SIMTEL20. Drop me a line if you need more help (no quick reply guaranteed at this time, tho). Rick 17-Nov-83 12:07:17-MST,1143;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 17 Nov 83 12:07:12-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 16 Nov 83 22:56 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 16 Nov 83 22:55 EST Date: Wed 16 Nov 83 19:56:06-PST From: Sam Hahn Subject: Re: ?looking for a minimal (small?) Lisp interpreter written in Pascal To: decvax!tektronix!tekig1!dont@UCB-VAX.ARPA cc: SHahn@SUMEX-AIM.ARPA, info-cpm@BRL.ARPA, info-micro@BRL.ARPA In-Reply-To: Message from "decvax!tektronix!tekig1!dont@ucb-vax" of Sun 13 Nov 83 23:38:12-PST I've got a machine-readable 8" SSSD disk with the UCRL-52417 LISP.PAS file on it. Looks well-commented, but haven't yet played around with it enough to recommend one way or another. For postage donations (and a blank disk), I'd offer to distribute it, but I'm going to see if that's ok with Taylor and Cox first (it's available from NTIS), though they specify right in the file that the code is in the public domain. File's about 36K of code and comments. -- sam hahn [shahn@sumex] ------- 17-Nov-83 12:08:06-MST,808;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 17 Nov 83 12:07:52-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 17 Nov 83 5:15 EST Received: From Mit-Mc.ARPA by BRL via smtp; 17 Nov 83 5:04 EST Date: 17 November 1983 05:10 EST From: Jerry E. Pournelle Subject: Reply to:Re: Call for Osborne Executive owners To: jalbers@bnl cc: info-cpm@brl, info-micro@brl, dag@ucbarpa In-reply-to: Msg of 27-Oct-83 13:52:33-EDT from jalbers at bnl I think I am confused. It's OK to advertise one's car for sale, or an apartment for sub-lease, but not to offer to trade software? Are there indeed rules to the use of these nets, or is t here a sort of concensus, or do we simply have self-appointed proctors, or what? 17-Nov-83 12:09:09-MST,1002;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 17 Nov 83 12:09:04-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 17 Nov 83 9:40 EST Received: From Sri-Unix.ARPA by BRL via smtp; 17 Nov 83 9:35 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 17 Nov 83 6:23-PST Date: 15 Nov 83 8:50:36-PST (Tue) To: info-cpm@brl From: hplabs!intelca!omsvax!ogcvax!tektronix!azure!michaelk@ucb-vax Subject: CP/M PLUS Article-I.D.: azure.2344 Does anyone know what bugs were fixed when DRI went from 3.0 to 3.1 ? My banked cpm plus (256K RAM) works OK functionally, but, doesn't seem to provide the disk speed improvement anticipated. It seems to flush read-buffers too much, and seems to do directory checksums rather often even though the floppies are marked non-removeable. Any ideas? I use DSDD 8" (1.2MB) drives w/512 byte sectors. This is a personal project, not one of my employer. Mike Kersenbrock Aloha, Oregon 17-Nov-83 15:38:06-MST,926;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 17 Nov 83 15:38:02-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 17 Nov 83 17:04 EST Received: From Mit-Mc.ARPA by BRL via smtp; 17 Nov 83 16:57 EST Date: 17 November 1983 17:02 EST From: Gail Zacharias Subject: 8-bit ascii files on pdp-10's To: LIN@mit-ml cc: info-cpm@brl In-reply-to: Msg of 16 Nov 1983 19:53 EST from Herb Lin Date: 16 November 1983 19:53 EST From: Herb Lin hi. can someone tell me how to turn the doc files on many SIGM and CPMUG files into real ascii? To my terminal, they are just a bunch of control characters... On ITS, :TYPE8 will type out such a file. The equivalent program for TOPS-20 can be found on MIT-MC in "AR7:GZ;TYPE8 >" (FTP it to TYPE8.MID and do @MIDAS TYPE8 to make a TYPE8.EXE). 17-Nov-83 18:27:09-MST,730;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 17 Nov 83 18:27:05-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 17 Nov 83 19:47 EST Date: 17 Nov 1983 17:42 MST (Thu) Message-ID: From: "Frank J. Wancho" To: INFO-CPM@brl-vgr Subject: New CRC Lists Thanks to Gail Zacharias for a special version of the CRC program which enabled to quickly build CRC files in the new one-liner format. The results of that effort are now in MICRO:dir.CRCLST on the SIMTEL20. (Substitute CPM, SIGM, CPMUG for dir above to get the list corresponding to the subdirectories in that particular directory.) --Frank 18-Nov-83 10:49:38-MST,933;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 18 Nov 83 10:49:31-MST Received: From Rand-Unix.ARPA by BRL-VGR via smtp; 18 Nov 83 2:07 EST Date: Thursday, 17 Nov 1983 23:05-PST To: info-micro@brl-vgr, info-cpm@brl-vgr Subject: Info Wanted on Micro DBMS's From: edhall@rand-unix I'm interested in hearing about people's experiences with Data Base Management Systems under CP/M. I have experience with dBase II, which is OK, but has a few minor bugs and some restrictions (such as only being able to work with two relations at once). Various magazines have reviewed these programs from time-to-time, but I'm more interested in experiences and actual applications, especially from people who have worked with more than one system. I'll post a summary of replies. Thanks, -Ed Hall edhall@rand-unix (ARPA) decvax!randvax!edhall (UUCP) 18-Nov-83 10:51:13-MST,607;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 18 Nov 83 10:51:09-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 18 Nov 83 6:23 EST Received: From Mit-Mc.ARPA by BRL via smtp; 18 Nov 83 6:18 EST Date: 18 November 1983 06:24 EST From: Jerry E. Pournelle Subject: STEAL THIS BOOK To: DJB%mit-oz@BRL.ARPA cc: INFO-CPM@mit-mc In-reply-to: Msg of Thu 17 Nov 83 14:47:36-EST from Dave Braunegg Of course what one should do is steal the book, but rip off the cover and LEAVE THAT BEHIND. 18-Nov-83 10:51:53-MST,2666;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 18 Nov 83 10:51:44-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 18 Nov 83 6:43 EST Received: From Sri-Unix.ARPA by BRL via smtp; 18 Nov 83 6:35 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 18 Nov 83 3:26-PST Date: 15 Nov 83 16:14:49-PST (Tue) To: info-cpm@brl From: decvax!wivax!linus!philabs!aecom!glen@ucb-vax Subject: The best of UNIX for CP/M Article-I.D.: aecom.250 YOU'LL BE AMAZED At What Your CP/M Micro Can Do Now!! ConIX can give your system the kind of power and flexibility that UNIX users have been raving about, AND SO MUCH MORE! Wouldn't you love to have a UNIX system at home? Has the price kept you back? If you have an 8-bit CP/M micro, you can enjoy many of the best features of UNIX and a wide range of other improvements available with the ConIX Operating System. Features include: * I/O Redirection and Pipes * Path Searching * Improved User Area Access * True CP/M Compatibility - runs with CP/M! * Memory Management - brings ConIX down to only 1/2K memory when programs execute. You won't have any memory crunch! * Multiple Commands Per Command Line * Full Upper/Lower Case and Argument Parsing ("", \, etc.) * "Shell" Storage and Argument Variables * Total User Memory Control - you can redirect right into memory! * Programmable Function Keys * Automatic Screen Paging * Virtual Floppy Disk System * Print Spooler * Interpreted Command Language (for "Shell" programming) Including: while, if, switch, goto, gosub, trap, onint * Over 100 Built-In Utilities and Option Settings * Integer Expression Analyzer with String and Numeric Comparison * Expanded Operating System Call Interface * Archive Manager For Compacting Files - saves over 50% storage! * On-Line Manual System What's even more amazing is the price: ONLY $135 for the most incredible building-block ever designed for an 8-bit CP/M system! Interested? It costs you nothing to get more information and a complete descriptive brochure! Reply directly (electronically), call, or write: Computer Helper Industries Inc. Post Office Box 680 Parkchester Station Bx., N.Y. 10462 Tel. (212) 597-3559 9AM - 8PM Please send your name, (UUCP address) and U.S. Postal Info. - E N J O Y - Glen Marianko CHI Inc. {philabs,esquire,cucard}!aecom!glen - - - - - UNIX: TM Bell Labs; CP/M: TM Digital Research; ConIX: TM Computer Helper Industries Inc. 18-Nov-83 11:21:26-MST,581;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 18 Nov 83 11:21:22-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 18 Nov 83 11:50 EST Received: From Nosc-Cc.ARPA by BRL via smtp; 18 Nov 83 11:38 EST Date: 18 Nov 1983 08:28:25-PST From: Jim Gilbreath Reply-to: CCVAX.gil@nosc To: decvax!wivax!linus!philabs!aecom!glen@ucb-vax, info-cpm@brl Subject: Re: The best of UNIX for CP/M Yes, I am interested. Please send info to Jim Gilbreath Code 91 NOSC San Diego, CA 92152 thanx -gil 18-Nov-83 12:33:11-MST,971;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 18 Nov 83 12:33:01-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 18 Nov 83 13:41 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 18 Nov 83 13:27 EST From: ssalzman.es@PARC-MAXC.ARPA Date: 18 Nov 83 9:10:40 PST Subject: Re: The best of UNIX for CP/M In-reply-to: decvax!wivax!linus!philabs!aecom!glen@ucb-vax.ARPA's message of 15 Nov 83 16:14:49 PST (Tue) To: decvax!wivax!linus!philabs!aecom!glen@ucb-vax.ARPA cc: info-cpm@brl.ARPA Wow. That sound a little too good to be true. I have an 820-II. Is there a massive configuration for this system? Any special hardware requirements, how much disk space do the utilities take up??? Send me all the info you've got. You can mail to: Isaac Salzman 5667 Corteen Pl. North Hollywood, CA 91607 (213)984-1478 or reply to Ssalzman.es@PARC-MAXC or sdcrdcf!csun!op-ijs@ucla-security 18-Nov-83 14:12:55-MST,3475;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 18 Nov 83 14:12:42-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 18 Nov 83 15:27 EST Date: Fri, 18 Nov 83 15:19:08 EST From: Keith Petersen To: Info-Cpm@brl-vgr Subject: RMACPAT.ASM - Improving RMAC ;**************************************************************** ; ; Patches for MAC and RMAC ; ------------------------ ; ; by George Blat ; Blat, Research + Development Corp. ; 8016 188th SW ; Edmonds, WA 98020 ; ; ;**************************************************************** ; ; ;The following changes are (c)1983 Blat R+D Corp. Permission is ;granted to use these patches only in non-commercial applications. ;MAC and RMAC are trademarks of Digital Research, Inc. which holds ;ownership and all rights to the original programs. ; ;**************************************************************** ; ; ;Mac and Rmac are two reliable assemblers developed by Digital ;Research which have a good number of useful features. It seems ;natural to get the most out of them. ; ;Among the features that can be added to Mac and Rmac, are the ;ability to use the period '.' and the underscore '_' as part of ;symbol names such as labels, even as first character of the ;symbol. The underscore, for instance, makes a much better word ;separator than the dollar '$' sign when used in a multi-word ;label. In a dense program listing, it's certainly easier to find ;STAT_PORT than STAT$PORT, and @hl_to_de than @hl$to$de. ; ;By the same token, I don't agree with the decision of Digital ;Research of making the dollar sign a don't care character. It ;introduces confusion as it allows symbols that don't look the ;same to be equivalent. ; ;In addition, RMAC can be easily patched to create .REL files ;where the global (external) names have up to 7 active characters. ;This helps by allowing you to create more meaningful symbol names ;and therefore improve program legibility. This change is still ;entirely compatible with the industry standard Microsoft format. ; ;The following patches should be assembled with MAC (not RMAC) ;and the resulting hex file should be applied over the original ;programs with DDT, SID or ZSID. KEEP AN ARCHIVE COPY OF THE ;ORIGINAL MAC OR RMAC BEFORE PATCHING. FALSE EQU 0 TRUE EQU NOT FALSE RMAC EQU TRUE ;select one and only one of these MAC EQU FALSE ;true IF RMAC GLOBAL7 EQU TRUE ;set to false if you don't want ;7 char globals PATCHAREA EQU 13BH DOLLARCOUNTS EQU 1D7AH ;set this to false if you like to ;keep the dollar as a don't care char CHECKALFA EQU 1D9CH TOUP EQU 2844H ENDIF IF MAC COPYRITE EQU 103H ;shorten but keep the copyright notice DOLLARCOUNTS EQU 1834H CHECKALFA EQU 1853H ENDIF IF MAC ORG COPYRITE DB '(c)1977 DRI' PATCHAREA: ENDIF IF RMAC ORG PATCHAREA ENDIF CPI '.' RZ CPI '_' RZ CPI '?' RZ CPI '@' RZ IF RMAC CALL TOUP ENDIF SUI 'A' CPI 'Z'-'A'+1 CMC RET IF RMAC AND GLOBAL7 COMPARE EQU 12D6H SETIT7 EQU 12DBH ORG COMPARE CPI 8 ;replaces cpi 7 ORG SETIT7 MVI A,7 ;replaces mvi a,6 ENDIF IF DOLLARCOUNTS ORG DOLLARCOUNTS NOP ;replaces mov m,a ENDIF ORG CHECKALFA CALL PATCHAREA ;replaces cpi 3f CMC ;jz 1db1 SBB A ;cpi 40 RET ;jz 1db1, etc. END 18-Nov-83 17:21:55-MST,1340;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 18 Nov 83 17:21:45-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 18 Nov 83 18:57 EST Date: Fri 18 Nov 83 16:56:57-MST From: Rick Conn Subject: VAX/VMS XMODEM File Transfer Programs To: info-cpm@BRL-VGR.ARPA cc: rconn@SIMTEL20.ARPA The programs I spoke of the other day which make up a set of file transfer programs which run under VAX/VMS are stored on SIMTEL20 in MICRO:. The following is a display of this directory: MICRO: CPM.COM.1 FMXMOD.FOR.1 QIO.DCK.1 TOXMOD.FOR.1 XMODEM.FOR.1 .FORDOC.1 .HLP.1 The TOXMOD and FMXMOD programs convert from VAX/VMS text file format to CP/M format and back, resp. XMODEM itself automatically handles this if you tell it you are transferring text files. The file CPM.COM is a VAX/VMS command file which establishes the command names for the transfer (such as XMODEM or X to invoke the program in general interactive mode, SEND to simply send text files, and RECV to simply receive text files). I have my LOGIN.COM file automatically execute CPM.COM to give me these commands. You will probably have to modify CPM.COM to indicate the directories you chose to store the programs in. Rick ------- 21-Nov-83 09:24:22-MST,937;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 09:24:17-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 21 Nov 83 3:18 EST Received: From Sri-Unix.ARPA by BRL via smtp; 21 Nov 83 3:14 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 21 Nov 83 0:08-PST Date: 18 Nov 83 12:32:31-PST (Fri) To: info-cpm@brl From: pur-ee!CS-Mordred!Pucc-H.ab3@ucb-vax Subject: Re: The best of UNIX for CP/M Article-I.D.: pucc-h.371 In-Reply-To: Article <250@aecom.UUCP> I can't believe you actually posted this to the net. It is the most blatant use of a (supposedly) non-profit network for commercial purposes that I've seen yet. Be assured that if your product is mentioned in a conversation to which I am party to, this posting will also be mentioned. -- Darth Wombat { allegra, ihnp4, decvax, harpo, seismo, teklabs, ucbvax } !pur-ee!rsk 21-Nov-83 11:17:09-MST,1006;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 11:17:04-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 21 Nov 83 5:53 EST Received: From Sri-Unix.ARPA by BRL via smtp; 21 Nov 83 5:50 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 21 Nov 83 2:42-PST Date: 25 Nov 83 2:18:55-EST (Fri) To: info-cpm@brl From: hplabs!intelca!omsvax!ogcvax!tektronix!billr@ucb-vax Subject: Re: Kaypro S/W Article-I.D.: tektroni.1596 Microcornucopia, a magazine devoted to single board computers (in particular, the Kaypro, Big Board I & II, Xerox 820) has a library of software for the Kaypro. There are several disks that include such goodies as MDM712, Small C Ver. 2, XLISP, games and utilities. The disks are reasonable priced (I don't remember the exact amount) and are free if you contribute some S/W or an article (and blank floppy). Contact: Microcornucopia PO Box 223 Bend OR 97709 (503) 382-8048 21-Nov-83 11:42:05-MST,760;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 11:41:57-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 18 Nov 83 19:51 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 18 Nov 83 19:48 EST Date: 18 Nov 83 15:48:33 PST (Friday) From: Duncan.es@PARC-MAXC.ARPA Subject: Re: The best of UNIX for CP/M In-reply-to: decvax!wivax!linus!philabs!aecom!glen's message of 15 Nov 83 16:14:49 PST (Tue) To: decvax!wivax!linus!philabs!aecom!glen@ucb-vax.ARPA cc: info-cpm@brl.ARPA, Duncan.es@PARC-MAXC.ARPA Yes I am interested. Please send info to following address: Donald K. Duncan Xerox Corporation 701 S. Aviation Blvd. El. Segundo, Ca 90245 tnx 21-Nov-83 11:55:17-MST,839;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 11:55:13-MST Received: From Amsaa.ARPA by BRL-VGR via smtp; 19 Nov 83 10:03 EST Date: Tue, 15 Nov 83 15:31:28 EST From: David Towson (CSD) To: Frank J. Wancho cc: INFO-CPM@brl-vgr Subject: Re: New CPM.DIRLST Frank - I just printed a copy of the new cpm.dirlst, and I just want to say thank you thank you thank you thank you... I'm sure it took a lot of work to put that thing together, but it was worth it. Having the CRC's is really helpful, as is knowing without ambiguity which files are ASCII and which are binary. (Not all files listed with "byte" length 36 in the former directory are in binary - archives, for example.) Best regards, Dave 21-Nov-83 11:57:15-MST,575;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 11:57:11-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 19 Nov 83 10:36 EST Received: From Amsaa.ARPA by BRL via smtp; 19 Nov 83 10:27 EST Date: Thu, 17 Nov 83 9:33:25 EST From: David Towson (CSD) To: Herb Lin cc: info-cpm@brl Herb - ALL files in both the SIGM and CPMUG archives are stored in ITS binary format. Just move 'em as though they were COM files, and all will be fine. Dave 21-Nov-83 11:58:43-MST,847;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 11:58:39-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 19 Nov 83 10:47 EST Received: From Sri-Unix.ARPA by BRL via smtp; 19 Nov 83 10:45 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 19 Nov 83 7:40-PST Date: 17 Nov 83 16:33:41-PST (Thu) To: info-cpm@brl From: harpo!floyd!cmcl2!lanl-a!bb@ucb-vax Subject: CRC-16 algorithms in net.sources Article-I.D.: lanl-a.3869 =============================================== The number of requests for these algorithms (C and 8086 assembler) is great enough, so I put them there instead of sending to each one of you. If you don't get net.sources, or miss it somehow, I will send you a copy directly. b2 {ucbvax!lbl-csam,purdue,cmcl2}!lanl-a!bb@LANL 21-Nov-83 11:59:46-MST,867;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 11:59:42-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 19 Nov 83 11:28 EST Received: From Sri-Unix.ARPA by BRL via smtp; 19 Nov 83 11:21 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 19 Nov 83 8:09-PST Date: 17 Nov 83 12:23:31-PST (Thu) To: info-cpm@brl From: harpo!floyd!clyde!akgua!emory!gatech!skip@ucb-vax Subject: Re: The best of UNIX for CP/M Article-I.D.: gatech.2190 In-Reply-To: Article <250@aecom.UUCP> Am I mistaken, or are commercials not allowed on USENET? -- from the DMZ of Skip Addison The Office of Telecommunications and Networking Georgia Tech, Atlanta GA 30332 CSNet: Skip @ GATech ARPA: Skip.GATech @ UDel-Relay uucp: ...!{akgua,allegra,rlgvax,sb1,unmvax,ut-ngp,ut-sally}!gatech!skip 21-Nov-83 12:01:08-MST,1028;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 12:01:04-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 19 Nov 83 11:59 EST Received: From Sri-Unix.ARPA by BRL via smtp; 19 Nov 83 11:55 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 19 Nov 83 8:43-PST Date: 17 Nov 83 18:53:18-PST (Thu) To: info-cpm@brl From: decvax!microsoft!uw-beaver!ssc-vax!david@ucb-vax Subject: CP/M Ada implementations Article-I.D.: ssc-vax.624 I submitted this once to net.lang.ada and got no response, so I will try one time here. I am looking for comments on Ada compilers available for CP/M (I know of three): SuperSoft Janus Augusta In particular, what you like/don't like about an implementation, what made you decide to purchase one over the others, worst feature/best feature, and any other comments. Please send via mail (or post news if it is of general interest). Thanks. -- Dave Norris -- ...!uw-beaver!ssc-vax!david 21-Nov-83 12:06:20-MST,3069;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 12:06:12-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 19 Nov 83 18:09 EST Date: 19 November 1983 18:15 EST From: Keith Petersen Subject: SD-77 now available To: Info-Cpm@brl-vgr The latest version of SD is now available on SIMTEL20 as: MICRO:SD.77ASM (source code) SD.77COM (COM file stored in ITS binary format) SD.77DOC (complete documentation) SD.77INF (short description of features) SD-77 works automatically with any number of disk drives, up to 16. If a disk has been left out of a drive, the program passes that drive and continues. It can be intentionally set to work with a specified number of drives, however. SUMMARY OF OPTIONS: B>SD $U4ADL (etc.) A - All user areas allowed, usually 0-15, less on RCPM systems C - Clear screen (if activated for your CRT) D - All disks starting with 1st available (usually A:) F - Makes a file called DISKMENU.DIR automatically L - Library list option N - No pagination, keeps scrolling if more than one full page P - Printer option - lists to printer R - Reset disk (perhaps a new one installed) S - Shows system files (otherwise doesn't) V - Shows date, version number U8 - Start with user 8 Using the $D option now automatically starts on the 1st available drive (usually A:) drive regardless what drive you were on when you started. It then checks all available drives. Similiarly, using the $A option will now always start with User 0, unless entered as $UnA - where n is a valid user number above zero. The most significant improvement concerns the ability of SD to search a range of drives (and/or user areas) for a specified file. This capability is patterned after FILE.COM. Using the D option automatically starts searching on drive A and all subse- sequent available drives, no matter what drive was in use. Additionally, using the A option will start the search in user area 0, even if the current user area is higher. Any number of drives may be used without resetting any part of the program. If a disk is not inserted in a particular drive the program passes that drive and continues checking the rest of the available drives. Files may be shown in vertical or horizontal listings, although this must be set when the program is assembled for a particular system. SD-77 has support for .LBR files, (an "L" option to list their member files); and support for the NZCPR/ZCPR2 "WHEEL" byte option. (SD-77.COM set up for ZCPR2 use with WHEEL at 3EH.) Size of library member files are shown in 'k'. Note that you don't really have to be running NZCPR or ZCPR2 to use the wheel byte feature, just get the WHEEL program and add code to BYE to make sure WHEEL byte is cleared when a remote user logs on, (before entering CP/M). 21-Nov-83 12:06:34-MST,1390;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 12:06:29-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 19 Nov 83 18:14 EST Date: 19 November 1983 18:19 EST From: Keith Petersen Subject: Digital Research: CPM+ Application Note 01 To: Info-Cpm@brl-vgr CP/M Plus (CP/M Release 3.0) Application Note 01 (revision of: RMAC R1.1 Application Note 01) INCLUDING LOCAL SYMBOLS OF RMAC Applicable products and version numbers: CP/M Plus, RMAC, LIB-80, and LINK-80 Install the following patch to RMAC.COM to include local symbols and publics in the object file produced by RMAC. Local symbols and publics are also included in the SYM file produced by LINK. Make a back-up copy of RMAC.COM before using DDT to make the following changes: A>ren rmac.sav=rmac.com A>sid rmac.sav NEXT MSZE PC END 3600 3600 0100 D4FF #s1167 1167 08 18 1168 32 . #wrmac.com 006Ah record(s) written. #g0 A> Licensed users are granted the right to include these changes in CP/M Plus software. 21-Nov-83 12:08:45-MST,1118;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 12:08:40-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 19 Nov 83 23:02 EST Received: From Usc-Isid.ARPA by BRL via smtp; 19 Nov 83 22:56 EST Date: 19 Nov 1983 10:56-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: The best of UNIX for CP/M From: ABN.ISCAMS@usc-isid To: harpo!floyd!clyde!akgua!emory!gatech!skip@ucb-vax Cc: info-cpm@brl Message-ID: <[USC-ISID]19-Nov-83 10:56:10.ABN.ISCAMS> In-Reply-To: The message of 17 Nov 83 12:23:31-PST (Thu) from harpo!floyd!clyde!akgua!emory!gatech!skip@ucb-vax Skip et al: Hokay, so maybe that one UNIX-like ad was a commercial pure and simple (no, I didn't send it) -- but it WAS extremely timely and QUITE informative for me since I had just read someone's discussion of another UNIX-like system. I kind of figured that one the exception to the rule -- but I FULLY agree with no commercialization. Sure would hate to see some Madison Avenue-type flunkey dumping into INFO-MICRO and the other nets. David Kirschbaum Toad Hall 21-Nov-83 12:17:56-MST,834;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 12:17:52-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Nov 83 17:13 EST Received: From Cmu-Cs-A.ARPA by BRL via smtp; 20 Nov 83 16:54 EST Received: from [128.2.254.192] by CMU-CS-PT with CMUFTP; 20 Nov 83 16:39:28 EST Date: 20 Nov 83 1651 EST (Sunday) From: George.Wood@cmu-cs-a To: Keith Petersen Subject: Re: SD-77 now available CC: info-cpm@brl In-Reply-To: "Keith Petersen's message of 19 Nov 83 18:15-EST" Message-Id: <20Nov83.165136.GW90@CMU-CS-A> Keith; I noticed an option to sd-77 to get date,version number; how can this be done? does it require zcpr? Which is more recent/better tested/ appropriate for z80s, NZCPR or ZCPR2? What's the difference? George 21-Nov-83 12:20:53-MST,1168;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 12:20:46-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 20 Nov 83 20:50 EST Date: 20 November 1983 20:55 EST From: Keith Petersen Subject: SD-77 now available To: George.Wood@cmu-cs-a cc: Info-Cpm@brl-vgr In-reply-to: Msg of 20 Nov 83 1651 EST () from George.Wood at CMU-CS-A The date,version number option in SD-77 refers to SD's creation date and version number. If I recall correctly it's the V option. The most recent ZCPR is ZCPR2. The latest versions are available via FTP from SIMTEL20. ZCPR 1.0 (the original) is also available there and MAY be a better choice for a small floppy disk system since it does not require any .COM files to support it. In a RCPM (Remote CP/M) environment disk space may dictate your choice. There is little need to go to "NZCPR" because you can easily change the built-in commands of ZCPR to whatever you want. NZCPR is NOT supported by the CCP-GROUP. If you have specific questions about either version of ZCPR, Rick Conn is the one to contact. --Keith 21-Nov-83 12:22:10-MST,3218;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 12:22:00-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 20 Nov 83 20:54 EST Date: 20 November 1983 20:59 EST From: Keith Petersen Subject: Speeding up the Kaypro-2 To: Info-Cpm@brl-vgr The following is forwaded from my RCPM: --- >>>The Following originally appeared in the "the kaypro column", Microcornucopia, PO Box 223, Bend, OR 97709, by Dave Thompson. Enjoy>>>Ben Peirce, Venice Beach>>> >>>Speeding things up (from Micro C, June '83)>>> The Kaypro can easily be converted from 2.5 to 5 MHz with just a few jumpers, a faster CPU (Z80B), a new monitor ROM, and a SPDT switch! Replace your Z80A CPU with a 6 MHz Z80B CPU (about $13.00 from: JDR Microdevices, 1224 A. Bascom Ave., San Jose, CA 95128, 1/800/538-5000 or 1/800/662-6279 ). Also replace your monitor ROM (marked with a white label as 81-149) with a new monitor ROM capable of 5 MHz operation without overheating. You may not have to replace the monitor ROM chip (#2716) if your original can run at 5.0 MHz without heating up and getting silly. Barry Cole told me that lots of "2716's" can run that fast without problems, but mine sure couldn't! (For about $29.00 from Micro C, PO Box 223, Bend, OR 97709, 1/503/382-8048, you can get one that can take the heat. It also replaces the flashing cursor with a solid one.) . Remove U87 (75lS390). Cut pin 9 (or bend it out) also bend out pin 1. Jumper pin 1 to pin 6. Jumper pin 12 to pin 15. Put the 74lS390 back in it's socket, making sure the pin 1 and pin 9 aren't making contact with anything. Unplug U66 (74164) and bend out pins 4 and 5 so they won't go back into the socket. Put U66 back in it's socket and connect the trace that used to go to pin 4 to the trace that goes to pin 3 and connect the trace that used to go to pin 5 to pin 4. Unplug U86 (74LS293) and bend out pins 4 and 5 ( 2.5 MHz and 5 MHz clocks, respectively). Connect a lead from each of these pins to either side of a small SPDT (single pole/double throw) switch. Connect the center of the switch to the forward end of R26 (the end of resistor R26 that's nearest the front of the Kaypro), so that you will be able to select between the 2.5 MHz and 5 MHz clock speeds. You can mount the switch quite easily in one of the ventilation slotes on the back. The slots are just the right width for the small toggle variety so you don't need to modify the cabinet at all. The early versions of disk format and copy programs don't work with the faster clock. So you may need to slow the system down once in a while. You will usually need to do a hardware reset when you change speeds since the glitch usually sends the system out to pasture! --end-- 21-Nov-83 12:29:44-MST,978;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 12:29:39-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 20 Nov 83 23:07 EST Received: From Hi-Multics.ARPA by BRL via smtp; 20 Nov 83 23:03 EST Date: 20 November 1983 21:58 cst From: Weinstein.ALWT@hi-multics Subject: 5 MB Hard Discs To: info-micro@brl cc: Weinstein.ALWT@hi-multics, info-trs80@brl, info-cpm@brl Acknowledge-To: Weinstein.ALWT at HI-MULTICS I have a few SEAGATE ST-506 5mb 5.25" Hard Discs that I can sell for $375.00 they are new, tested, and error free. I bought a group to get a price break on the SEAGATES rather than the Tandoms that I was able to get before. Anyone interested.. let me know.. helping people get hard discs cheap takes time and since I am going to finish up my masters degree.. I may not be able to get any more hard discs for a while..so if you want one speak up NOW! Dennis 612-425-1813 21-Nov-83 12:36:04-MST,1686;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 21 Nov 83 12:35:56-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 21 Nov 83 0:28 EST Date: Mon, 21 Nov 83 0:21:35 EST From: Rick Conn To: info-cpm@brl cc: info-micro@brl Subject: The New ZCPR - ZCPR3 Work is beginning on the creation of ZCPR3, and I would like to poll the user community to determine their feelings on a few points. Please respond to those questions you feel strongly about or have definite input for. Lack of response to a yes/no question will be assumed to mean No. 1. [Fill in the Blank] Please provide details on any ZCPR2 utility which exhibits a definite bug. Please describe the nature of the bug, the sequence of operations or commands which cause it, and enough information to ensure that it can be duplicated by someone who is trying to identify and correct the bug. 2. [Yes/No] Does anyone mind if the disk-based named directory facility is removed? Memory-based (as an option) named directories will be retained in ZCPR3, but the value of the disk-based named directory facility is being questioned in lieu of the cost in terms of the added size of the utilities. 3. [Yes/No] Does anyone object to the removal of the disk-based command file facility? This would mean that SUB2/SUBMIT will no longer work, and the memory-based ZEX command file processor will be the only command file facility which can be used. A prompt reply will be appreciated. Thank you. Rick 22-Nov-83 12:01:22-MST,1167;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 22 Nov 83 12:01:18-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 22 Nov 83 11:32 EST Received: From Usc-Isid.ARPA by BRL via smtp; 22 Nov 83 11:10 EST Date: 21 Nov 1983 16:48-PST Sender: ABN.ISCAMS@usc-isid Subject: Linkers From: ABN.ISCAMS@usc-isid To: INFO-CPM@brl Cc: ABN.ISCAMS@usc-isid Message-ID: <[USC-ISID]21-Nov-83 16:48:43.ABN.ISCAMS> NetLand: I'm trying to do a little beginner work in C, and run directly into a requirement to link programs together. I poked around in SIMTEL20 MICRO: and found L2, but find I need a linker to assemble L2 and its other two necessary programs. I keep running into this problem in CP/M too -- and my question is* is there any way to link programs together WITHOUT a linker? You see, I don't really understand everything a linker does. If it's just a matter of concatenating files -- heck, lots of ways to do that. If it reconciles/adjusts all addresses between the linked programs... that ain't so easy to do! Help/information/education, please. David Kirschbaum Toad Hall 22-Nov-83 12:01:32-MST,804;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 22 Nov 83 12:01:28-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 22 Nov 83 11:31 EST Received: From Sri-Unix.ARPA by BRL via smtp; 22 Nov 83 11:08 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 22 Nov 83 4:11-PST Date: 20 Nov 83 20:03:34-PST (Sun) To: info-cpm@brl From: ihnp4!houxm!hogpc!houti!ariel!vax135!cornell!uw-beaver!ssc-vax!schneids@ucb-vax Subject: Re: best UNIX for cpm Article-I.D.: ssc-vax.627 Yes I'm interested. Please send me info: !ssc-vax!schneids or Schneids 11802-1st Ave. S. Apt. 4 Seattle, Wash. 98168 p.s. - Those of you bitching about advertising on the net STICK IT IN YOUR EAR!!!!!!!!!!!!!!!!!!!!!!!! 22-Nov-83 14:15:20-MST,1477;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 22 Nov 83 14:15:15-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 22 Nov 83 11:50 EST Received: From Ucb-Vax.ARPA by BRL via smtp; 22 Nov 83 11:38 EST Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.21/4.15) id AA15530; Mon, 21 Nov 83 22:01:13 pst Received: by ucbarpa.ARPA (4.16/4.13) id AA03435; Mon, 21 Nov 83 22:01:23 pst Date: Mon, 21 Nov 83 22:01:23 pst From: David Allen Gewirtz Message-Id: <8311220601.AA03435@ucbarpa.ARPA> To: info-cpm@brl, info-ibmpc@usc-isib Subject: PC<->UNIX I am looking for an IBM PC to UNIX file transfer facility. It is my understanding that KERMIT and possible UMODEM will accomplish text and binary transfers in both environments. The problem is not what is available, but how to get it on my machines. I would greatly appreciate it if someone would be kind enough to make me a disk with source and object of KERMIT (or UMODEM) for the PC and a VAX tar tape with source and object for UNIX (system V or 4.1) and get them to me. I would be more than happy to reimburse you for the cost of mailing and media. If anyone can do this, please call me at 415-653-6957 after 8pm PST or 415-965-7200 during working hours. If you are going to be at COMDEX, please stop by the Pyramid Technology booth and ask for me. I thank you in advance for your help. David Gewirtz 22-Nov-83 15:09:03-MST,4030;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 22 Nov 83 15:08:42-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 22 Nov 83 11:50 EST Received: From Usc-Isid.ARPA by BRL via smtp; 22 Nov 83 11:43 EST Date: 21 Nov 1983 10:29-PST Sender: ABN.ISCAMS@usc-isid Subject: Transformers and European Current From: ABN.ISCAMS@usc-isid To: INFO-CPM@brl Cc: ABN.ISCAMS@usc-isid Message-ID: <[USC-ISID]21-Nov-83 10:29:29.ABN.ISCAMS> Netland: My organization has been using some big heavy lunkers of Solas "constant voltage" transformers for years now to stabilize some of the horrible AC current we get under field conditions (Army generators, long cables running through mud, strangers hanging coffee pots and arc welders off the line, etc.) They've worked just fine with the usual 110V AC (+/- 20 volts), and also worked fine when I grabbed some three-phase 220. (Had to jumper them up internally for the 220-110 conversion, but they're designed for that.) Problem: Went to Germany. Took the good old Solas's along (they convert 220 to 110, don't they?). Plugged in (appropriately jumpered to 220>110 conversion). Got a beautiful, steady spikeless 96 volts! Huh! Found an already-transformered 110 wall plug. Rejumpered friend Solas, now 110>110 range. Plugged in. Got a beautiful, steady spikeless 96 volts! Reinvented the theory of AC transformers, and I need some feedback from you real electrical/electronics types out there (I'm a mere SF weapons man). I propose the core of a transformer vibrates from the AC cycles, or in some way creates a cyclic magnetic field. This magnetic field is cut by the windings, thus creating the output AC voltage. (Kind of like an alternator does, but the field moves instead of the windings.) The 50 cycle current available in Europe cycles the magnetic field slower, thus resulting in a reduced output AC voltage. (The 110/96 ratio is suspiciously close to the 60/50 cycle ratio, prompting me to this hypothesis.) Could this be right, wizards? Any way to cobble my trusty old Solas's up to kick that output voltage up (and no, I ain't gonna rewind that sucker either!)? Or just buy European 220/110 transformers with the cycle difference already accounted for? Anyway, lesson learned for you guys planning to go to Europe: don't depend on any Stateside 220/110 transformers working correctly. (Incidentally, the Apples I was using ran just fine on 96V. Two of three Corvus 20Meg hard disks ran fine (last one wouldn't run there; ran just fine back Stateside). Sanyo color monitors - just fine on 96V. Sanyo green screen monitors: yuck! Extremely blurry characters top and bottom of screen; totally unsatisfactory. Took a chance, grabbed the available 110 volt wall current, ran it through an isolator (really had dirty current at that location); green screen ran fine. Oh, yeah, blew up three (count 'em, 3) Global OOPSes (Uninterruptable Power Supplies) trying to run them on the available 110V wall plugs. Capacitors catastrophically destructed (really neat, lots of smoke and expensive smells). Lost two solid and one wet capacitors -- the wet one on the electronics board blew like a minigrenade, plastering bits of foil and gunk all over the board and actually blowing several traces off the board! Suspect the 110V in that building was obtained by "cycle clipping" (donno the real word for it, but you clip off one side of the 220V cycle, getting 110V all right, but a strange 110V that maybe electronics don't like so very much). One of the OOPSes ran OK for a couple of hours on Solas-transformed 220>96V, and then started complaining; so we never did get any use of our OOPSes. 'Nuff said on my experiences. Would appreciate some hints/suggestions/ background knowledge on European power and my hardware. Thanks in advance, David Kirschbaum SGM, USA Corps Automation Management Office HQ XVIII Abn Corps, Ft Bragg 22-Nov-83 15:38:26-MST,1078;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 22 Nov 83 15:38:10-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 22 Nov 83 12:19 EST Received: From Ucb-Vax.ARPA by BRL via smtp; 22 Nov 83 12:07 EST Received: by UCB-VAX.ARPA (4.21/4.15) id AA14046; Mon, 21 Nov 83 20:25:48 pst Date: Mon, 21 Nov 83 20:22:51 PST From: AJ76 Message-Id: <8311220422.AA15701@D.CC.Berkeley.ARPA> Received: by D.CC.Berkeley.ARPA (4.8/4.8) id AA15701; Mon, 21 Nov 83 20:22:51 PST To: k.info-cpm@brl Subject: U.S. Robotics S-100 212A modem query In a recent Byte, I saw that Priority One is selling the new U.S. Robotics S-100 212A 300/1200 autodial/autoanswer modem for something like $379. I just got the manual on the beast and it seems to be pretty good, although they have done some strange things to allow variable baud rates... I was wondering if anybody actually has one of these things, and if they do, what their reactions are to it. Phil (jlapsley%D.CC@Berkeley) 22-Nov-83 16:00:52-MST,2493;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 22 Nov 83 16:00:43-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 22 Nov 83 13:14 EST Received: From Brl-Bmd.ARPA by BRL via smtp; 22 Nov 83 12:47 EST Date: Tue, 22 Nov 83 12:40:34 EST From: A B Cooper III To: ihnp4!houxm!hogpc!houti!ariel!vax135!cornell!uw-beaver!ssc-vax!schneids@ucb-vax cc: info-cpm@brl, abc@brl-bmd Subject: Re: best UNIX for cpm Your untoward outburst about advertising on the net is both impolite and uninformed. If your parents did nothing about your manners, then neither can I. As to your lack of awareness, however, I have provided the following note put out by the administrator if Info-Micro to his net. Continued flagrant violations of the policies by which these nets are constrained will only cause all of us to lose a valuable resource for which we pay essentially NOTHING. Brinton Cooper (abc@brl.arpa)  Received: From Brl.ARPA by BRL-BMD via smtp; 22 Nov 83 12:04 EST Received: From Mit-Mc.ARPA by BRL via smtp; 22 Nov 83 11:32 EST Date: Mon, 21 Nov 83 13:35:52 EST From: Ron Natalie To: Mark Horton cc: header-people@mit-mc.arpa, Rudy.Nedved@cmu-cs-a.arpa Subject: Re: Rudy Nedved on mail forwarding Let me point out, that despite what ARPANET (and MILNET) has become, they enjoy some operating benefits that are legally unavailable to commercial telecommunications and computer services. This is THE major reason for the anti-commercial restriction on these nets for it has always been stated in the first few lines of every ARPANet policy statement that the net is not to be used to compete with comparable commercial service. Second policy is that the network must be used solely for the conduct of or in support of official U.S. Government business. This is a wide area. All the discussions about things like Apple computers are in support of the US Gov. because (unfortunately maybe?) the government has bought a lot of Apple computers. DCA has left it up to the host administrators at each site to protect the network with "adequate" access control procedures. In this case you are right, let the host administrators determine what level of interaction he wants to support, but it is not just a question of what money he is paying for his network service. -Ron  22-Nov-83 16:22:55-MST,1102;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 22 Nov 83 16:22:45-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 22 Nov 83 15:24 EST Date: Tue, 22 Nov 83 15:19:29 EST From: Keith Petersen To: Info-Cpm@brl-vgr Subject: Re: Transformers and European Current Dave, the UPS and Sola units are "tuned" to 60hz, should NEVER be plugged into anything else. The capacitor/inductance combination is actually carefully peaked at 60hz to provide the desired core saturation to create the voltage regulation effect. Generally speaking 60hz equipment (such as monitors and computers) should not be run on 50hz because the transformers run hotter and may eventually fail from the heat (or the heat may cause something else inside to fail). If you intend your equipment to operate on both 50 and 60hz, it should be ordered for 50hz originally. The transformers have more iron in them and run just fine on 60hz (actually cooler). This of course cannot be done with "tuned" systems such as Sola CVTs. 23-Nov-83 15:07:23-MST,1232;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 23 Nov 83 15:07:12-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 22 Nov 83 20:04 EST Date: Tue, 22 Nov 83 19:57:06 EST From: Rick Conn To: George.Wood@cmu-cs-a cc: info-cpm@brl, info-micro@brl Subject: ZEX and ZCPR2 George, ZEX, the memory-based command file facility, is able to process submit files, usually without change from the old form used with SUBMIT. It was released with ZCPR2, and I have used it ever since, moving almost completely away from SUBMIT and SUB2 (a version of SUBMIT with enhancements that also came out wth ZCPR2). The few cases I found it desirable to go to SUB2 involved the need for a larger TPA, and ZEX may very well have been able to handle it anyway. Your concern is valid ... if you have not tried ZEX with ZCPR2, read the manual and try running a few ZEX command files. I think you will see the differences which attract me to ZEX and away from SUB2/SUBMIT. The purpose of question 3 of the query was to see if anyone has an application where ZEX absolutely cannot do the job and they HAVE to use SUB2/SUBMIT. Rick 23-Nov-83 15:07:51-MST,1761;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 23 Nov 83 15:07:42-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 22 Nov 83 21:17 EST Received: From Usc-Isid.ARPA by BRL via smtp; 22 Nov 83 21:09 EST Date: 22 Nov 1983 14:27-PST Sender: ABN.ISCAMS@usc-isid Subject: KERMIT and your local TAC From: ABN.ISCAMS@usc-isid To: INFO-CPM@brl Cc: ABN.ISCAMS@usc-isid Message-ID: <[USC-ISID]22-Nov-83 14:27:47.ABN.ISCAMS> I was exchanging messages with a NetLandian the other night, and he mentioned not being able to get KERMIT running. He also mentioned he was working on the ARPANet through a TAC, and I fired off my TAC patch to KERMIT. Suddenly realized others out there might have the same problem. If you're working through a TAC, and KERMIT absolutely totally refuses to make the first connection, even in the simple CONNECT mode, message me. The problem is in the TAC's interrupt character (I think that's the term -- on my TAC, it's the @ sign -- you have to send 2 to get the TAC to send on a single one to the host, else the TAC thinks you're talking to it, and all KERMIT's commands and stuff make no sense at all to it! I have a real simple patch for the .ASM source to KERMIT (only about 3 instructions and one address!), and will message to you singly, or to the net in general if enough queries come in. Yes, I will be contacting the COLUMBIA people, but want to make my Morrow Decision I and Freedom 100 IF-ENDs to KERMIT (well, actually CPMBASE.M80) first to give them one complete FTPable package. If you have a Decision I or a Freedom 100, of course I'll be glad to get the appropriate changes to you as well. David Kirschbaum Toad Hall 23-Nov-83 15:08:24-MST,1014;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 23 Nov 83 15:08:18-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 23 Nov 83 0:01 EST Date: Tue, 22 Nov 83 23:55:29 EST From: Keith Petersen To: jim@rand-unix cc: Info-Cpm@brl-vgr Subject: Re: MODEM 7? All MICRO: directories on SIMTEL20 have been changed to MICRO:. Frank Wancho sent out a message announcing this but guess it got lost on its way to you. The one you want is MICRO: and you'll find MDM714 (the VERY latest MODEM7 that I just finished uploading this morning). Do a DIR to get the file names. I'll be sending out an annoucement telling what each of the files is for, but in the meantime you can figure out which overlays you want by their two-character distinctive names M7xx.1ASM. You don't need MDM714.ASM - just get MDM714.COM and the appropriate overlay. It's easy to configure. --Keith 23-Nov-83 15:08:39-MST,1128;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 23 Nov 83 15:08:33-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 23 Nov 83 0:13 EST Date: Wed, 23 Nov 83 0:08:47 EST From: Keith Petersen To: ABN.ISCAMS@usc-isid cc: INFO-CPM@brl, ABN.ISCAMS@usc-isid Subject: Re: KERMIT and your local TAC Kermit works fine through a TAC if you change the TAC intercept character to something that Kermit will not be sending. I use control-E. That's done by telling the TAC: @i 5 no changes are required to Kermit when this is done. Of course only text files (not binary) can be transmitted because the mainframe Kermit doesn't know how to tell the TAC to switch to binary mode yet. I've been using Kermit to upload VERY large text files using wild cards (i.e.: Kermit send *.*) and it works very well at 1200 baud. I uploaded the whole MDM714 package over the weekend that way. Kermit works when MODEM or umodem fail due to system load. My last upload was 140k of files while there were 25 users on BRL! --Keith 23-Nov-83 15:08:50-MST,1198;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 23 Nov 83 15:08:45-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 23 Nov 83 1:59 EST Date: 23 November 1983 02:05 EST From: David Sternlight Sender: W8SDZ@mit-mc Subject: SD bug To: Info-Cpm@brl-vgr Orig-Date: 21 Nov 1983 2103-PST To: info-cpm-request@brl-vgr cc: sternlight@ecl ReSent-To: Info-Cpm@brl-vgr There is a bug in sd-77 which has been around for a while. When SD goes to look at the S2 byte of the file control block to see if there are more extents than 3, it looks at the whole byte. This is inconsistent with CP/M practice, which uses the lower 4 bits only of this byte. (Never mind what David Cortesi says in his book; he is mistaken.) Thus an ani 0fh needs to be inserted in the code to mask out the relevant bits. Otherwise, programs such as qbax, which use the higher bits for such things as archive flags will (if they set a file as backed-up) cause sd to report the file size as 256k too large. The place for the ani 0fh is just following the (second) LDAX D after TMOVE:, which loads the s2 byte. --david-- 23-Nov-83 15:10:00-MST,4468;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 23 Nov 83 15:09:46-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 23 Nov 83 4:08 EST Date: Wed, 23 Nov 83 3:57:18 EST From: Keith Petersen To: Info-Cpm@brl-vgr Subject: MDM714 now available The latest version of MODEM7 is now available on SIMTEL20 as MDM714. Irv Hoff has released a fully-commented version of the source code and renamed the overlays so they don't have to be updated when a new version of the main program is released. Some overlays have been improved and/or fixed. You should get the new one apporpriate to your hardware. This program is based on one originally written by Ward Christ- ensen in September 1977. It has since undergone a considerable number of changes. Recent changes include auto-dialing and continuous redial- ing for the Hayes 300 or 1200 Smartmodem and the U. S. Robotics, along with the standard PMMI 103 routines the program has long supported. It also handles up to two alternate long distance systems such as SPRINT, ALLNET,MCI, (can be used to auto-dial TYMNET), etc. NOTE: Special configuration files are being added for specific types of computers. A large number are already available (as shown below) and others are being added as interest escalates. The files are are on SIMTEL20 in the MICRO: directory. Program name Purpose MDM714.ASM (source code file) MDM714.COM (object code file) MDM714.DOC (how-to-use file) MDM714.INF (information file) M7AC.1ASM (AppleCat II overlay file) M7AJ.1ASM (Apple J-Cat overlay M7AL.1ASM (Altos Series 5 overlay file) M7AM.1ASM (Apple II with Mtn. Computer CPS card) M7AP.1ASM (Apple II overlay file) M7DP.1ASM (Datapoint 1560 overlay) M7EP.1ASM (Epson QX-10 overlay) M7GP.1ASM (General purpose overlay) M7H8.1ASM (Heath/Zenith H89 file) M7HP.1ASM (Hewlett Packard 125 file) M7HZ.1ASM (Heath/Zenith Z-100 file) M7IN.1ASM (Interfacer 3/4 overlay file) M7KP.1ASM (KayPro overlay file) M7LO.1ASM (Lobo MAX-80 overlay file) M7MD.1ASM (Morrow MD overlay file) M7MM.1ASM (Morrow Multi I/O overlay file) M7NA.1ASM (North Star Advantage) M7NE.1ASM (NEC PC-8001 overlay file) M7NH.1ASM (North Star Horizon with HSIO-4) M7NM.1ASM (Phone number overlay) M7OA.1ASM (Otrona Attache overlay file) M7OS.1ASM (Osborne overlay file) M7OX.1ASM (Osborne Executive overlay file) M7PC.1ASM (IBM-PC with Baby Blue Z-80 card) M7PM.1ASM (PMMI S-100 modem overlay) M7R1.1ASM (Radio Shack TRS-80, Model I) M7R2.1ASM (Radio Shack TRS-80, MODEL II - P&T) M7RV.1ASM (Racal-Vadic VA212PA modem) M7SY.1ASM (Sanyo MBC-1000 overlay) M7TV.1ASM (TeleVideo TS-802 overlay) M7VT.1ASM (DEC VT-180 overlay) M7XE.1ASM (Xerox 820 overlay file) M7ZB.1ASM (Telcon Zorba overlay file) To adapt this version to your equipment, you will want to get some of these programs. The minimum would be any pair in one of the examples shown below.) There are several ways by which you can set the proper ports, status pin values, etc. for your equipment. 1) Use your editor, ASM (or MAC) MDM714.COM and and DDT (or SID) with: M7xx-x.ASM (7xx-x stands for an appropriate overlay) or 2) Use your editor, ASM (or MAC) MDM714.ASM One of those should appeal to you. The program is designed to work immediately for PMMI users with no changes - just use MDM7xx.COM. (You might wish to change some of the available options, however. It is set to use base port 0C0H.) When ready to use the program, type 'H' (for 'HELP'), hit RET and it will display helpful information on the commands. There are so many commands there are several pages. You can abort the display with a CTL-C. (One of the most useful features being CTL-P to toggle your printer on/off.) You can also type a question mark (?) which shows the current parameters. --end-- 23-Nov-83 15:12:16-MST,1099;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 23 Nov 83 15:12:09-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 23 Nov 83 7:26 EST Received: From Sri-Unix.ARPA by BRL via smtp; 23 Nov 83 7:16 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 23 Nov 83 4:12-PST Date: 20 Nov 83 22:53:10-PST (Sun) To: info-cpm@brl From: pur-ee!uiucdcs!uok!jsmcginn@ucb-vax Subject: Re: Modem7 on the rainbow - (nf) Article-I.D.: uiucdcs.4034 #R:sri-arpa:-1320400:uok:4800002:000:495 uok!jsmcginn Nov 18 14:57:00 1983 Yes, the DEC Rainbow does come with a rs232 port as standard equipment. I don't have a modem for my Rainbow yet, but I asked my dealer and he said that (for example) if I wanted to hook up a Smartmodem, the only extra equipment that I would need is a standard rs232 cable w/25 pin connector. My dealer also said that all the modem software that he has tested so far has worked efficiently and practically bug free. Jay ...!uok!jsmcginn 23-Nov-83 15:17:20-MST,5772;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 23 Nov 83 15:17:02-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 23 Nov 83 8:34 EST Date: Wed, 23 Nov 83 8:20:26 EST From: Rick Conn To: info-cpm@brl cc: info-micro@brl Subject: Results of ZCPR2 Query to Date To date, I have only received seven replies to the query I sent out on the current state of ZCPR2 and the two questions on retaining features. CCP GROUP has had tons of traffic on a lot of issues as well, and the following summarizes the data to date: Question 2: Should disk-based named directories be retained? Yes - 1, No - 4; My Decision: NO Comment 2: Loss of disk-based named directories has only one disadvantage that I can see -- the tree and mesh structures possible with them are no longer possible. With only memory- based named dirs and the DU form, only a flat directory structure is possible (with current mode of thinking). Loss of disk-based named dirs has one major advantage -- all major ZCPR2 utilities, including XDIR, XD, VFILER, ERASE, RENAME, PROTECT, MCOPY, etc, will be smaller now and run faster. Question 3: Should disk-based command files ($$$.SUB) be retained? Yes - 2, No - 5; My Decision: MAYBE Comment 3: Again, with ZEX around, SUB2/SUBMIT are not necessary by and large. The only good reason to retain $$$.SUB is to have the largest TPA possible. I am really reluctant to remove this capability based on this one reason, but I fear the space may be needed to implement the more-important new functions of the command processor. As a result, I plan to proceed with the design and reconsider this alternative only when it becomes appearant that removal of the $$$.SUB processing is absolutely necessary in order to get the newer features in. Question 1: Bug Reports. I am very pleased with the distinct lack of bug reports -- not bad considering that these few bugs were found in over 1.5 million bytes of source code! Here is a summary of the bugs reported. If you are planning to submit a reply to the query, please look here first to see if your bug has already been reported. PROGRAM PROBLEM/NEW FEATURE ------- ------------------- ZEX (1) aborting via ^? does not return cleanly; this bug has been duplicated and will be corrected MCOPY (1) protection against accidentally copying into the same DU as the source does not work in all cases; this bug will be corrected; as a note, MCOPY will undergo a complete redesign for greater speed, more flexibility, and better human interface (2) the ability to abort a multiple copy is requested; this request will be granted (3) accidental use of the A:FN1.TYP=A:FN2.TYP form will cause the original file to be deleted and nothing left; this bug will be corrected; MCOPY was not intended to be used with this form, but the habit of using PIP that way is not easily forgotten DU2 (1) The ability to save the contents stored in the queue as a disk file is requested; this request will be granted GET (1) does not restore the DMA address if executed from a $$$.SUB file; this has not been verified yet, but will be looked into and corrected if verified VFILER (1) "VFILER d" form may not log user into the same user area that he was in originally; this will be investigated and corrected (2) new feature: lack of information passed from the pointer to the CMD file being executed; add the ability to pass just the "filename" or "typ" part of "filename.typ" (3) new feature: include R/O attribute in file display and add command to toggle it for file being pointed to (4) new feature: add ability to duplicate the file pointed to in the same directory under a different name (5) more features in general requested; will be considered EVAL10/ (1) may have a bug when some even numbers are input; will SYSLIB investigate and correct Thanks very much to all who responded. Your comments are useful and of value, and your interest in this project is appreciated. If any other ideas come to mind, feel free to forward them to me. There has been a lot of curiosity about two items: (1) what will ZCPR3 be like and (2) when will it be released. I am very reluctant to say anything either way at this time because the design is still forming. Once the system has begun to take operational shape, then something can be said. Two design reviews are now planned -- one around the first two weeks in Jan 84 and the other around the first two weeks in Feb 84. Something should be firm by the first review, and an announcement will be made then. The big thing to remember is that ZCPR3 will be more of the same thing as ZCPR2, and features such as paths, multiple command lines, memory-based named dirs, redirectable I/O, and screen-oriented tools (like VFILER) will also be found in ZCPR3. There are some new features which are in line with the old ones and significantly extend the capability of the system beyond ZCPR2 -- first will come the implementation of these, and then will come the news to you of them. Will keep in touch. Rick 23-Nov-83 15:19:16-MST,1545;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 23 Nov 83 15:19:11-MST Received: From Usc-Isid.ARPA by BRL-VGR via smtp; 23 Nov 83 9:26 EST Date: 23 Nov 1983 04:20-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: MODEM 7? From: ABN.ISCAMS@usc-isid To: w8sdz@brl Cc: jim@rand-unix, Info-Cpm@brl-vgr Message-ID: <[USC-ISID]23-Nov-83 04:20:03.ABN.ISCAMS> In-Reply-To: The message of Tue, 22 Nov 83 23:55:29 EST from Keith Petersen Roger on MDM714.COM and its overlays. I was working on MDM712, saw the bulletin on MDM714, and immediately grabbed it. Sure is easier to patch up a wee little micro-specific overlay than the big source code of MDM714! Works fine (except I got a bug in the LOCMSG character (the one that I think lets you send a local command (like ^E in HERMES) while telling MDM714 to ignore it. For some reason the SHFTYPE procedure is NOT changing that character back to ASCII in the menu, and ^^ (per the original code) oes weird things on my Freedom 100 screen! Changed it to ^\, so it no longer blows my menu away, but still don't have it working quite right. I'll figure it out though. I added (I THINK it was me that added) my serial port 3 baud initialization routine as an initialization routine in the M7MM-1 overlay (used to be MDM712MM.ASM) for my Decision I. (Doggon shame when you're hacking so much you can't remember what is your work and what came from outside!) Regards, David Kirschbaum Toad Hall 23-Nov-83 15:26:38-MST,1411;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 23 Nov 83 15:26:32-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 23 Nov 83 9:45 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 23 Nov 83 9:37 EST Date: 23 Nov 83 09:14:06 EST (Wednesday) From: Nail.wbst@PARC-MAXC.ARPA Subject: Re: Transformers and European Current In-reply-to: <[USC-ISID]21-Nov-83 10:29:29.ABN.ISCAMS> To: ABN.ISCAMS@usc-isid.ARPA cc: INFO-CPM@brl.ARPA Dave, First, I would like to say that I am glad to see someone using the net in a way that is very effective and suit the medium very well. Kudos. Second. Sola transformers are resonant transformers with energy alternatingly stored in the magnetic field (L) and then in a capacitor(C). The this is a LC tuned circuit intended to run at the 60 cycles designed for your equipment. Running such a tuned circuit at any other frequency will not effectively exchange the stored energy between L and C in the circuit. Conceivably, the circuit can be retuned by changing the components (probably C would be easiest to change). You may be able to successfully retune the circuit, but you can expect the power handling characterists of the transformer to differ. My take on this is that you might find it to be better to get a transformer tuned for the 50Hz application. Good luck. Charlie 23-Nov-83 15:26:54-MST,1136;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 23 Nov 83 15:26:46-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 23 Nov 83 9:45 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 23 Nov 83 9:38 EST Date: Wed, 23 Nov 83 09:24 EST Subject: Re: best UNIX for cpm To: info-cpm@brl.ARPA From: Don Wegeng cc: The problem that we face when discussing the subject of "commercial use of the net" is that while ARPANET and MILNET have policies against commercial use of the net, Usenet does not. In fact, commercial use of Arpanet and Milnet is illegal. I suspect that most readers on both sides of the gateway appriciate the benefits of having the list gatewayed between the nets, and therefore do not post messages which might cause the gateway to be shut down. However, this is one instance when a few bad apples have a very good chance of spoiling the whole bunch if they continue at their present course. Don Wegeng Wegeng.Henr@Parc-Maxc.ARPA (ARPA) {intelca | pur-ee | rocksvax | sequent} !rocks34!dw (UUCP) 23-Nov-83 15:39:59-MST,1628;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 23 Nov 83 15:39:51-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 23 Nov 83 15:11 EST Received: From Nosc-Cc.ARPA by BRL via smtp; 23 Nov 83 12:19 EST Date: 23 Nov 1983 09:14:49-PST From: Ty Wernet Reply-to: CCVAX.ty@nosc To: info-cpm@brl, rconn@brl Subject: Re: Results of ZCPR2 Query to Date Rick, A disadvantage to ZEX that makes me go back and use one of the disk-based submit type programs is that when using ZEX I am unable to run programs that need speed. For example, I am running a SUPER19 like rom in my terminal at 38,400 baud. I request the date from the terminal under the regular submit like programs and have no problem, when using ZEX, it is unable to handle the characters coming back from the terminal. That makes programs that use the date feature of my terminal useless. Even running at 9600 baud ZEX is unable to keep up. Other than the speed problem ZEX does everything else that I require. When I say ZEX is unable to handle the characters coming back from the terminal it is ZEX dropping/missing them. I have implemented ZCPR2 on our machines here at work and also all the ones we have at home. We currently do not use ZCPR2's named directories. We had developed a "CD" of our own running under ZCPR1. It is name based with unique directory recognition. The .dir file is only a text file containing disk,user#,name. A rather simple solution but works well. When ZCPR2 came around we just moved our "CD" over. ty@nosc --- 23-Nov-83 16:12:02-MST,1455;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 23 Nov 83 16:11:57-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 23 Nov 83 15:14 EST Received: From Amsaa.ARPA by BRL via smtp; 23 Nov 83 15:01 EST Date: Wed, 23 Nov 83 14:59:27 EST From: David Towson (CSD) To: ABN.ISCAMS@usc-isid cc: INFO-CPM@brl, ABN.ISCAMS@usc-isid Subject: Re: Transformers and European Current David - The answer to your constant-voltage transformer question becomes self-evident as soon as you hear the other name for them: They are also known as "ferro-resonant transformers". Their operation depends on a tuned circuit whose resonant frequency is slightly off the operating frequency. As the line voltage input changes, the amount of core flux changes, and since the relationship of core flux to exciting current (which results from the applied voltage) is non-linear for iron-core inductors, the inductance of a choke (inductor) in series with the transformer part itself (it's all inside the box) changes and this changes the voltage actually applied to the trans- former. The thing is set up so that the change is in the right direction to adjust the voltage to near what it should be coming out of the unit. When you run it on 50 HZ, you totally mess up the resonant action, which is tuned for 60 HZ. And that's the rest of the story. Dave 23-Nov-83 17:00:26-MST,1068;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 23 Nov 83 17:00:19-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 23 Nov 83 17:47 EST Date: 23 Nov 1983 15:45 MST (Wed) Message-ID: From: "Frank J. Wancho" To: INFO-CPM@brl-vgr Subject: New Hours for SIMTEL20 The SIMTEL20 will be unavailable tomorrow (Thanksgiving), and only first shift (08:30 to 16:00 MST) on Friday, 25 Nov. Beginning on Monday, the hours will revert to 08:30 to 21:40 MST instead of only til 19:40 MST, still weekdays only, but, read on. We finally got one of our Facilities Engineering engineers to come out yesterday to check out the situation for installing an over-temp cutoff. This means our work order has been "engineered", and is now a matter of purchasing some miscellaneous items and the shunt-trip circuit breaker (contactor) to replace the existing normal breaker, AND, scheduling someone to come out to do the work. Real Soon Now... --Frank 23-Nov-83 17:23:49-MST,768;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 23 Nov 83 17:23:46-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 23 Nov 83 18:35 EST Date: Wed, 23 Nov 83 18:24:51 EST From: Rick Conn To: info-cpm@brl cc: info-micro@brl Subject: Ty's comments Ty, thanks for your message. You brought up a point I had not considered, and it gives more reason for leaving the $$$.SUB capability in. The advantage to using named dirs under ZCPR2 instead of a simple implementation for just CD is that ALL of the major ZCPR2 utilities know about them. You can say things like XDIR ROOT:, ERASE MYDIR:*.BAK, etc. Even VFILER knows about them and how to use them. Rick 25-Nov-83 08:37:55-MST,706;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 25 Nov 83 08:37:50-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 23 Nov 83 21:26 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 23 Nov 83 21:25 EST Date: Tue, 22 Nov 83 08:21 PST From: Eldridge.es@PARC-MAXC.ARPA Subject: Starcross help needed To: info-cpm@brl.ARPA cc: DGilbert.es@PARC-MAXC.ARPA, Eldridge.es@PARC-MAXC.ARPA We are playing the CP/M version of the Infocom game STARCROSS. We have completed about 80% of it, but have come to an impass. Help from anyone who has played STARCROSS would be greatly appreciated. Reply to Eldridge.es@PARC-MAXC.ARPA George 25-Nov-83 08:38:44-MST,883;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 25 Nov 83 08:38:37-MST Received: From Usc-Isid.ARPA by BRL-VGR via smtp; 23 Nov 83 21:37 EST Date: 23 Nov 1983 14:10-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: MODEM 7? From: ABN.ISCAMS@usc-isid To: ABN.ISCAMS@usc-isid Cc: w8sdz@brl, jim@rand-unix, Info-Cpm@brl-vgr Message-ID: <[USC-ISID]23-Nov-83 14:10:11.ABN.ISCAMS> In-Reply-To: <[USC-ISID]23-Nov-83 04:20:03.ABN.ISCAMS> To NetLand and the author of MDM714: Sorry, sorry, sorry. That serial port 3 initialization for the Morrow Decision I overlay to MDM714 was the work of the original author ( canNOT remember his name!). His work, his credit, his glory. (Sorry, looked just like a patch I made to another modem program that I hacked out of my CBIOS, and got mixed up.) David Kirschbaum Toad Hall 25-Nov-83 08:38:53-MST,827;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 25 Nov 83 08:38:48-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 23 Nov 83 22:23 EST Received: From Su-Score.ARPA by BRL via smtp; 23 Nov 83 22:14 EST Date: Wed 23 Nov 83 19:10:47-PST From: Mark Crispin Subject: Re: KERMIT and TAC To: cc.fdc@COLUMBIA-20.ARPA cc: Info-CPM@BRL.ARPA, Info-Kermit@COLUMBIA-20.ARPA In-Reply-To: Message from "Frank da Cruz " of Wed 23 Nov 83 09:46:12-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) I believe that @ B I S will suffice to disable the TAC escape character, so the step of setting it with @I should be unnecessary. ------- 25-Nov-83 08:39:32-MST,1498;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 25 Nov 83 08:39:24-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 23 Nov 83 21:39 EST Received: From Usc-Isid.ARPA by BRL via smtp; 23 Nov 83 21:36 EST Date: 23 Nov 1983 13:50-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: Modem7 on the rainbow - (nf) From: ABN.ISCAMS@usc-isid To: pur-ee!uiucdcs!uok!jsmcginn@ucb-vax Cc: info-cpm@brl Message-ID: <[USC-ISID]23-Nov-83 13:50:51.ABN.ISCAMS> In-Reply-To: The message of 20 Nov 83 22:53:10-PST (Sun) from pur-ee!uiucdcs!uok!jsmcginn@ucb-vax Jay: Yes, you should be able to find good Public Domain modem programs out there. I'm pretty certain there's a Rainbow overlay for MDM714; you can check the SIMTEL20 treasure trove for that. I think KERMIT is also implemented for the Rainbow, and that's a good "packetizing" file transfer and terminal program to mainframes and minis as well as micros. One thing, though..you not only don't NEED a full 25-wire cable for that RS-232 connection: you don't WANT all those wires hanging out there! All they do is pick up interference, radiate, etc. Check your RS232 pin requirements for the modem you get and your Rainbow, and only hang wires for the pins required. Have fun hanging the Rainbow on a Wire: that's the best part of owning my Decision I -- talking with the NetLandians and looting all that great Public Domain treasure. David Kirschbaum Toad Hall 25-Nov-83 08:47:52-MST,1678;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 25 Nov 83 08:47:46-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 24 Nov 83 4:30 EST Received: From Sri-Unix.ARPA by BRL via smtp; 24 Nov 83 4:26 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 24 Nov 83 1:12-PST Date: 21 Nov 83 22:54:52-PST (Mon) To: info-cpm@brl From: pur-ee!uiucdcs!parsec!kolstad@ucb-vax Subject: Re: Reply to:Re: Call for Osborne Execu - (nf) Article-I.D.: uiucdcs.4056 #R:sri-arpa:-1373900:parsec:48000002:000:1039 parsec!kolstad Nov 21 16:02:00 1983 [re: Jerry Pournelle's confusion about selling cars, leasing apartments, and trading software] While it is perfectly legal and acceptable for people to sell their car (and transfer titles through state authorities) and sublease apartments (with the ensuing legalities of sublease signing), it is typically illegal and unethical for people to trade, say, their copy of Wordstar II for my copy of SuperDuperWriter. I believe this is the kind of trade which is discouraged on the net. If the net were to allow such (I believe illegal) trading to go on, then few major companies could support it (as their reputations would follow that of the network). I believe the net would then shrink drastically -- a happening I would dread. To use an appropriate analogy, the net would also discourage people from typing in first editions of, say, the sequel to "Mote in Gods Eye" so everyone on the net could enjoy it without the hassle of paying the bookseller to obtain a hard-copy and sell it ... Rob "not really holier than thou" Kolstad 25-Nov-83 09:37:49-MST,1330;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 25 Nov 83 09:37:45-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 24 Nov 83 5:27 EST Received: From Sri-Unix.ARPA by BRL via smtp; 24 Nov 83 5:21 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 24 Nov 83 2:13-PST Date: 22 Nov 83 11:09:11-PST (Tue) To: info-cpm@brl From: ihnp4!ihopa!burris@ucb-vax Subject: Mail to ..!aecom!glen concerning ConIX Article-I.D.: ihopa.111 I couldn't get this through via mail so here it is: To: harpo!seismo!philabs!aecom!glen Subject: cp/m unix I am very interested in the ConIX system you mentioned on the net. I have a couple of questions: 1. Is the source code supplied? Optional? Cost? 2. How is the speed? 3. What utilities are included? 4. What kind of support has been committed too? 5. How are bug reports and/or fixes to be distributed? 6. Can the user supply device drivers? 7. Does the system keep all directory information that UNIX does (dates, etc.)? 8. Is it multi-user/tasking? Info may be sent to: Dave Burris AT&T Bell Labs - Indian Hill Naperville - Wheaton Road Naperville, Il. 60566 -- Dave Burris ..!ihnp4!ihopa!burris AT&T Bell Labs, Naperville, Il. 25-Nov-83 12:42:26-MST,1586;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 25 Nov 83 12:42:17-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 25 Nov 83 10:33 EST Received: From Usc-Isid.ARPA by BRL via smtp; 24 Nov 83 9:54 EST Date: 23 Nov 1983 20:52-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: KERMIT and TAC From: ABN.ISCAMS@usc-isid To: MRC@su-score Cc: cc.fdc@columbia-20, Info-CPM@brl Cc: Info-Kermit@columbia-20 Message-ID: <[USC-ISID]23-Nov-83 20:52:55.ABN.ISCAMS> In-Reply-To: The message of Wed 23 Nov 83 19:10:47-PST from Mark Crispin Talking about disabling (or changing) the TAC escape character.. I just had a (polite but sincere) talking to by my TAC owners... Seems they don't really like so very much when users start messing about with their ports! (I never changed the excape character because I suspected it would cause people problems.) I DID leave F O S set a couple of times (makes XON/XOFF happen at the TAC level for immediate halting of a listing while my software writes to file) -- usually when the system choked up and I got thrown off! Turns out any of those convenient settings we users make to ports STAY THAT WAY when we leave/sign off unless we specifically reset them to the way things were -- and that sure can mess up the next guy. I'd suggest anyone playing with their TAC maybe check with the operators first to kind of work out an agreement. If they know what and why you're doing, they tend to be much more understanding! David Kirschbaum Toad Hall 25-Nov-83 14:04:06-MST,889;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 25 Nov 83 14:04:01-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 25 Nov 83 10:41 EST Received: From Sri-Unix.ARPA by BRL via smtp; 25 Nov 83 6:42 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 25 Nov 83 3:28-PST Date: 22 Nov 83 14:34:24-PST (Tue) To: info-cpm@brl From: ihnp4!houxm!hou2f!9534tap@ucb-vax Subject: need help on Epson QX/10 modem set for other than hayes Article-I.D.: hou2f.118 I have a modem that will operate at 1200 baud, but is not smart enough to emulate a hayes. I would like help in setting up the 'SETUP' commands to use this modem. I have MBASIC and SuperSoft 'C' compilers. I am a novice at personal computers, and would appreciate any help from anyone. Tom Pappas BTL Holmdel, N.J. USENET!ihpn4!hou2f!9534tap 25-Nov-83 14:19:09-MST,764;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 25 Nov 83 14:19:05-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 25 Nov 83 10:41 EST Received: From Sri-Unix.ARPA by BRL via smtp; 25 Nov 83 7:45 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 25 Nov 83 4:28-PST Date: 29 Nov 83 1:57:27-EST (Tue) To: info-cpm@brl From: harpo!eagle!allegra!amd70!phil@ucb-vax Subject: Re: Speeding up the Kaypro-2 Article-I.D.: amd70.4126 In-Reply-To: Article <13851@sri-arpa.UUCP> What's all this silliness about ROMs overheating when you run them too fast? I never heard of such a thing. Glad I'm not a hobbyist, -- Phil Ngai (408) 988-7777 {ucbvax|decwrl|ihnp4|allegra}!amd70!phil 25-Nov-83 14:28:46-MST,738;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Fri 25 Nov 83 14:28:43-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 25 Nov 83 10:42 EST Received: From Sri-Unix.ARPA by BRL via smtp; 25 Nov 83 7:58 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 25 Nov 83 4:43-PST Date: 22 Nov 83 17:16:50-PST (Tue) To: info-cpm@brl From: ihnp4!fortune!burton@ucb-vax Subject: Re: The New ZCPR - ZCPR3 Article-I.D.: fortune.1824 In-Reply-To: Article <13859@sri-arpa.UUCP> If you're reading this message under group net.micro.cpm, please see my reply under group net.micro. -Philip Burton Fortune Systems 28-Nov-83 08:28:25-MST,553;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:28:14-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 25 Nov 83 12:21 EST Received: From Bbnccs.ARPA by BRL via smtp; 25 Nov 83 12:12 EST Date: 25 Nov 1983 12:06:23 EST (Friday) From: Andrew Malis Subject: UNIX version of xmodem/amodem To: info-micro@brl, info-cpm@brl Cc: malis@bbn-unix Can anyone point me to an FTPable copy of AMODEM/XMODEM that runs on UNIX v7 or system III? Thanks, Andy 28-Nov-83 08:28:39-MST,1674;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:28:26-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 25 Nov 83 16:53 EST Received: From Columbia-20.ARPA by BRL via smtp; 25 Nov 83 16:42 EST Date: Wed 23 Nov 83 10:47:07-EST From: Frank da Cruz Subject: KERMIT and TAC To: Info-CPM@BRL.ARPA, Info-Kermit@COLUMBIA-20.ARPA I've been told by someone who knows about these things (Mark Crispin at Stanford) that there's no good way to make KERMIT-20 put the TAC in binary mode, at least not in a way that doesn't depend on a bug in TOPS-20 that may be present at some sites but fixed at others (the bug being that FF (a byte with all 1's) is supposed to be quoted by doubling in the monitor, but isn't, so some application programs do it instead). Therefore, the way to use KERMIT over a TAC would seem to be: 1. Set the TAC escape character to be any control character other than ^A or CR, LF, etc. ^A is KERMIT's packet synchronization character, and CR or LF might be used as line terminators at the end of packets (KERMIT never puts any control characters inside the packets). Also, choose the character to be something you're unlikely to type during your timesharing session. For instance, as Keith Petersen suggests, use ^E. Do this by typing "@I 5" (for ^E) to the TAC. This allows "@" to be transmitted. 2. To send binary files, type "@B O S" and "@B I S" to the TAC (if you already did step 1, then I suppose you would type "^EB O S" and "^EB I S"). I'm not a TAC user myself, so I can't vouch for any of this. - Frank ------- 28-Nov-83 08:28:54-MST,2928;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:28:42-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 25 Nov 83 19:01 EST Received: From Usc-Ecl.ARPA by BRL via smtp; 25 Nov 83 18:54 EST Date: 25 Nov 1983 1549-PST From: Ted Shapin Subject: New Public Domain FORTH-83 Implementation To: Info-cpm@brl, forth%SRI-CSL@sri-nic cc: info-ibmpc%USC-ISIB@sri-nic Postal-address: Beckman Instruments, Inc. Postal-address: 2500 Harbor X-11, Fullerton, CA 92634 Phone: (714)961-3393 Announcing a public domain implementation of FORTH-83. A very fine public domain implementation of FORTH 83 is now available on the Arpanet SIMTEL20 system in the directory MICRO:. Get the file F83-READ.ME for a list of the files and what each contains. This directory contains two implementations, one for the 8080 running CP/M-80 and one for the 8086 (or 8088) running CP/M-86. I have also submitted the 8080 version to the SIG/M users group. This implementation has a CP/M file interface for FORTH screens, a metacompiler, multi-tasking, debugging utilities, and many other features. This implementation is largely due to Henry Laxen and Mike Perry with assistance from some other members of the FORTH Interest Group. F83-READ.ME This lists all of the files and some hints on getting started. (These files are for the 8080 system) F83.HEX A loadable, ready to use 8080 FORTH system including an editor, assembler, and many FORTH utilities. F83.DOC A message from the primary implementors including instructions on how to use F83 to compile itself. META80.BLK The meta source and F83 screens as an ASCII CP/M file. EXTEND80.BLK The extension screens as an ASCII CP/M file. CPU8080.BLK Assembler, debugging and multitasking source as an ASCII CP/M file. (UTILITY.BLK is the same in both 8080 and 8086 systems) UTILITY.BLK The CP/M interface, editor, and high level multitasking support as an ASCII CP/M file. (Now the 8086 system files) F83.CMD A binary, ready-to-use 8086 FORTH CP/M system including an editor, assembler, and many FORTH utilities. F83-86.DOC A message from the primary implementors including instructions on how to use F83 to compile itself. META86.BLK The meta source and F83 screens as an ASCII CP/M file. EXTEND86.BLK The extension screens as an ASCII CP/M file. CPU8086.BLK Assembler, debugging and multitasking source as an ASCII CP/M file. (UTILITY.BLK is the same in both 8080 and 8086 systems) UTILITY.BLK The CP/M interface, editor, and high level multitasking support as an ASCII CP/M file. Ted Shapin. ------- 28-Nov-83 08:29:37-MST,1022;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:29:29-MST Received: From Sri-Nic.ARPA by BRL-VGR via smtp; 26 Nov 83 1:37 EST Received: from USC-ECLB by SRI-NIC with TCP; Fri 25 Nov 83 22:38:05-PST Date: 25 Nov 1983 2235-PST From: Dick Subject: FORTH83 help wanted To: info-cpm@brl-vgr I downloaded the 8080 Forth83 files. In my attempt to re-compile as per the instructions in the F83READ.ME file, when I try to do the sequence: F83 META80.BLK OK BYE I get "stack underflow" very shortly after the OK is entered. This happened on two different 64k CP/M 2.2 systems. Any clues? When I view the indexes of a range of screens ( 0 80 INDEX ) the text starts shifting right, and I do not get the same index line after about # 6 or so, just what looks like pieces of Forth & assembly. Have the .BLK files anything to do with this, or are the screens part of the .COM file? Any help appreciated.. ------- 28-Nov-83 08:32:22-MST,898;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:32:10-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 25 Nov 83 12:45 EST Received: From Rand-Relay.ARPA by BRL via smtp; 25 Nov 83 12:42 EST Date: Thu, 24 Nov 83 16:16:28 CST From: Stan O. Barber Return-Path: Subject: modem2 protocol Received: by TETHYS (AA22194); Thu, 24 Nov 83 16:31:19 CST Received: from TETHYS by RICE (AA02134); Thu, 24 Nov 83 16:36:41 CST To: W8SDZ@mit-mc Cc: info-cpm@brl Message-Id: <1983.11.24.16.16.28.633.22115@Tethys.rice> Via: Rice; 25 Nov 83 9:16-PST Thanks for forwarding the Modem dox by Ward. I believe there is one error. I think that is really 06H and not 05H as stated. At least this is the case in the versions I have used. Thanks again. Stan Barber 28-Nov-83 08:32:34-MST,787;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:32:28-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 26 Nov 83 10:56 EST Date: 26 November 1983 11:02 EST From: David Sternlight Sender: W8SDZ@mit-mc Subject: Security of alds code with MDM714 To: INFO-CPM@brl-vgr Orig-Date: 25 Nov 1983 1400-PST To: info-cpm-request@brl-vgr cc: sternlight@ecl ReSent-To: INFO-CPM@brl-vgr MDM714 (and its predecessors) displays the alternate ld (sprint, etc) number and code on the screen when dialing. A simple fix is to comment out the 'CALL TYPE' instruction in MDM714.ASM after DIALAD2: and add three (3) NOP instructions after it (to keep the code the same length). --david-- 28-Nov-83 08:33:23-MST,992;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:33:18-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Nov 83 12:48 EST Date: Sat, 26 Nov 83 12:39:18 EST From: Keith Petersen To: Mark Crispin cc: cc.fdc@columbia-20.arpa, Info-CPM@brl.arpa, Info-Kermit@columbia-20.arpa Subject: Re: KERMIT and TAC If you do @B I S to the TAC you don't have ANY intercept character at all and it's then impossible to @C (close) the connection between the TAC and your host after you're done. I'm not certain but I think this may leave a "hanging job" on your host. The @I 5 command to set the TAC for control-E intercept works fine with KERMIT for text files and when you are done the TAC reverts to the normal "@" intecept for the next caller so no one will be unhappy with you changing the intercept character for the duration of your connection. --Keith 28-Nov-83 08:33:45-MST,953;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:33:40-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Nov 83 13:00 EST Received: From Sri-Unix.ARPA by BRL via smtp; 26 Nov 83 12:57 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 26 Nov 83 9:39-PST Date: 24 Nov 83 10:25:22-PST (Thu) To: info-cpm@brl From: sri-unix!decvax!duke!rpk%ecsvax.uucp@BRL.ARPA Subject: where is hex.com? Article-I.D.: ecsvax.1582 I need a copy of hex.com and can't find it on the few RCPMs that I've looked at. Can anybody forward a copy or point me to a RCPM that has a copy of it? (Hex.com is a utility that takes a .com file and converts it into .hex format [intel] for transmission through "text-only" transmission facilities. The person at the other end uses load to convert back to a .com file.) Thanks in advance -- -Dick (...decvax!mcnc!ecsvax!rpk) 28-Nov-83 08:34:20-MST,1114;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:34:15-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Nov 83 15:31 EST Received: From Su-Score.ARPA by BRL via smtp; 26 Nov 83 15:22 EST Date: Sat 26 Nov 83 12:22:07-PST From: Mark Crispin Subject: Re: KERMIT and TAC To: w8sdz@BRL.ARPA cc: cc.fdc@COLUMBIA-20.ARPA, Info-CPM@BRL.ARPA, Info-Kermit@COLUMBIA-20.ARPA In-Reply-To: Message from "Keith Petersen " of Sat 26 Nov 83 09:42:56-PST Postal-Address: 725 Mariposa Ave. #103; Mountain View, CA 94041 Phone: (415) 497-1407 (Stanford); (415) 968-1052 (residence) In my humble opinion, any host which fails to hang up the connection when the user logs out should be disconnected from the ARPANET until they fix their software! @ B I S is the means of getting into binary mode on the TAC, and no host should make that mode useless. Disabling the TAC intercept character is necessary if you want true binary I/O. Hosts ought to work well enough so this functionality is usable. ------- 28-Nov-83 08:34:27-MST,557;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:34:23-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Nov 83 16:53 EST Date: Sat, 26 Nov 83 16:44:01 EST From: Keith Petersen To: sri-unix!decvax!duke!rpk%ecsvax.uucp@brl-bmd.arpa cc: info-cpm@brl Subject: Re: where is hex.com? The program to change a .COM file into a .HEX file is called UNLOAD. It's available from most RCPMs. The latest version is probably UNLOAD21.ASM. --Keith 28-Nov-83 08:34:31-MST,804;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:34:27-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Nov 83 17:05 EST Date: Sat, 26 Nov 83 16:54:27 EST From: Keith Petersen To: Info-Cpm@brl-vgr, Info-Kermit@columbia-20 Subject: Re: KERMIT and TAC If the host software is properly written it should be possible for the operating system to send instructions to the TAC, telling it to enter and exit BINARY mode. UMODEM (for UNIX), MODEM (for TOPS-20) and MMODEM (for ITS at MIT) all do this sucessfully, making it unnecessary for the user to "lose control" of his TAC. I frequently connect to several hosts during one TAC session and "losing control" is unacceptable to me. -Keith 28-Nov-83 08:34:43-MST,455;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:34:39-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Nov 83 17:06 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 26 Nov 83 17:00 EST From: ssalzman.es@PARC-MAXC.ARPA Date: 26 Nov 83 10:49:21 PST Subject: VFILER2 To: info-cpm@brl.ARPA Does anybody know where I can get the source code to VFILER2 (Z80 vsn)? TNX. 28-Nov-83 08:34:48-MST,1879;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:34:37-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Nov 83 17:06 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 26 Nov 83 16:59 EST From: ssalzman.es@PARC-MAXC.ARPA Date: 26 Nov 83 9:29:27 PST Subject: Re: The New ZCPR - ZCPR3 In-reply-to: rconn@brl.ARPA's message of Mon, 21 Nov 83 0:21:35 EST To: Rick Conn cc: info-cpm@brl.ARPA, info-micro@brl.ARPA Rick, Hi. So your busy on another ZCPR system. Great! As an extensive user of the system, I have a few commants to make. Regarding ZEX: So far I've had no problem with it. Once I started using it I don't ever want to use SUB2 or anything like that again. I did run into one problem though. I was using it wiwth Kelly Smith's ARCHIVE program and I had some problems. I never found out why or really looked into it. There are probably a few programs that will conflict with it though therefore the submit utility should be an option. There are a couple things about ZEX that I would like to see happen, like the ability to turn on and off user input (^"). It would be handy if it could be made a toggle. I guess getting rid of disk based directories would be ok. I suppose it would save a lot of space. I don't know of any 'bugs' in the system. All the utilities (like VFILER, XDIR, etc.) should be made to obey the restriction of not going into protected user areas. If user area 15 is 'protected' then VFILER and XDIR should ask for the password before looking at or logging into that direct- ory. This should maybe be built into the ZCPR itself (typing A15: should maybe prompt a password). I can't think of anything else off hand. I'll let you know if I do think of anything. Take it easy and good luck! - Isaac. 28-Nov-83 08:35:08-MST,629;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:35:00-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Nov 83 17:55 EST Date: Sat, 26 Nov 83 17:53:19 EST From: Rick Conn To: ssalzman.es@parc-maxc.arpa cc: info-cpm@brl.arpa Subject: Re: VFILER2 VFILER2 is on the SIG/M disks. I haven't uploaded it to SIMTEL20 yet because it is quite large (90K+) and is going to change anyway with ZCPR3. Both the 8080 and Z80 VFILERs have the same source -- you just select a flag as to which version you want. Rick 28-Nov-83 08:35:45-MST,790;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:35:39-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 26 Nov 83 23:15 EST Received: From Usc-Eclb.ARPA by BRL via smtp; 26 Nov 83 23:09 EST Date: 26 Nov 1983 2006-PST From: LHILL@usc-eclb Subject: Hexify ?? To: w8sdz@brl cc: info-cpm@brl Re your recent message about the HEX.COM program, what is really needed is a TOPS20 HEXIFY.EXE. It has now been 4-5 months since I have been able to download any .COM or .?Q? file due to the continuing problem with the TAC I must go through. I am only able to get ASCII files with a capture buffer and TYP or TYPSQ. I know it's not your fault. Has any one written a hexify program???? Lem ------- 28-Nov-83 08:36:49-MST,1270;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:36:30-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Nov 83 1:08 EST Received: From Sri-Unix.ARPA by BRL via smtp; 27 Nov 83 0:58 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 26 Nov 83 21:53-PST Date: 24 Nov 83 22:30:10-PST (Thu) To: info-cpm@brl From: pur-ee!uiucdcs!uiucuxc!delong@ucb-vax Subject: Modem712 on an Apple IIe? - (nf) Article-I.D.: uiucdcs.4126 #N:uiucuxc:27600001:000:667 uiucuxc!delong Nov 24 16:17:00 1983 We have implemented the public domain package "modem712" on a couple of our small CP/M computers. We also have an Apple IIe with a CP/M + card from Advanced Logic System(ALS). We would like to implement modem712 or modem701 or a varient on the IIe. We need to know how to talk to the output ports before we can continue. If someone has already done this, please contact me at 217-352-6511. If not, we will continue to plug away and get more info from ALS in our spare time. Carl E. DeLong Construction Engineering Research Lab {decvax,ucbvax}!pur-ee!uiucdcs!uiucuxc!delong {ihnp4,pur-ee}!uiucdcs!uiucuxc!delong cc: net.micro net.micro.appl net.micro.cpm 28-Nov-83 08:38:32-MST,2822;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:38:18-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Nov 83 12:18 EST Received: From Usc-Isid.ARPA by BRL via smtp; 27 Nov 83 12:12 EST Date: 27 Nov 1983 08:52-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: KERMIT and TAC From: ABN.ISCAMS@usc-isid To: MRC@su-score Cc: w8sdz@brl, cc.fdc@columbia-20, Info-CPM@brl Cc: Info-Kermit@columbia-20 Message-ID: <[USC-ISID]27-Nov-83 08:52:58.ABN.ISCAMS> In-Reply-To: The message of Sat 26 Nov 83 12:22:07-PST from Mark Crispin Mark (also also Keith at W8SDZ): Fully agree with the host properly hanging up/reconfiguring. The KERMIT patch, though is SO very simple. Atchd is my patch I recently sent to a local user who's emulating an IBM PC (kind of) with a Wang PC. Same problem; same fix outta work. David Kirschbaum Toad Hall To: ABN.20E-SP@USC-ISID Subject: Re: TAC X/ON X/OFF In-Reply-To: <[USC-ISID]26-Nov-83 13:42:41.ABN.20E-SP> ------------------------------------------------------------------------ Sir, I don't have the source code of PCKERMIT available now, so I can't move an actual patch over to you. However -- if you can grab the chunk of assembler that actually sends characters out the port when sending packets (in my version its the section with OUTCHR, OUTCH0, OUTCH1, etc...) and move/message it to me, I can put in the patches. What you do is get the character from a register or memory (wherever KERMIT put it)(the character you want to send as part of a packet, that is, and compare it to 40H (the @ sign). If it isn't an @ sign, just go ahead and send it. If it IS -- send it twice!. In my code (8080), it looks like this... outchr: mov a,e ; get the char into A call setpar ; This is the routine that sets parity on ; the char to your desires. I moved it ; up here to keep it out of the TAC loop. mov e,a ; Put the character back into E while we ; use A to check port status. cpi 40h ; compare immediate A with the @ sign. cz outch1 ; Yep - got an @. Call the OUT routine to ; send it the first time, and fall through to ; send it the second time (elegant, no?) outch1: in mnprts ; Get the output ready flat from the Tx ; status port. ani output ; Is the ready bit set? jz outch1 ; Not ready, loop... mov a,e ; Char back into A register outch2: out mnport ; Put it out the modem port (finally). ret ; Return the first time to the OUTCHR ; call, the second time (if there IS a second ; time) to whatever called this. That's all there is to it! Now your code and registers are going to be a bit different, but basically the simple idea works. Have fun... SGM K 28-Nov-83 08:40:00-MST,1420;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:39:07-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Nov 83 14:01 EST Date: Sun, 27 Nov 83 13:54:36 EST From: Keith Petersen To: Info-Kermit@columbia-20 cc: Info-Cpm@brl-vgr Subject: Bug fix for Kermit-80 ver 3.5 There is a bug in the CONNECT (dumb terminal) function of CPMBASE.ASM. It causes continuous NULLs to be sent out to the modem when there are no characters ready from the console keyboard. This bug occurs in all versions except ROBIN or RAINBO or GENER or DMII. Two lines of code were mis-placed. Below is a listing of the corrected area. CONCHR: IF NOT (ROBIN OR RAINBO OR GENER OR DMII) MVI C,DCONIO ; Direct console I/O BDOS call. MVI E,0FFH ; Input. CALL BDOS ENDIF ; NOT (robin OR rainbo OR gener OR dmII) IF ROBIN OR RAINBO OR GENER OR DMII CALL BCONST ; Get the status CALL BCONIN ; Yes, get the character ENDIF ; robin OR rainbo OR gener OR dmII ORA A ; Anything there? <-----corrected JZ RSKP ; No, forget it <-----corrected ANI 7FH ; Keep only 7 bits ........ End of corrected area 28-Nov-83 08:40:05-MST,3016;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:39:16-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Nov 83 14:01 EST Received: From Usc-Isid.ARPA by BRL via smtp; 27 Nov 83 13:55 EST Date: 27 Nov 1983 10:51-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: KERMIT and TAC From: ABN.ISCAMS@usc-isid To: MRC@su-score Cc: w8sdz@brl, cc.fdc@columbia-20, Info-CPM@brl Cc: Info-Kermit@columbia-20 Message-ID: <[USC-ISID]27-Nov-83 10:51:12.ABN.ISCAMS> In-Reply-To: The message of Sat 26 Nov 83 12:22:07-PST from Mark Crispin PCKERMIT users: Here's a patch to PCKERMIT to hopefully solve the TAC intercept character problem with no hassles about resetting TACs. Now, please check this out for me -- I'm an 8080/Z80 hacker and donno nuttin about 8086/8088 code except what I reasoned out of the PCKERMIT source. Regards, David Kirschbaum Toad Hall ;************************System Dependent**************************** ; Put a char in AH to the port. PORT PROC NEAR IF ibmpc outchr: sub cx,cx ; [14 start] mov al,ah ; Parity routine works on AL. [16] call dopar ; Set parity appropriately. [10] mov ah,al ; Don't overwrite character with status. [16] mov dx,03FDH ; Toad Hall note: hokay - now we got the char in ah. Need to test and see ;if it's the infamous TAC intercept character (@ in this case). Sending it ;twice will tell the TAC that it's a true ASCII character for the host: the ;TAC will then send a single @ on to the host, and echo one more back to you. ;If it is, we'll call OUTCH1 to put it out once, and then fall through to :put it out the second time. If it isn't, we'll just send one character. ; PS: Somebody with a manual on this assembler language check this out ; for me - I'm only guessing at the mnemonics since I'm a Z80/8080 hacker. cmp ah,40h ; Is it the @? cz outch1 ; Yep, send it the first time.. ; ...and fall through for the second. ; Else just send it once. [Toad Hall] ;End of Toad Hall TACpatch outch1: in al,dx test al,20H ; Transmitter ready? jnz outch2 ; Yes loop outch1 jmp r ; Timeout outch2: mov al,ah ; Now send it out mov dx,03F8H out dx,al jmp rskp ; [14 end] ENDIF IF Z100 outchr: mov al,ah ; Yes, get the character into al mov cx,0 call dopar ; Set parity appropriately. [10] ; Toad Hall Note: somebody check this for me -- I assume here that ; ah has not been trashed by the DOPAR call above, and the char is ; still in ah. I also assume the BIOS-AUXOUT call don't do nuttin ; to ah or al or wherever the char is being accessed so we can in ; fact call and put it out twice in a row. [Toad Hall] cpi ah,40h ; Is the char an @ (TAC intercept char)? cz bios-auxout ; Yep - send it once... ; ...and fall through to send the 2nd... ; End of Toad Hall TACpatch. outch1: call bios_auxout ; Send the character jmp rskp ENDIF  28-Nov-83 08:40:08-MST,658;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:39:45-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Nov 83 14:13 EST Date: Sun, 27 Nov 83 14:04:47 EST From: Keith Petersen To: LHILL@usc-eclb cc: Info-Cpm@brl-vgr Subject: Re: Hexify for TOPS-20 The problem with your TOPS-20 can be EASILY fixed. It involves a simple patch to the system monitor to correct a bug in the way it negotiates with your TAC. WANCHO@SIMTEL20 or BILLW@SRI-KL have full particulars. It should not be necessary for you to ASCII capture ANYTHING. --Keith 28-Nov-83 08:41:37-MST,866;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:41:33-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Nov 83 22:07 EST Received: From Sri-Unix.ARPA by BRL via smtp; 27 Nov 83 21:57 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 27 Nov 83 18:55-PST Date: 27 Nov 83 16:49:43-PST (Sun) To: info-cpm@brl From: decvax!ittvax!sii!mem@ucb-vax Subject: Aztec library change for CCP overlay Article-I.D.: sii.340 b I have put an article in net.sources which describes how to change the Aztec C library so that you can control whether or not the CCP is overlayed. See it if you are interested. I put it in net.sources because that seems to be the convention. It seems more reasonable to me, however, to put it here. What say? Mark E. Mallett decvax!sii!mem 28-Nov-83 08:42:16-MST,4705;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:41:46-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 27 Nov 83 21:09 EST Received: From Sri-Kl.ARPA by BRL via smtp; 27 Nov 83 21:02 EST Date: Sun 27 Nov 83 18:03:13-PST From: William "Chops" Westfield Subject: TACs and BINARY mode on TOPS20 To: info-cpm@BRL.ARPA, info-kermit@COLUMBIA-20.ARPA The problem is that the current implementation of TOPS20 is not "properly written". It is broken. It isnt even clear that it will work if you give your TAC an @B I S command sequence.... Here is the a description and solution to the BINARY MODE problem on TOPS20. --------------- Date: Mon 1 Aug 83 14:17:59-PDT From: BILLW@SRI-KL.ARPA Subject: [Frank J. Wancho : [pditmars: Binary]] To: info-modemxx@MIT-MC.ARPA, tops20@SU-SCORE.ARPA As some of you may know, there are a series of programs for downloading microcomputers from Tops-20 systems. Recently, a new version of TAC code was installed, and these programs stopped working when used through a TAC. After much searching, this was finally tracked down to a bug in Tops-20 (or a mis-feature) that was agravated by the new TAC code. A patch has been developed (and is enclosed). This patch has been tested at SRI and at SIMTEL20, and should be installed if you have any users who use the MODEM program to download micros over the ARPANet. Bill Westfield ------------- Date: 24 June 1983 12:29 EDT From: Frank J. Wancho Subject: [pditmars: Binary] To: BillW @ SRI-KL Bill, Peter patched my TAC port so that he could capture the TCP headers in a dump. I ran MMODEM on MC first, to demonstrate a working version. Then I ran your MODEM (still 125) on XX. Here's is his results so far. I thought you'd be interested... --Frank -------------------- Date: 24 Jun 1983 11:14:32 EDT (Friday) From: Pieter Ditmars To: fjw cc: taccers at BBN-UNIX, pditmars at BBN-UNIX Re: Binary Frank, Results of the dump proved inconclusive, though something funny seems to be going on. Can't see the first IAC from xx but it should be a "will binary" cause the TAC responds do binary. Then xx says wont binary and the tac gives don't binary. Finally xx sends do binary to which the TAC does not reply. Looks like we got a bug here new tests in progress will msg you when isolated. Pete Date: 27 Jul 1983 18:26-PDT From: William "Chops" Westfield To: Wancho@SIMTEL20 Cc: billw@SRI-KL Here is a bug fix that might help fix the downloading through TAC problem. First, the suspected reason it doesnt work: The 20 sends "WILL BINARY". The TAC receives this and, if binary is not already set, responds with a positive "DO BINARY" (this explains why it will work if you put the TAC in binary mode BEFORE you connect to the host). The 20 monitor receives the "DO BINARY", and is currently set to refuse this option (I consider this a bug, and plan to complain to DEC - It will help if other Net heavyweights complain also), so it sends "WONT BINARY",and the TAC responds "DONT BINARY", leaving things in NON-binary mode. The reason this probably worked in older versions of the TAC code is that the TAC probably ignored the second "DONT BINARY" and just transmitted all 8 bits from the host anyway. Thus this is really a bug in TOPS-20, and not in the new TAC code. Now, here is the fix: In module TTNTDV, at location NVTDOD, change NVTDOD: IFIW!R to NVTDOD: IFIW!RSKP (This can also be done to the binaries, of course, and its relatively safe to do to a running monitor: @MDDT call SWPMWE$x ;write enable swappable monitor NVTDOD/ SETZ RSKP ;make the change call SWPMWP$x ; write protect monitor again ^Z ;exit MDDT ) This will cause TOPS20 to reply "WILL BINARY" whenever it receives "DO BINARY", which chould not cause any problems. The PROPER thing to do is to reply positively only if the program on the other end is reading from the terminal in binary mode, and refuse otherwise. Putting the terminal in binary mode should take care of everything. Unfortunately, the relevant code (NVTMOD) has been commented out of the current monitor. Please let me know if this works... Bill Westfield ------- ------- 28-Nov-83 08:43:40-MST,831;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 08:43:34-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Nov 83 2:48 EST Received: From Mit-Mc.ARPA by BRL via smtp; 28 Nov 83 2:38 EST Date: 28 November 1983 02:43 EST From: lin@mit-ml Sender: LIN@mit-mc Subject: getting files via MDMXXX from TOPS-20... To: info-cpm@brl I guess I am doing a silly thing, but I keep fouling up in trying to use MODEM on TOPS-20. Can someone pls help? in particular, I set up my MDM712 for use as a terminal. Then, I say to TOPS-20 the following @modem s foo.bar TOPS-20 responsd by saying READY TO SEND. I then exit to MDM712 and say RT FOO BAR. This procedure works using MMODEM on ITS, but no luck on TOPS-20. Help? many thanks.. 28-Nov-83 09:06:51-MST,715;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 09:06:46-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Nov 83 1:27 EST Received: From Mit-Ml.ARPA by BRL via smtp; 28 Nov 83 1:17 EST Date: 28 November 1983 01:09 EST From: Herb Lin Subject: MAC and RMAC To: info-cpm@brl Query: Can RMAC do everything that MAC can do? (In other words, when people say I need MAC to assemble something, can I use RMAC to get the same results?) Also, can someone comment about the alleged Z-80 macros which are included in the macro packages for both MAC and RMAC which are supposed to simulate Z-80 instructions? tnx. 28-Nov-83 14:13:35-MST,966;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 14:13:30-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Nov 83 15:42 EST Received: From Mit-Ml.ARPA by BRL via smtp; 28 Nov 83 13:58 EST Date: 28 November 1983 14:00 EST From: Jon P. Albers Subject: RMAC vs. MAC To: lin@mit-mc cc: Info-CPM@brl Herb, according to my CP/M+ manuel, MAC is what you would normally use to assemble and RMAC creates a 'relocatable' code. In the MAC command line where: MAC(or RMAC) filespc.typ $options The H option, which is used to control where the .HEX file goes, is replaced by the option R, which controlls the file: filespc.REL, which is the relocatable code filein hex. So the following: RMAC filespc $PX SB RB Would kill the .PRN file, and put the .SYM and .REL files on drive b: I hope this helped, Jon Albers ALBERS@ML 28-Nov-83 15:22:43-MST,1182;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 15:22:38-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Nov 83 16:40 EST Received: From Sumex-Aim.ARPA by BRL via smtp; 28 Nov 83 16:36 EST Received: from ISL by SUMEX-AIM with Pup; Mon 28 Nov 83 13:35:28-PST Date: Monday, 28 Nov 1983 13:37-PST To: info-cpm@brl Subject: (mis)feature in cp/m+ Reply-to: kevinw@su-dsn From: kevinw@su-dsn Sender: kevinw%isl@BRL.ARPA i have found that cpm allows access to any file in user 0 which has the sys attribute but if you are in any user location OTHER than 0 then the file is given the attribute of r/o. to me this seems a nasty feature in that it forces you to use user 0 for much work where there is a common file which is to be read as well as written... this is a problem in using mince from other user areas... i.e. it won't work since cp/m+ in its (in)finite wisdom crashes your program with a r/o error on file MINCE.SWP... i'm looking into patching mince so that it handles user 0 for the swap but anybody have any ideas or similar probs? thanks, -- Kevin kevinw@su-dsn 28-Nov-83 18:28:50-MST,601;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 18:28:42-MST Received: From Lll-Mfe.ARPA by BRL-VGR via smtp; 28 Nov 83 19:28 EST Date: Mon, 28 Nov 83 16:23 PST From: Maron@LLL-MFE.ARPA Subject: 9918A chip info request To: info-cpm@brl-vgr.arpa Help, help, I remember reading an article on the TI "sprite" chip (TMS 9918A) some time ago. It had construction details-I believe. I also think it was in BYTE mag. but I'm not sure. Can anyone give me some pointers to the article, 9918 info etc. etc. -Thanks in advance -Neil 28-Nov-83 19:22:32-MST,591;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 19:22:25-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 28 Nov 83 20:52 EST Received: From Usc-Eclb.ARPA by BRL via smtp; 28 Nov 83 20:43 EST Date: 28 Nov 1983 1743-PST From: Dick Subject: QBAX info wanted To: info-cpm@brl I recall seeing a message from a QBAX owner here. It was mentioned that a few minor fixes may come out in the next release. I wonder if there has been a new release, and what is the update policy for QBAX? ------- 28-Nov-83 20:06:01-MST,816;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 20:05:52-MST Received: From Mit-Mc.ARPA by BRL-VGR via smtp; 28 Nov 83 21:23 EST Date: Mon 28 Nov 83 21:22:02-EST From: Mark Becker Subject: Re: 9918A chip info request To: Maron@LLL-MFE.ARPA cc: info-cpm@BRL-VGR.ARPA In-Reply-To: Message from "Maron@LLL-MFE.ARPA" of Mon 28 Nov 83 20:25:51-EST Neil - The August 1982 issue of BYTE magazine had an article dealing with the TMS-9918A graphics chip. This was their LOGO issue with a bunch of turtles on the cover. Since then I have seen other graphics IC's, mostly marketed by TI. Does anyone else on the net have pointers to these newer chips? Mark ARPA: [CENT.MBECK@MIT-OZ] ------- 28-Nov-83 20:26:03-MST,695;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Mon 28 Nov 83 20:25:55-MST Received: From Radc-Tops20.ARPA by BRL-VGR via smtp; 28 Nov 83 21:41 EST Date: Mon 28 Nov 83 21:40:41-EST From: JOEL ROBERTSON/EE/ROBINS TAC Subject: Re: 9918A chip info request To: Maron@LLL-MFE.ARPA cc: info-cpm@BRL-VGR.ARPA In-Reply-To: Message from "Maron@LLL-MFE.ARPA" of Mon 28 Nov 83 20:25:50-EST THE ARTICLE YOU WANT IS "HIGH-RESOLUTION SPRITE-ORIENTED COLOR GRAPHICS" BY STEVE CIARCIA, BYTE VOL. 7 NO. 8, AUG 82, PP 57-80. I HAVE THIS ISSUE IF YOU NEED A COPY OF THE ARTICLE. -JOEL- ------- 29-Nov-83 08:38:13-MST,1007;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 29 Nov 83 08:38:07-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 29 Nov 83 6:08 EST Received: From Rutgers.ARPA by BRL via smtp; 29 Nov 83 1:41 EST Date: 29 Nov 83 01:42:16 EST From: FRIEDMAN@RU-BLUE.ARPA Subject: Tops-20 modem. To: info-cpm@BRL.ARPA I tried to use Modem to transfer a file between 2 tops 20 machines. These machines are connected together via a 1200 baud terminal line. This is what I tried. Modem ctty# Modem t this brought me over to the other machine. next I typed Modem s foo ^E brought me back to the first machine. and now modem r foo to get the file. This worked fine for small files. If the file was longer than 16 blocks the receiving end aborted after 10 tries. I examined the incoming characters and everything seemed to be working fine. Does anyone know whats wrong? -Gadi ------- 29-Nov-83 08:39:08-MST,920;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 29 Nov 83 08:38:55-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 29 Nov 83 6:10 EST Received: From Sri-Unix.ARPA by BRL via smtp; 29 Nov 83 5:47 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 29 Nov 83 2:39-PST Date: 27 Nov 83 4:30:19-PST (Sun) To: info-cpm@brl From: pur-ee!uiucdcs!uiuccsb!eich@ucb-vax Subject: FDC/HDC S-100 Hybrid? - (nf) Article-I.D.: uiucdcs.4169 #N:uiuccsb:4800001:000:336 uiuccsb!eich Nov 27 02:06:00 1983 Looking for a FDC/HDC all on one board for the S-100 bus. Data Systems Design makes a winchester/floppy/tape three-in-one for Multibus; anyone know of anything that good for -696? I want to handle IBM PC format floppies; ST506 will do for the HD. Please send mail. Thanks Brendan Eich uiucdcs!uiuccsb!eich eich.uiuc@rand-relay 29-Nov-83 08:39:16-MST,735;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 29 Nov 83 08:39:11-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 29 Nov 83 6:10 EST Received: From Sri-Unix.ARPA by BRL via smtp; 29 Nov 83 5:58 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 29 Nov 83 2:53-PST Date: 27 Nov 83 16:50:38-PST (Sun) To: info-cpm@brl From: ihnp4!ihopa!burris@ucb-vax Subject: ZCPR2 utilities request. Article-I.D.: ihopa.113 I am looking for a source of the major ZCPR2 utilities within the chicago area with XMODEM downloading capability. Please send mail if you can help out. Thanks, -- Dave Burris ..!ihnp4!ihopa!burris AT&T Bell Labs, Naperville, Il. 29-Nov-83 08:40:27-MST,1169;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 29 Nov 83 08:40:21-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 29 Nov 83 7:50 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 29 Nov 83 7:47 EST Date: Tue, 29 Nov 83 07:48 EST From: Platteter.Henr@PARC-MAXC.ARPA Subject: Re: Tops-20 modem. In-reply-to: "FRIEDMAN@RU-BLUE.ARPA's message of 29 Nov 83 01:42:16 EST" To: FRIEDMAN@RU-BLUE.ARPA cc: info-cpm@BRL.ARPA Your problem is with the 1200 baud. The software knows when the receive buffer is full but has no way to tell the machine that it is receiving the data from that it should not send any more data. There are two solutions. The first is to use 300 baud. This allows the receiving computer time to dump the buffer without loosing any data. The other solution is to use a modem program that allows you to insert delays before the sending of each line of data. I have used both successfully. I find that there is a lot less playing around if I just use 300 baud but if this option is not open to you you will have to use the other route. Later, DALE 29-Nov-83 08:40:42-MST,783;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 29 Nov 83 08:40:39-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 29 Nov 83 8:28 EST Received: From Parc-Maxc.ARPA by BRL via smtp; 29 Nov 83 8:22 EST Date: Tue, 29 Nov 83 08:22 EST From: Thieret.WBST@PARC-MAXC.ARPA Subject: GodBout Disk 1 BIOS To: Info-Cpm@brl.ARPA cc:Thieret.WBST@PARC-MAXC.ARPA I recently got a DISK 1 up and running but the thing really bangs the disk heads around. Does anybody have a fix for that? Also, since the Disk 1 can do DMA to extended memory - has anyone written a cacheing BIOS for this controller? That would also solve the problem with the heads bashing around. Thanks, Tracy. (Thieret.WBST @ PARC-MAXC.ARPA) 29-Nov-83 13:39:18-MST,939;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 29 Nov 83 13:39:15-MST Date: Tue, 29 Nov 83 15:12:10 EST From: Dave Towson (info-cpm) To: info-cpm@brl-vgr, info-micro@brl-vgr Subject: [Maron: TMS9916 info request] Can anyone help answer this question? Dave Towson info-cpm-request@brl-vgr ----- Forwarded message # 1: Received: From Lll-Mfe.ARPA by BRL-VGR via smtp; 28 Nov 83 19:21 EST Date: Mon, 28 Nov 83 16:16 PST From: Maron@LLL-MFE.ARPA Subject: TMS9916 info request To: info-cpm-request@brl-vgr.arpa Help help, I remember reading an article that gave construction details or some kind of info on the "sprite" chip-TI TMS9918A (not 9916 as the subject line would suggest). I think it was in BYTE but I can't find it. Can anyone give me some pointers. --thx in advance -Neil ----- End of forwarded messages 29-Nov-83 16:31:13-MST,569;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 29 Nov 83 16:31:09-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 29 Nov 83 18:13 EST Received: From Brl-Bmd.ARPA by BRL via smtp; 29 Nov 83 18:01 EST Date: Tue, 29 Nov 83 14:43:02 EST From: Greg the Hogg To: info-cpm@brl cc: greg@brl-bmd Subject: CPM tools on UNIX Hello, What happened to the micro: directory on simtel20? More importantly the programs like umodem.c and uc.c? Thanks 29-Nov-83 16:42:56-MST,626;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 29 Nov 83 16:42:52-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 29 Nov 83 18:24 EST Received: From Cmu-Cs-G.ARPA by BRL via smtp; 29 Nov 83 18:12 EST Date: 29 Nov 1983 16:54-EST From: David.Anderson@CMU-CS-G.ARPA Subject: TMS9918A To: info-cpm@brl, info-micro@brl Message-Id: <438990866/dba@CMU-CS-G> The August 1982 Byte (p. 57 -- the "Logo" issue) had a construction article on building a sprite card for the Apple ][ based on the TMS9918A. That's probably what you're thinking of. --david 29-Nov-83 17:23:06-MST,942;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Tue 29 Nov 83 17:23:01-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 29 Nov 83 18:28 EST Received: From Mit-Ml.ARPA by BRL via smtp; 29 Nov 83 18:21 EST Date: 29 November 1983 16:21 EST From: Jon P. Albers Subject: Re:RMAC vs. MAC To: lin@mit-mc cc: Info-CPM@brl Herb, I would suppose that the only difference between .HEX files via MAC and .REL files via RMAC is that the .REL file is set up so it makes no direct memory calls but instead had some sort of formula that takes care of the memory addressing. I'm not sure of it, but I would assume so. Jon Albers ALBERS@ML (If anyone can correct me, I would be interested. I have only used MAC and ASM and am interested in finding out exactily what RMAC is. I can go only by the book and my own thoughts) 30-Nov-83 08:38:35-MST,489;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 30 Nov 83 08:38:30-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Nov 83 1:12 EST Date: Wed, 30 Nov 83 1:05:57 EST From: Keith Petersen To: Greg the Hogg cc: Info-Cpm@brl-vgr Subject: Re: CPM tools on UNIX The directory on SIMTEL20 was renamed to MICRO: and you'll find umodem.c, uc.c, and others there. 30-Nov-83 08:40:03-MST,1953;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 30 Nov 83 08:39:55-MST Received: From Hi-Multics.ARPA by BRL-VGR via smtp; 30 Nov 83 2:42 EST Date: 30 November 1983 01:40 cst From: Eaton.HFED@hi-multics Subject: max disk size To: info-cpm@brl-vgr The answer to a very perplexing question has never beenn satisfactorily answered until now. The question was.... HOW MUCH INFORMATION CAN BE STORED ON A HARD DISK ADDRESSED AS ONE LOGICAL DEVICE? The answer is a MAXIMUM of 8,388,608 bytes and ABSOLUTELY NO MORE than 8,388,608 bytes. I had heard the 8M figure before but no one really explained it so that I understood why. My bios allowed me to make it as large as I wanted to so why not make my 10M hard disk a single logical device. After firing up a quick and dirty "BASIC" program to finish filling out the remaining 3.8M of so far unused disk space (6.2M was already filled with "good" stuff), I let it rip. And "rip" it did. I fully expected to see a disk full message after the mythical 8M or at the 10M limit which my bios was genned for. Well folks... I eventually got the disk full message. However.... It was printed out after my handy-dandy "BASIC" program had written "this is a test message" throughout my entire DIRECTORY! OH $!%*!!! GUESS WHO ORDERED QBAX ONE DAY TOO LATE? As to why this happened I found out with much digging that CP/M will only handle 65,536 sectors (128 bytes each). If you multiply that out quickly in your head the not so mythical figure of 8M pops out with blinding clarity. so.... BEWARE! THE 65,537TH SECTOR IS SECTOR 0! THE VERY 1ST SECTOR IN YOUR PRECIOUS DIRECTORY. MOAN.... SO IF YOUR PUSHING RELATIVELY CLOSE TO THE 8M LIMIT WITH YOUR LOGICAL HARD DISK DRIVES. RECHECK YOUR CALCULATIONS TO INSURE YOU HAVEN'T ALLOCATED 1 BLOCK TOO MANY. signed 8megmax a.k.a Jesse (Mpls, Mn) 30-Nov-83 08:43:02-MST,2917;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 30 Nov 83 08:42:52-MST Received: From Hi-Multics.ARPA by BRL-VGR via smtp; 30 Nov 83 4:21 EST Date: 30 November 1983 03:20 cst From: Eaton.HFED@hi-multics Subject: zcpr2 bugs To: info-cpm@brl-vgr I was unable to get ZCPR2 to respond quickly enough to xoff even after installing mod 3. I eventually patched my bios to intercept xon, xoff and ^P. This feature can be turned on and off with a com file and works great now. I would recommend this to anyone whether or not they are using ZCPR2. ^P can be used "anytime" you so desire to turn on the printer or conversely turn it off. The xon/xoff patch also allowed me to synchronize my "no scroll" key on my Visual 55. (after an xoff my bios ignores anything but xon) The "no scroll" key sends xon and xoff alternately. Smooth scroll mode is very xon/xoff intensive and now works like a charm with ZCPR2 also. I had several other problems with ZCPR2 which were corrected by mod 3. However one of them persisted. DU2 would go into a loop sending spaces to the screen when I typed DU2 //. The problem was discovered to be garbage in the B reg after a call to CONOUT. The author of DU2 expects that reg to contain the same info that was in it before the call was made. Guess what. My bios had little or no concern for the contents of the B reg upon exiting CONOUT. Again the fix was to modify my bios. However in this case I feel that it is up to the programmer to save any pertinent registers before making a call to BDOS or BIOS. You be the judge... DU2 is considerably more versatile than DUU but also runs considerably slower than DUU. I suspect it may be connected with the increased number of options in DU2. I use them both depending on my needs at that time. (I use DUU to tune my phase lock loop read clock by margining.) The copy program MCOPY is a bit to verbose for my taste and I don't use it for that reason. It should also have the option of informing you of a possible file overwrite on the target disk. Due to the amount of documentation supplied (excellent I might add) there should be a quick and dirty installation cookbook to get a minumum configuration up and going FAST. A note should be added to warn users that the documentation should be concantenated before printing it with WORDSTAR. Otherwise the page numbers don't match the table of contents. (I didn't find that out until I had printed ALL the documentation.) I hope this wasn't too nitpicky. It is not meant to be an indictment of ZCPR2. Quite the contrary. Only an effort to help make an EXCELLENT product better. Thanks much Rick and the rest of you dedicated ZCPR2 contributers Keep up the good work Jesse (Eaton.HFED -at HI-MULTICS) p.s. I can't use the "at" sign (it means kill line here) 30-Nov-83 08:47:41-MST,1601;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 30 Nov 83 08:47:35-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Nov 83 7:02 EST Received: From Sri-Unix.ARPA by BRL via smtp; 30 Nov 83 6:53 EST Received: from Usenet.uucp by sri-unix.uucp with rs232; 30 Nov 83 3:44-PST Date: 28 Nov 83 15:48:53-PST (Mon) To: info-cpm@brl From: decvax!ittvax!dcdwest!sdcsvax!noscvax!mplvax!cdl@ucb-vax Subject: Re: Transformers and European Current Article-I.D.: mplvax.124 In-Reply-To: Article <13899@sri-arpa.UUCP> A Sola Transformer is a tuned resonant-circuit device. As such, it is designed to work over a small range of frequencies, typically +/- 5% (57-63 Hz). Over this range, the output voltage will vary 1.5 times as much as the input frequency varies, all other things being constant. Running your Solas on nominal 50 Hz, all bets are off. You are lucky that they didn't just burn up in a large puff of bad-smelling smoke. Seriously, Sola does make 50Hz transformers, and possibly you could re-tune yours by adding capacitance in the appropriate places. I have used Sola transformers for many years in seagoing applications, and have muttered about the poor frequency control of the shipboard power, but at least they try to keep it at 60Hz. For a concise explanation of the working of these transformers, see "Electronic Transformers and Circuits," Ruben Lee, Wiley 1955, pp. 252-3. Carl Lowenstein Marine Physical Lab., U.C. San Diego {ucbvax,philabs}!sdcsvax!mplvax!cdl mplvax!cdl@nosc 30-Nov-83 09:10:31-MST,958;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 30 Nov 83 09:10:27-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Nov 83 9:52 EST Received: From Columbia-20.ARPA by BRL via smtp; 30 Nov 83 9:46 EST Date: Wed 30 Nov 83 09:47:56-EST From: Bill Catchings Subject: Hexify for Tops-20 To: Info-CPM@BRL.ARPA In answer to LHILL's question, there is a hexify program (by that name no less) that exists for Tops-20. While I agree Kermit and other programs should be able to cope with things like a TAC, there are times when it is nice to have a work around. The program was written by Bruce Tanner and can be found in the directory PS: at Columbia-20 on the ARPAnet. I've never used it myself, but the 8080 and Z80 crosscompiler for Tops-20 by Bruce works very well. I assume the hexify program works as well. -Bill Catchings ------- 30-Nov-83 09:21:08-MST,631;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 30 Nov 83 09:21:04-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Nov 83 9:53 EST Received: From Usgs1-Multics.ARPA by BRL via smtp; 30 Nov 83 9:51 EST Date: 30 November 1983 09:47 est From: LSchwarz.Activate@reston Subject: For Glen Marianko please To: info-cpm@brl cc: LSchwarz.Activate@reston Could not reply to your usb-vax - so have to use this method. Please send the info and brochure to: Louis J. Schwarz U. S. Geological SUrvey 924 Reston, VA 22092 Thanks in adadvance, 30-Nov-83 13:35:52-MST,4627;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 30 Nov 83 13:35:39-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Nov 83 14:16 EST Date: Wed, 30 Nov 83 14:03:01 EST From: Keith Petersen To: Info-Cpm@brl-vgr Subject: Dysan note: Using floppy backside REVERSING MEDIA ON SINGLE HEAD FLEXIBLE DISK DRIVES typed by Keith Petersen, W8SDZ, from information supplied by Dysan Corporation There has been a tendency by some end users to economize by attempting to use the media on both sides in a single head disk drive. We must not lose sight of the fact that the value of the data stored on diskettes exceeds the cost of the media by a wide margin. Loss of data on either read or write means time delays, reconstruction of lost data, and customer dissatisfaction with the system, drive and/or media manufacturer. All of this can be avoided in advance if the end user is made aware of the whys and why nots. HEAD SHOE AND PAD OPERATION The relationship of the head to the media is such that when the jacket is properly inserted, and all interlocks are satisfied, the head is loaded onto the media on the recording side, and a felt loading pad is applied to the non-recorded side. In normal operation, a gradual build-up of oxide will accumulate on the pressure pad. There might even be some wear on the non-recorded side due to a scouring action of the oxide impregnated pad. If the media is reversed, the scouring action will now occur on the prime recorded side, and the previously scoured side is now presented to an abrasive wearing by the contaminated load pad. Since this data is not being read, there is not any means of detecting the amount of wear or the loss of data. While a catastrophic failure might not occur, it is possible that some drop-out or other read error might go undetected. Worse yet, is the possibility that the error condition might be intermittent, which makes the entire operating system suspect. Another adverse effect of reversing the media, is caused by reversing the direction of rotation of the media against the pressure pad. This reversal of direction is apt to "break off" any build-up of oxide particles. This presents a potential loose contaminent situation. The net effect of this reversing (or flipping) action over a period of time is to reduce performance and increase the probability of drop outs and errors. DISKETTE TENSIONING On most Floppy Disk Drives, when the diskette is properly inserted and operation has begun, pressure is applied to the jacket on both sides so that proper tension is created on the flexible media prior to the recording head. This also provides a wiping action of the liner material against the flexible media. When the jacket is reversed (or flipped), the direction of rotation is reversed, breaking loose any extraneous particles built-up by prior wiping. Thus, reversing the media increases the probability of extraneous contamination and again increases the possibility of errors. TWO HEAD DRIVES The above problem areas do not occur on two head drives that are designed for two sided applications. On a two head drive, the pressure pad has been replaced by a second head mounted in a ceramic shoe. The operation now consists of a head-media-head relationship. The soft pressure pad with possible oxide build-up has been eliminated. The diskette tensioning apparatus is the same on one and two head drives. Since media spin direction is not reversed by flipping, the oxide break-off problem does not occur. SUMMARY The foregoing summarizes the reasoning why Dysan and major OEM suppliers of diskette drives do not recommend two sided media for one head drive application. Dysan feels that the potential operating problems would make an unwarranted reflection on our reputation by using media in an unsuitable fashion. When IBM introduced the 3740 diskette, they intentionally interlocked reversal possibilities by offsetting the index hole from the centerline. IBM does not make a reversable diskette. Dysan does test and supply two sided media for operation in two head (two sides) disk drives. 30-Nov-83 14:48:06-MST,632;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 30 Nov 83 14:48:02-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Nov 83 15:43 EST Received: From Brl-Bmd.ARPA by BRL via smtp; 30 Nov 83 15:31 EST Date: Wed, 30 Nov 83 15:27:04 EST From: Greg the Hogg To: info-cpm@brl cc: greg@brl-bmd Subject: MDM714 and the MAX-80 Hello, I was just looking at the new MDM714 program and found that the overlay file for the max-80 (the one I own) is missing. There was one for MDM712 will it still work for MDM714? Thanks 30-Nov-83 20:09:31-MST,1551;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 30 Nov 83 20:09:26-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Nov 83 21:45 EST Received: From Usc-Isid.ARPA by BRL via smtp; 30 Nov 83 21:34 EST Date: 30 Nov 1983 18:22-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: Hexify for Tops-20 From: ABN.ISCAMS@usc-isid To: G.WBC3@columbia-20 Cc: Info-CPM@brl Message-ID: <[USC-ISID]30-Nov-83 18:22:32.ABN.ISCAMS> In-Reply-To: The message of Wed 30 Nov 83 09:47:56-EST from Bill Catchings Confirm Bill Catching's comments on sometimes needing a hexify program. Working through a TAC still gives me problems with binary files since, all rumors and facts to the contrary, my g------ed TAC will NOT reset itself once I disconnect, and I lock up the bloody unmentionable port until my TAC owners go and kick the front panel or something. Soooo .. I HEXIFY com files regularly. Incidentally, my regular assemblers don' like HEXIFY-produced hex files so very much, but if I load them into DDT and then save them -- perfect! Don't let the visual appearance of a HEXIFY-produced file scare you, either. Sure, each line of hex is almost as wide as an 80-col screen (much different from HEX files produced by regular CP/M assemblers), but not to worry -- DDT handles them just fine (guess it's a function of the 32-bit word (well, kind of a 32-bit word) the DEC uses -- don't really care; it works!). Regards, David Kirschbaum Toad Hall 30-Nov-83 20:21:28-MST,1209;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 30 Nov 83 20:21:23-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Nov 83 21:46 EST Received: From Usc-Isid.ARPA by BRL via smtp; 30 Nov 83 21:36 EST Date: 30 Nov 1983 18:32-PST Sender: ABN.ISCAMS@usc-isid Subject: Re: MDM714 and the MAX-80 From: ABN.ISCAMS@usc-isid To: greg@brl-bmd Cc: info-cpm@brl Message-ID: <[USC-ISID]30-Nov-83 18:32:24.ABN.ISCAMS> In-Reply-To: The message of Wed, 30 Nov 83 15:27:04 EST from Greg the Hogg Gregg, I used the 712 version overlay for my Decision I with MDM714, and had NO problems at all. The whole idea of that overlay format, I think, is to enable massive changes in the body of the program, yet leave the first part with all the overlay stuff alone. They even left a couple of spare EQUs there for future growth, so until they eat that up, the overlays should still be OK. I like MDM714 for its excellent copy capability while the remote computer is typing or scrolling data (I work with mainframes mostly, not with other micros running Christensen protocol programs). David Kirschbaum Toad Hall 30-Nov-83 20:28:00-MST,535;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Wed 30 Nov 83 20:27:57-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 30 Nov 83 21:46 EST Date: Wed, 30 Nov 83 21:39:07 EST From: Rick Conn To: Greg the Hogg cc: info-cpm@brl, greg@brl-bmd Subject: Re: CPM tools on UNIX There is now a major directory on SIMTEL20. Since the programs in were UNIX-based, they are now filed under . Rick 10-Nov-83 09:52:27-MST,1417;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 10 Nov 83 09:52:23-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Dec 83 0:55 EST Received: From Mit-Ml.ARPA by BRL via smtp; 9 Dec 83 21:48 EST Date: 9 December 1983 21:54 EST From: Herb Lin Subject: information useful to cpmland on ASM and REZ. To: info-cpm@brl Date: 9 Dec 83 1639 EST (Friday) From: George.Wood at CMU-CS-A To: Herb Lin Re: RESOURCE and REZ... Herb; ASM will take tdl mnemonics except for the non-8080 z80 instructions; (that's because tdl starts with the intel 8080 instruction set & adds more --in the same style-- to cover the extra instructions used by the z80). If you try assembling them, you will get an error message; If you really want to, you can then translate the z80 instructions into 8080 instructions. (there are macro's for doing this with the MAC assembler). Most software that doesn't explicitly require a z-80 to run use only the 8080 instruction set (which is also compatible with 8085's): So when these are disassembled to tdl mnemonics, the disassembly should contain only the intel mnemonic 8080 instructions. This means you won't have to do any z-80 translation. REZ runs on z-80's under cpm. I think Christiansen wrote it in 8080 assembler so it should run on 8080's and 8085's too. George 10-Nov-83 09:52:46-MST,1156;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 10 Nov 83 09:52:42-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Dec 83 0:55 EST Received: From Usc-Eclb.ARPA by BRL via smtp; 9 Dec 83 23:41 EST Date: 9 December 1983 20:41-PST (Friday) Sender: TLI@usc-eclb From: Tony Li To: Info-cpm@brl Cc: dda@cmu-cs-c, ciaraldi@rochester Subject: Re: CP/M Media Compatibility Reply-to: Tli@usc-eclb Home: 1275 W. 29th #211, Los Angeles, Ca. 90007 (213) 737-8168 Hi, Yes Mike, you got that discussion about CP/M media compatibility perfectly correct. However, let me add one little other note: Digital Research intends to support the CP/M-80 disk format until doomsday. (By this, I mean all operating systems which are planed in the forseable future - about 5 years). This portability extends also to CP/M-68K. However, realize that MOST CP/M-86 systems use 5 1/4" diskettes, so in one way, DDA, your salesman was correct. Cheers, Tony Li ;-) Digital Research Inc. P.s. This is not a policy statement. Just knowledge from an employee. 10-Nov-83 09:53:42-MST,2836;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 10 Nov 83 09:53:35-MST Received: From brl-gateway2.ARPA by BRL-VGR via smtp; 10 Dec 83 2:00 EST Received: From Ucb-Vax.ARPA by BRL via smtp; 10 Dec 83 1:49 EST Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by UCB-VAX.ARPA (4.22/4.16) id AA21679; Fri, 9 Dec 83 21:47:56 pst Received: by ucbpopuli.CC.Berkeley.ARPA (4.13/4.8) id AA27751; Fri, 9 Dec 83 21:49:23 pst Date: Fri, 9 Dec 83 21:47:14 PST From: The tty of Phil Lapsley Message-Id: <8312100547.AA07952@D.CC.Berkeley.ARPA> Received: by D.CC.Berkeley.ARPA (4.8/4.8.2) id AA07952; Fri, 9 Dec 83 21:47:14 PST Arpa-Address: jlapsley%D.CC@Berkeley To: ciaraldi@rochester, info-cpm@brl Subject: U. S. Robotics S-100 / Password Mike, et al. Yes, just this afternoon I got a call from a friend, and we talked for a while, and then I hung up to call him back later. When I hung up, the U.S.R. S-100 jumped into the circuit and sent an answer tone (it then decided that the dial tone was another modem and tried to talk to it for a while, without much success). I have found that the same thing happens if I switch-hook or click on my home made hold button. I haven't noticed it happening when I *call* somebody, but I haven't had it for very long. I'd be willing to bet that it will, however. If I recall, when one calls a long distance party, there is a brief reversal of polarity (this is the same reason why the touch-tone pads on some pay phones don't work when one places a long distance call). This may make the modem think that there is an incoming call. It seems to me that there are about three solutions. First, you could set up your BIOS to tell the modem not to auto-answer. I don't think too much of this idea (my terminal program, though, does do this, and when I switch-hook or whatever, I get a RING result code back). Second, you could put in a switch between the phone line and the modem, so that you could switch the modem out of the circuit when you don't want it there (which is what I am getting close to doing). Third, if you are a hardware hacker, you could do as I have done and write to U.S. Robotics and ask for a schematic. It must be that they are using really brain- damaged ring-detection circuitry, and some modifications might be in order here. Whatever option you choose, it strikes me as if none of them should be necessary. I would suggest writing to U.S. Robotics (1123 West Washington Blvd., Chicago, IL, 60607) and complaining about this. Perhaps if enough owners do, they will consider doing a bit of re-work on some of their products. Good luck, and let me know what happens. Phil (jlapsley%D.CC@Berkeley) 10-Nov-83 10:05:25-MST,601;000000000000 Return-Path: Received: from BRL-VGR by SIMTEL20.ARPA with TCP; Thu 10 Nov 83 10:05:22-MST Received: From Simtel20.ARPA by BRL-VGR via smtp; 10 Dec 83 11:35 EST Date: Fri 9 Dec 83 20:30:55-MST From: Rick Conn Subject: To: info-cpm@BRL-VGR.ARPA All of the ZCPR2 subdirectories under on SIMTEL20 have now been consolidated into the one subdirectory named . Also, the SYSLIB files which were in the ZCPR2 subdirectories have been consolidated into the one subdirectory named . Rick -------