1-Nov-83 08:57:30-MST,862;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
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 <RMS.G.EH%MIT-OZ@MIT-MC.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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) <rbn@brl-vgr>
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:
<vortex!lauren@rand-unix>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <MEAD@usc-eclb>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <JOSEPH@RU-BLUE.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <W8SDZ@simtel20>
To: David Towson (CSD) <towson@amsaa>
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) <towson at AMSAA>
The source for MDM712 is now available on SIMTEL20 in both squeezed
(binary) and normal ASCII format:
MICRO:<CPM.MODEM7>MDM712.AQM (the squeezed file)
MICRO:<CPM.MODEM7>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: <info-cpm-request@BRL-VGR.ARPA>
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 <Schauble@mit-multics>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <W8SDZ@mit-mc>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <WANCHO@simtel20>
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:<SIGM.VOL000>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: <info-cpm-request@BRL-VGR.ARPA>
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 <W8SDZ@simtel20>
To: JOEL ROBERTSON/EE/ROBINS TAC <ROBERTSON@RADC-TOPS20.ARPA>
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 <ROBERTSON at RADC-TOPS20.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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. <Heiby@hi-multics>
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 <Heiby @ HI-Multics>.
3-Nov-83 08:20:08-MST,891;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
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 <BANDY@mit-ml>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <W8SDZ@simtel20>
To: Herb Lin <LIN@mit-ml>
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 <LIN at MIT-ML>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <W8SDZ@simtel20>
To: Charles Garthwaite <CRG@WASHINGTON.ARPA>
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 <CRG at WASHINGTON.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <CCVAX.revc@nosc>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <rconn@brl>
To: info-cpm@brl
cc: info-unix@brl
Subject: UNIX S/W Repositories on SIMTEL20
SIMTEL20 now contains a <UNIX> directory. The programs related to
file transfers between UNIX and CP/M are located in MICRO:<UNIX.CPM>,
the MENU programs are in MICRO:<UNIX.MENU>, and general utilities
like CLMAN and DIR are in MICRO:<UNIX.UTILS1>.
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: <info-cpm-request@BRL-VGR.ARPA>
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 <rconn@brl>
To: info-cpm@brl
cc: info-unix@brl
Subject: More on UNIX Stuff
The <UNIX.CPM> 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: <info-cpm-request@BRL-VGR.ARPA>
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 <PLEHN@mit-mc>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <POURNE@mit-mc>
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 <CCVAX.revc at nosc>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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) <strom@brl-bmd>
To: Jeffrey Shulman <SHULMAN@rutgers.arpa>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <STORK@mit-mc>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <w8sdz@brl-bmd>
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:<CPM.DSKUTL>DDD.ASM
MICRO*<CPM.DSKUTL>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: <info-cpm-request@BRL-VGR.ARPA>
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) <cpmlist@brl-vgr>
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>cpm.dirlst" local_file_name
get "micro:<cpmug>cpmug.dirlst" local_file_name
get "micro:<sigm>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 <cpm> 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:<cpm.modem7> mdm712.com" mdm712.com
get "micro:<cpmug.vol001>assign.asm" assign.asm
get "micro:<sigm.vol001>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
<cpm.hex>. Files in the <cpm> 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 <cpm.squsq> 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:<cpm.z2doc>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 <cpm.squsq>, or there are several host-based unsqueezers in the
<cpm> archive (see for example, directory <cpm.tops20>). 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: <info-cpm-request@BRL-VGR.ARPA>
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 <FCDSSASD%USC-ECLB@sri-nic>
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: <info-cpm-request@BRL-VGR.ARPA>
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) <strom@brl-bmd.ARPA>
cc: Jeffrey Shulman <SHULMAN@rutgers.ARPA>, 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: <info-cpm-request@BRL-VGR.ARPA>
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 <stan.rice@rand-relay>
Return-Path: <stan.Rice@Rand-Relay>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <w8sdz@brl>
To: Stan Hanks <stan.rice@rand-relay>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <cc.fdc@COLUMBIA-20.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <FCDSSASD%USC-ECLB@sri-nic>
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: <info-cpm-request@BRL-VGR.ARPA>
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) <hcarter@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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) <strom@brl-bmd>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <SHahn@SUMEX-AIM.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <LIN@mit-ml>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <ctrl>-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 <ctrl>-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: <info-cpm-request@BRL-VGR.ARPA>
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: <WANCHO.11966639495.BABYL@SIMTEL20>
From: "Frank J. Wancho" <WANCHO@simtel20>
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>CPM.DIRLST.
Here's a sample:
Filename (MICRO:) Type Size CRC
(bytes)
<CPM.6502>6502.SIMLBR COM 75904 074AH
<CPM.6502>6DASM.MAC ASCII 2659 3E16H
<CPM.6502>D6502.MAC ASCII 11753 C978H
<CPM.APPLE>APBDSC.PATCHS ASCII 7371 F65EH
<CPM.APPLE>APBOOT.MAC ASCII 1173 CF3AH
...
--Frank
14-Nov-83 08:51:01-MST,1270;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
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 <PLEHN@mit-mc>
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:<CPM.DIRUTL>, 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:<CPM.DIRUTL>. Thanks.
Al Plehn
14-Nov-83 08:51:14-MST,1533;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <stdio.h>
#include <fcntl.h>
#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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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) <strom@brl-bmd>
To: Herb Lin <LIN@mit-ml>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <SHahn@SUMEX-AIM.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <LIN@mit-ml>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <LIN@mit-ml>
Subject: other people running on G&G systems...
To: info-cpm@brl
From:Sam Hahn <SHahn at SUMEX-AIM.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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. <Heiby@hi-multics>
Subject: BDS-C CDB package help?
To: info-cpm@brl
cc: cpm.sv <Heiby.AVDNSWE@hi-multics>
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 <Heiby @ HI-Multics>.
14-Nov-83 09:19:39-MST,813;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
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: <STRAZ.11967476688.BABYL@MIT-OZ>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <POURNE@mit-mc>
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 <LIN at mit-ml>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <W8SDZ@mit-mc>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <POURNE@mit-mc>
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: <info-cpm-request@BRL-VGR.ARPA>
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. <Heiby@hi-multics>
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 <Heiby @ HI-Multics>.
15-Nov-83 08:38:21-MST,558;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
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 <LIN@mit-ml>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <LIN@mit-ml>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <v.jody@ucla-locus>
To: Herb Lin <LIN@mit-ml>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <ciaraldi@Rochester.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <LIN@mit-ml>
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 <automatically> find the DBs.
16-Nov-83 11:58:59-MST,1148;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
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 <SHahn@SUMEX-AIM.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <LIN@mit-ml>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <v.jody@ucla-locus>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <STRAZ.11967476688.BABYL@MIT-OZ>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <LIN@mit-ml>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <SHahn@SUMEX-AIM.ARPA>
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) <strom@brl-bmd>" 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: <info-cpm-request@BRL-VGR.ARPA>
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 <rconn@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <SHahn@SUMEX-AIM.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <POURNE@mit-mc>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <GZ@mit-mc>
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 <LIN at mit-ml>
Date: 16 November 1983 19:53 EST
From: Herb Lin <LIN at mit-ml>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <WANCHO.11968454285.BABYL@SIMTEL20>
From: "Frank J. Wancho" <WANCHO@simtel20>
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>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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <POURNE@mit-mc>
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 <DJB%MIT-OZ at MIT-MC.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <CCVAX.gil@nosc>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <w8sdz@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <RCONN@SIMTEL20.ARPA>
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:<CPM.VAXVMS>.
The following is a display of this directory:
MICRO:<CPM.VAXVMS>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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) <towson@amsaa>
To: Frank J. Wancho <WANCHO@simtel20>
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: <info-cpm-request@BRL-VGR.ARPA>
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) <towson@amsaa>
To: Herb Lin <LIN@mit-ml>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <W8SDZ@mit-mc>
Subject: SD-77 now available
To: Info-Cpm@brl-vgr
The latest version of SD is now available on SIMTEL20 as:
MICRO:<CPM.DIRUTL>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: <info-cpm-request@BRL-VGR.ARPA>
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 <W8SDZ@mit-mc>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <W8SDZ@mit-mc>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <W8SDZ@mit-mc>
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 <rconn@BRL> is the one to contact.
--Keith
21-Nov-83 12:22:10-MST,3218;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
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 <W8SDZ@mit-mc>
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 <in Cal>). 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.) <an alternate way of dealing with this problem
is to use the 4 MHz clock from pin 6 of U87, instead the 5 MHz
clock from pin 5 of U86 so things don't heat up so much; the
difference between 5 and 4 MHz is insignificant>.
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <rconn@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <dag%ucbarpa@berkeley>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <jlapsley%D.CC@berkeley>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <abc@brl-bmd>
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 <ron@brl-vgr>
To: Mark Horton <cbosgd!mark@ucb-vax>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <w8sdz@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <rconn@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <w8sdz@brl>
To: jim@rand-unix
cc: Info-Cpm@brl-vgr
Subject: Re: MODEM 7?
All MICRO:<MC.whatever> directories on SIMTEL20 have been changed to
MICRO:<CPM.whatever>. Frank Wancho sent out a message announcing this
but guess it got lost on its way to you. The one you want is
MICRO:<CPM.MODEM7> 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: <info-cpm-request@BRL-VGR.ARPA>
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 <w8sdz@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <STERNLIGHT%USC-ECL@sri-nic>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <w8sdz@brl>
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:<CPM.MODEM7> 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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <rconn@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <w8sdz@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <Wegeng.Henr@PARC-MAXC.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <CCVAX.ty@nosc>
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: <info-cpm-request@BRL-VGR.ARPA>
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) <towson@amsaa>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <WANCHO.11970005848.BABYL@SIMTEL20>
From: "Frank J. Wancho" <WANCHO@simtel20>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <rconn@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <MRC@SU-SCORE.ARPA>
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 <cc.fdc@COLUMBIA-20.ARPA>" 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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <MRC@SU-SCORE.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <malis@bbn-unix>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <cc.fdc@COLUMBIA-20.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <BEC.SHAPIN@usc-ecl>
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:<CPM.FORTH-83>.
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: <info-cpm-request@BRL-VGR.ARPA>
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 <MEAD%USC-ECLB@sri-nic>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <sob.rice@rand-relay>
Return-Path: <sob%TETHYS.Rice@Rand-Relay>
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 <ack> 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: <info-cpm-request@BRL-VGR.ARPA>
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 <STERNLIGHT%USC-ECL@sri-nic>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <w8sdz@brl>
To: Mark Crispin <MRC@su-score.arpa>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <MRC@SU-SCORE.ARPA>
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 <w8sdz@brl>" 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: <info-cpm-request@BRL-VGR.ARPA>
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 <w8sdz@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <w8sdz@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <rconn@brl.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <rconn@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <MRC@SU-SCORE.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <w8sdz@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <MRC@SU-SCORE.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <w8sdz@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <BILLW@SRI-KL.ARPA>
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 <FJW @ MIT-MC>: [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 <FJW @ MIT-MC>
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 <pditmars at BBN-UNIX>
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 <BillW @ SRI-KL>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <LIN@mit-ml>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <ALBERS@mit-ml>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <MEAD@usc-eclb>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <CENT.MBECK%MIT-OZ@MIT-MC.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <ROBERTSON@RADC-TOPS20.ARPA>
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-
<ROBERTSON@RADC-TOPS20>
-------
29-Nov-83 08:38:13-MST,1007;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
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 <FRIEDMAN@RU-BLUE>
-------
29-Nov-83 08:39:08-MST,920;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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) <cpmlist@brl-vgr>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <greg@brl-bmd>
To: info-cpm@brl
cc: greg@brl-bmd
Subject: CPM tools on UNIX
Hello,
What happened to the micro:<cpm.unix> 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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <ALBERS@mit-ml>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <w8sdz@brl>
To: Greg the Hogg <greg@brl-bmd>
cc: Info-Cpm@brl-vgr
Subject: Re: CPM tools on UNIX
The directory on SIMTEL20 was renamed to MICRO:<UNIX.CPM> and you'll
find umodem.c, uc.c, and others there.
30-Nov-83 08:40:03-MST,1953;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <G.WBC3@COLUMBIA-20.ARPA>
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:<KERMIT>
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: <info-cpm-request@BRL-VGR.ARPA>
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, <LJ>
30-Nov-83 13:35:52-MST,4627;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
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 <w8sdz@brl>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <greg@brl-bmd>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <G.WBC3@COLUMBIA-20.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <greg@brl-bmd>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <rconn@brl>
To: Greg the Hogg <greg@brl-bmd>
cc: info-cpm@brl, greg@brl-bmd
Subject: Re: CPM tools on UNIX
There is now a major <UNIX> directory on SIMTEL20. Since the programs in
<CPM.UNIX> were UNIX-based, they are now filed under <UNIX.CPM>.
Rick
10-Nov-83 09:52:27-MST,1417;000000000000
Return-Path: <info-cpm-request@BRL-VGR.ARPA>
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 <LIN@mit-ml>
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 <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: <info-cpm-request@BRL-VGR.ARPA>
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 <Tli%usc@BRL.ARPA>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <jlapsley%D.CC@berkeley>
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: <info-cpm-request@BRL-VGR.ARPA>
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 <RCONN@SIMTEL20.ARPA>
Subject: <CPM.ZCPR2>
To: info-cpm@BRL-VGR.ARPA
All of the ZCPR2 subdirectories under <CPM> on SIMTEL20 have now
been consolidated into the one subdirectory named <CPM.ZCPR2>. Also,
the SYSLIB files which were in the ZCPR2 subdirectories have been
consolidated into the one subdirectory named <CPM.SYSLIB>.
Rick
-------