CP/M/CPM_CDROM.iso/simtel/archives/cpm/8412-1.txt

Text File | 1993-02-12 | 116KB | 2,812 lines

17-Dec-84 08:31:44-MST,3638;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 17 Dec 84 08:31:29-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  17 Dec 84 9:54 EST
Date: 17 Dec 1984  07:54 MST (Mon)
Message-ID: <KPETERSEN.12072156212.BABYL@SIMTEL20>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: Forth-83 version 2 for PCDOS/MSDOS available

Filename            Type     Bytes     CRC

Simtel20 directory MICRO:<CPM.FORTH-83>
F83V2-MS.LBR.1            COM    228736  9FFEH

is an (untested) version of Forth-83 V2 for PCDOS /MSDOS - see announcement
from Ted Shapin <[e-mail]>:

F83V2-MS.LBR contains F83.COM, a public domain implementation of FORTH-83 that
is ready to run. It also contains source files in squeezed format.  I have
squeezed them using the public domain utility NSQ and you can unsqueeze them
with the NUSQ utility. Squeezed files have a Q in the file type.

The original Laxen-Perry distribution had these files squeezed with a program
that took hours (!) to run to unsqueeze. AUSQ will run in minutes and the
squeezed files take up less space than the original distribution disk. Make B:
(or C:) your default drive. Have plenty of room on your default drive and then
type A:AUSQ A:filename.BQK to make filename.BLK on your default drive.

CRCK4 or CRCK is a hash checksum program to help you tell if you have good
copies of the files.  Type CRCK4 *.* (or CRCK *.*) and see if what you have
agrees with the values listed below. This should assure you that you have a
good copy of the disk.

F83.COM is the ready to run FORTH system.

The MS-DOS version is set up to use the IBM-PC cursor positioning codes.
This won't work on other MS-DOS machines such as the TI Professional.
To fix this, start F83, then type EDITOR DUMB and you can use the editor
commands as though you have a dumb terminal.

The VIEW word expects certain source blocks to be on drive A: and certain
source files to be on drive B:.  If you have a hard disk system, you can
follow the directions in README.PC to recompile your system with all of the
source blocks on your hard disk and the VIEW file numbers will be set up
correctly.

CRCK ver 4.2B (MS DOS VERSION )  Here are the files on the MS-DOS disk:
CTL-S pauses, CTL-C aborts


--> FILE:  F83     .COM         CRC = D3 3E  FORTH system compiled.
--> FILE:  README  .1ST         CRC =        This file
--> FILE:  NUSQ    .COM         CRC = DD 00  The unsqueeze program
--> FILE:  NSQ     .EXE         CRC = 23 CA  The squeeze program
--> FILE:  README  .PQ          CRC = 2D F6  Original F83 instructions
--> FILE:  F83-FIXS.TQT         CRC = 24 CD  Changes from F83 v.1.0
                         These "blocks" are the F83 sources squeezed
--> FILE:  KERNEL86.BQK         CRC = 2B 60  Kernel source
--> FILE:  META86  .BQK         CRC = 5B BE  Metacompiler source
--> FILE:  CPU8086 .BQK         CRC = 4D 6E  8086 dependent code
--> FILE:  EXTEND86.BQK         CRC = F5 C0  Extensions source
--> FILE:  UTILITY .BQK         CRC = ED 3E  The UTILITY source
                         These blocks are applications
--> FILE:  HUFFMAN .BQK         CRC = 7C B7  A VERY slow compression program
--> FILE:  CLOCK   .BQK         CRC = 47 A2  Source for a calendar example
--> FILE:  EXPAND86.BQK         CRC = 3F F6  Original source to expand .HUF
--> FILE:  BASIC   .BQK         CRC = 37 E6  A BASIC compiler in FORTH-83


Ted Shapin. July 31, 1984.
17-Dec-84 08:49:27-MST,3325;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 17 Dec 84 08:49:14-MST
Received: From csnet-pdn-gw.ARPA by AMSAA via smtp;  17 Dec 84 10:07 EST
Received: from gmr by csnet-relay.csnet id a003264; 17 Dec 84 10:09 EST
Date:     Mon, 17 Dec 84 09:52 EST
From:      [e-mail]
MMDF-Warning:  Parse error in preceding line at CSNET-RELAY.ARPA
To:       [e-mail]
Subject:  ideal CP/M environment

There was message on INFO-CPM last week from Chuck (last name?)
suggesting and ideal CP/M environment. His selection did not agree
with my own preferences so I thought a counter-suggestion might be
useful. How about a general discussion of pros & cons of particular
choices?

1) I use CP/M Plus in preference over CP/M 2.2 or ZCPR. It is a big
   improvement in speed over 2.2 in a floppy-only environment and
   should run like a bandit with a RAM disk. The RSX capability of
   CP/M Plus provides expansion possibilities that have not been
   touched yet. The only advantage I see in ZCPR is the named
   directories. TURBODOS is a good alternative in a multi-processor
   system.

2) For my money, the MAC/RMAC/LINK/SID(or ZSID) combination is hard to
   beat for assemby language development. I haven't used the SLR
   Systems package so I cannot comment about it. Anyone care to
   enlighten me?

3) PASCAL and Modula 2 - I don't use them so don't have a choice.

4) The BDS C compiler is one of the best around - close to UNIX C
   as well as being fast and cheap. It doesn't have FLOATs built
   in but an optional library package does provide this if you
   want it.

5) I use VEDIT for program editting and like it quite well. I haven't
   used MINCE but if it is a reasonable subset of EMACS, it should be
   a good choice also.

   For word processing editting, I use WORDSTAR. The only improvement
   I would ask for would be a capability for displaying italics,
   proportional spacing, etc. (if your display system can handle it)
   without generating a print version.

There were a couple of categories missing in the previous message:

6) a spelling checker - SPELLSTAR is a reasonable one to work with
   WORDSTAR

7) Database ? anything better than DBASE II ?

8) spreadsheet? CALCSTAR is no great shakes but is adequate.

9) For modem control, terminal emulation, and file transfer, I use
   MEX. I have used MODEM7, MDMxxx, TERM II, and some others, but
   MEX is by far the best - very reliable and it has a powerful
   command language. The new version (MEX 2.0) should be even better.
   The only other contender might be KERMIT, but I haven't tried it
   on a micro.

10) MicroShell was a neat product for the CP/M 2.2 environment but
   its capabilties have been for the most part included in CPM Plus.
   Is anyone working on a window-based replacement for the CCP ?

11) How about graphics utilities ? any suggestions ?  DRI appears
   to have dropped GSX-80 as a product.


One thing to notice in all this is the large amount of good software
available in the public domain. This is what makes me think that CP/M
is a fantastic environment.


    Bob Haar
    G.M. Research Labs

[opinions expressed here are not necessarily those of G.M., etc.]
17-Dec-84 15:06:11-MST,976;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 17 Dec 84 15:06:06-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  17 Dec 84 16:31 EST
Received: from mit-mc.arpa by BRL-AOS.ARPA id a001058; 17 Dec 84 16:33 EST
Received: from a.ARPA by LANL.ARPA (4.12/4.7)
    id AA16475; Mon, 17 Dec 84 14:16:01 mst
Received: by a.ARPA (4.12/4.7)
    id AA19488; Mon, 17 Dec 84 14:16:15 mst
Date: Mon, 17 Dec 84 14:16:15 mst
From: Richard Thomsen <[e-mail]>
Message-Id: <[e-mail]>
Subject: Request for MACRO-80 assembler information
Newsgroups: ar.info-cpm
Distribution: na
To: [e-mail]

Hi,

    I got a copy of the Small-C compiler, but it produces assembly
language in MACRO-80.  Is MACRO-80 in the public domain?  If so, does
anyone have a copy of the assembler (source, but if it is written in
MACRO-80, then the HEX version also)?

    Thanks in advance.

                        Richard Thomsen


17-Dec-84 18:26:15-MST,2264;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 17 Dec 84 18:25:58-MST
Received: From usc-ecl.arpa.ARPA by AMSAA via smtp;  17 Dec 84 19:57 EST
Date: Mon 17 Dec 84 14:39:36-PST
From: Ted Shapin <[e-mail]>
Subject: Sources for FORTH-83 Public Domain
To: [e-mail], [e-mail], [e-mail]
Postal-address: Beckman Instruments, Inc.
Postal-address: 2500 Harbor X-11, Fullerton, CA 92634
Phone: [phone]

Version 2 of the public domain implementation of the FORTH-83 standard
known as F83 is available on the Arpanet in versions for CP/M-80,
CP/M-68K, and MS-DOS.

F83 is largely the work of Henry Laxen and Mike Perry with some assistance
from many members of the FORTH Interest Group.  The system contains many
utilities, an editor, an assembler, and a meta-compiler that makes
recompilation of the system, or porting to a new system possible.  I have
uploaded the systems as three large library files.  You will need a library
utility such as LU or LUPC to extract individual members.

The files are on SIMTEL20 in MICRO:<CPM.FORTH-83> and are:

                F83V2-80.LBR  for CP/M 8080
                F83V2-68.LBR  for CP/M 8086
                F83V2-MS.LBR  for MS-DOS 8088

For those who are unable to FTP files from the Arpanet, I have submitted the
first 2 versions to SIG/M and the MS-DOS version to PC-BLUE.  These can be
addressed at Box 97, Iselin NJ  08830 and should be available as soon as they
can be added to their catalog.

No Visible Support Software
Box 1344
2000 Center St.
Berekeley, CA. 94706.

can supply 8080 CP/M on 8" single-sided single density
           8086 CP/M on 8" single-sided single density
           68000 CP/M on 8" single-sided single density
           8088 PC-DOS on 5.25" double-sided double density
for $25 each. (These are the versions I squeezed and made into .LBR files).

A somewhat similar version known as F83X for the Apple IIE is available from
Wil Baden, Orange County FIG, 339 Princeton Circle, Costa Mesa, CA. 92626
for $25 payable to Orange County FIG.
This has extensions that are not in the Laxen-Perry model.

Ted Shapin. Dec. 17, 1984



-------
18-Dec-84 08:08:51-MST,630;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 08:08:45-MST
Received: From almsa-1.arpa.ARPA by AMSAA via smtp;  18 Dec 84 9:30 EST
Date:     Tue, 18 Dec 84 8:15:24 CST
From:     Crede Edens <[e-mail]>
To:       [e-mail]
cc:       [e-mail]
Subject:  Need a BREAK key.


I noticed someone made a request for information about a "break" key the
other day.  I also need this on my NEC APC.  I haven't found a work around
for it and would appreciate any information from you experts out there.

thanks in advance

Crede Edens

18-Dec-84 08:42:50-MST,1302;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 08:42:43-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  18 Dec 84 10:07 EST
Date: Tue 18 Dec 84 08:03:18-MST
From: Rick Conn <[e-mail]>
Subject: Writing ZCPR3 Programs
To: [e-mail]

    There has been a recent increase in interest by people to write
ZCPR3 programs, and I would like to encourage this.  One thing that Echelon
and I and really pushing in this regard is the idea that ZCPR3 programs
are CONSISTENT with each other in a variety of ways -- how the options
are invoked, how online help is obtained, etc.  It is this consistency
that adds to the value of the ZCPR3 system; in particular, the classic problems
found under so many CP/M programs, such a "what options are available"
and "how do I invoke the options", are not encountered.  I really recommend
that those wanting to write ZCPR3 programs consider this and read the
Echelon newsletters.  One of the newsletters, in particular, outlines
all the major facets that enhance the consistency of the toolset.  In general,
the newsletters serve to answer the common questions and provide
much insight into the operational and user-interface aspects of the system.

        Rick
-------
18-Dec-84 09:44:43-MST,2488;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 09:44:35-MST
Date:     Tue, 18 Dec 84 11:06:54 EST
From:     Dave Towson (info-cpm-request) <[e-mail]>
To:       [e-mail]
Subject:  Addition to archive blurb.

Fellow CP/Mers - Earl Boebert at HI-MULTICS has suggested that since there
will be greater use of CP/M library (LBR) files in order to conserve space on
the MICRO: disk-pack at SIMTEL20, it would be helpful to include in the blurb
a description of these files.  I heartily agree.  Thanks for the suggestion,
Earl.  Here is the addition.  It goes in the FILE TYPES section, and I have
included some of the surrounding text, so that those who care to do so can
insert it into their copies of the blurb.


------------------------------------------------------------------------------
as a binary file, and then unsqueezed.  The unsqueezing can be done on a 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> and
<UNIX> archives (see for example, directories <CPM.TOPS-20> and <UNIX.CPM>).

     CP/M library files, which can be identified by their ".LBR" extensions,
combine several regular CP/M files into a single binary file which contains
an internal directory of its contents.  They are created using the CP/M
library utility, LUxxx.COM (where "xxx" is three digits giving the current
version number), or some other compatible utility.  Because these are binary
files, they are stored in ITS binary format, and they must be retrieved using
the special procedures described elsewhere in this message.  LUxxx and a newer
compatible program called NULUxx (where "xx" is the version) can be found in
directory MICRO:<CPM.CPMLIB>.  C-language source code for a compatible UNIX
utility called LAR (library archiver) is in directory MICRO:<UNIX.CPM>.

     Although the type of storage used for a particular file can usually be
inferred from the file-name, this is not always true.  It is a good idea to
check the appropriate "crclst" file to ascertain the storage format used for
each file of interest.  This applies to all of the archives except <UNIX> and
<ADA>, where ALL files are presently stored in ASCII.  Now, and for the
------------------------------------------------------------------------------



Dave Towson
[e-mail]


18-Dec-84 14:19:06-MST,1395;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 14:19:00-MST
Received: From mit-mc.arpa.ARPA by AMSAA via smtp;  18 Dec 84 15:29 EST
Date: Mon, 17 Dec 1984  20:58 EST
Message-ID: <ZZZ.RLK.12072276996.BABYL@MIT-OZ>
From: "Robert L. Krawitz" <[e-mail]>
To:   [e-mail]
Subject: procedure calls in Z-80 or CP/M-based systems
cc:   [e-mail]
reply-to: [e-mail]

I'm doing a term paper on the procedure call, and I'm trying to gather
information on how procedure calls are performed in various
implementations of various languages.  I'd be most grateful if anyone
either knows something about specific cases or can point me to
literature on such.  I would be particularly interested in information
about how various versions of C do this, as there are a large number
and can form a good database for a comparative study.  Most useful
would be notes from the companies selling such software or articles
from the trade press, and pointers to such.  Note that by procedure
call I am referring to a C or Lisp style procedure, not a subroutine
such as Basic.

Please reply to me directly.  I am on the list but will be going home
for two weeks beginning Friday, and will temporarily remove myself
from the list at that time.

Thanks in advance for any help.

Robert^Z

18-Dec-84 16:01:36-MST,1043;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 16:01:26-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  18 Dec 84 17:31 EST
Received: from mit-multics.arpa by BRL-AOS.ARPA id a010589; 18 Dec 84 17:29 EST
Date:  Tue, 18 Dec 84 17:25 EST
From:  "Paul E. Woodie" <[e-mail]>
Subject:  Break key
To:  [e-mail]
Message-ID:  <[e-mail]>

I in the past have used the rather crude method of switching to a slower
line speed and sending a few characters then switching back to the
original line speed.  This worked with GTE Telenet, but I don't know
about other systems.  I know this is rather crude, but being rather
crude is better than suffering through many lines (or pages) of unwanted
information.  The only other solution that I know of is using some
hardware-specific feature of the particular computer that you happen to
be using.  There is no implementation of a break key in regular CP/M.

--Paul Woodie
18-Dec-84 22:03:02-MST,598;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 22:02:58-MST
Received: From ucla-locus.arpa.ARPA by AMSAA via smtp;  18 Dec 84 23:32 EST
Date: Tue, 18 Dec 84 13:22 CST
From: "Jeff M. Gibson" <cepu!bradley![e-mail]>
Subject: archive blurb
To: [e-mail]

would you please send me a copy of 'archive blurb'.  CP/M-80 prefered.

thanks in advance,

Jeff Gibson              UUCP: {cepu,ihnp4,noao,uiucdcs}!bradley!jmg
Bradley University        ARPA: cepu!bradley!jmg@UCLA-LOCUS
Peoria, IL 61625            PH: [phone]

18-Dec-84 22:13:05-MST,1909;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 22:12:59-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  18 Dec 84 23:45 EST
Received: from usenet by BRL-TGR.ARPA id a007462; 18 Dec 84 23:42 EST
From: ken <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Warning: RIPOFF from GDL
Message-ID: <[e-mail]>
Date: 16 Dec 84 00:56:00 GMT
Nf-ID: #N:hpcvlo:14900004:000:1331
Nf-From: hpcvlo!ken    Dec 15 16:56:00 1984
To:       [e-mail]


Warning : Potential Rip-Off !!!!!!!!!!!!!!!!!

Have you had any contact with Graphics Development Laboratories
                2832 Ninth Street
                Berkeley CA. 94710
                [phone]

A Prof. at Oregon State University with the Dept. of Forest Science
tried to purchase one of their graphics boards for S100 bus and has
been having a very difficult time.  Unfortunately he sent them a
check for about $2000 after reviewing their literature, ads in BYTE,
and other similar products.  They acknowledge having got the $$ in
September of '84.  However they have not produced any equipment,
graphics board, or refund.  He has called them numerous times trying
to get some satisfaction.  Alas over the phone they continually give
him dead end responses.

If any of you have any suggestions for how to deal with this company,
I'd appreciate the suggestions,  which I will pass on to my friend at
OSU.  Also I highly suggest that if you are connsidering dealing with
this company that you also consider throwing your money down a hole
first.  You may get better results.

All Responses welcome, especially from people in the Berkeley area, or
from anyone associated with this company.  I will quickly post any
results that may serve to clear the badly tarnished reputation of GDL.

                -Ken Bronstein
                 hp-pcd!ken
                 [phone]  X4133
18-Dec-84 22:14:55-MST,1086;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 22:14:50-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  18 Dec 84 23:45 EST
Received: from usenet by BRL-TGR.ARPA id a007379; 18 Dec 84 23:40 EST
From: craig <[e-mail]>
Newsgroups: net.micro.cpm
Subject: EPROM burner wanted
Message-ID: <[e-mail]>
Date: 14 Dec 84 15:47:00 GMT
Nf-ID: #N:hpcvlo:14900003:000:524
Nf-From: hpcvlo!craig    Dec 14 07:47:00 1984
To:       [e-mail]


I'm looking for an EPROM burner to hang off my S-100 CPM system.  It
can be plug in or RS-232, etc just so it can program lots of different
size proms (1k, 2k, 4k, etc).  If it is internal, I would prefer it
to use I/O addresses rather than take up memory space.  Anyone have
any exerience to pass on?? (by the way, I have only seen ads for the
SDS and SSM units).

Does anyone know know where I can get card guides for my Vector Graphics
Vector 1?  Is VG still around?
                Thanks,
                Craig Durland
                ...!hp-pcd!craig
18-Dec-84 23:39:51-MST,1360;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 23:39:44-MST
Received: From rice-gateway.ARPA by AMSAA via smtp;  19 Dec 84 1:10 EST
Received: by rice.ARPA (AA00839); Wed, 19 Dec 84 00:05:54 CST
Date:     Tue, 18 Dec 84 23:26:55 CST
From: Paul Milazzo <[e-mail]>
Subject:  Kaypro floppy format?
To: [e-mail]
Message-Id: <[e-mail]>

I want to exchange data on 5 1/4" floppies with someone who has a
Kaypro II running CP/M 2.2, but I can't figure out the Kaypro's disk
format.  If someone could describe the format in sufficient detail that
I could add a new Disk Parameter Block template to my BIOS, I'd be home
free.  Thus, I need to know the density, sides, TPI, sector size, skew
factor, number of reserved tracks, allocation block size, etc.

Any information someone could supply would be a big help.  If it
matters, I have an H89 running CP/M 3 with a Magnolia 77316 floppy
controller.

Please reply directly to me, and spare the List these boring details.
I'd be happy to summarize should anyone express interest.

                Many Thanks,
                Paul G. Milazzo
                Dept. of Computer Science
                Rice University, Houston, TX

ARPA:    [e-mail]
UUCP:    {cbosgd,convex,cornell,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzo
19-Dec-84 11:39:49-MST,1389;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 19 Dec 84 11:39:42-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  19 Dec 84 12:56 EST
Received: from usenet by BRL-TGR.ARPA id a020907; 19 Dec 84 12:40 EST
From: [e-mail]
Newsgroups: net.micro.cpm
Subject: Re: EPROM burner wanted
Message-ID: <[e-mail]>
Date: 19 Dec 84 14:23:00 GMT
Nf-ID: #R:hpcvlo:14900003:acf4:10000016:000:799
Nf-From: acf4!greenber    Dec 19 09:23:00 1984
To:       [e-mail]

<>

I use a really nice EPROM burner:

Programmer 4+
Periphco
1659 Scott Blvd #1
Santa Clara, CA 95050
(408)-244-5214

It costs about $200.  Features:
    -    Programs 2716, 2732, 2764, 27128's
    -    RS232
    -    Selectable as Data set or terminal
    -    All Dc is generated on board (you do have to buy you're own
            transformer!)
    -    Handles the "A"'s too: 21/25 VDC
    -    ZIF on board
    -    Software is pretty good: Program, Read, Verify. Dumps in
            ASCII and HEX
    -    CP/M and other os's

It does not come in a pretty box, it is pretty slow, it isn't as nice as
the $5000 DataIo I use sometimes, but it meets my "home/hobby/business"
purposes.

I'm not attached to Periphco, except at the wrist and ankles.

Call them and ask for the spec sheet.


Ross M. Greenberg  @ NYU   ---->  allegra!cmcl2!acf4!greenber  <----
19-Dec-84 15:45:12-MST,836;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 19 Dec 84 15:45:05-MST
Received: From ucb-vax.arpa.ARPA by AMSAA via smtp;  19 Dec 84 17:22 EST
Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.24/4.40)
    id AA04673; Wed, 19 Dec 84 14:22:56 pst
Received: by ucbarpa.ARPA (4.24/4.40)
    id AA01905; Wed, 19 Dec 84 14:23:29 pst
Date: Wed, 19 Dec 84 14:23:29 pst
Message-Id: <[e-mail]>
From: Phil Lapsley <[e-mail]>
To: [e-mail]
Subject: S-100 Byte CPU card data

     Does anyone know where I might obtain a manual on the
old S-100 Byte Indutries 8080 CPU board?  I have one, and a
schematic for it, but I'd be interested in getting more
information on it.  Thanks.

                    Phil Lapsley
            ([e-mail], ...!ucbvax!phil)
19-Dec-84 22:53:16-MST,630;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 19 Dec 84 22:53:11-MST
Received: From mit-mc.arpa.ARPA by AMSAA via smtp;  20 Dec 84 0:33 EST
Date: 20 December 1984 00:32-EST
From: Jerry E. Pournelle <[e-mail]>
Subject:  Warning: RIPOFF from GDL
To: [e-mail]
cc: [e-mail]
In-reply-to: Msg of 16 Dec 84 00:56:00 GMT from ken <ken%hp-pcd.uucp at BRL-TGR.ARPA>

please have your friend send me a letter with the details at
BYTE, (and send them a carbon of the letter to me).  That may or
may not help but it won't cost much.
JEP

20-Dec-84 03:10:18-MST,1141;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 03:10:13-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  20 Dec 84 4:46 EST
Received: from usenet by BRL-TGR.ARPA id a003345; 20 Dec 84 4:40 EST
From: Shields <[e-mail]>
Newsgroups: net.general,net.wanted,net.micro.cpm
Subject: Mattel Intellivoice info wanted
Message-ID: <[e-mail]>
Date: 18 Dec 84 02:42:02 GMT
To:       [e-mail]



Recently we found a bargain at the local J.C. Penney store - they were liqui-
dating their stock of Mattel Intellivoice modules for $5 each - used to be
$75-100 a year ago. Inside is a General Instruments SP-0256 speech processor
chip and what appears to be a programmable sound generator chip, as well as
filters, pre-amp, etc.  We were interested in interfacing one of these modules
to a micro, but don't have any documentation.  Does anyone out there in netland
have a schematic and/or any other documentation for the Intellivoice module?
Thanks in advance.

        Jeff Shields (pur-ee!shields)
        Tim Miller   (pur-ee!miller)
20-Dec-84 07:25:46-MST,4932;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 07:25:12-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  20 Dec 84 8:51 EST
Date: 20 Dec 1984  06:52 MST (Thu)
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail], [e-mail]
Subject: 2400 baud modems

This is file 2400BAUD.TXT - relayed from the RCPM circuit:
--Keith

From:  Wayne Masters, Potpourri sysop
       [phone] 300/1200/2400 baud
       San Jose, Ca.

Subject: New 2400 baud modems         8/19/84

       Many of you have asked technical questions about the 2400 baud
modems now on the market (and more being introduced monthly).  As most
of you know by now Irv Hoff and I have been beta testing 2400 baud for
several months.  The test results are amazing to say the least.  Running
controlled tests on standard dial-up phone lines with random "noisy
connections", the number of "hits" on a given file transfer is less by
a factor of 10 using 2400 baud vs 1200 baud.  So it is concluded that
2400 baud technology is working and will soon be available on most
commercial and private dial-up systems.  Now, what is a "standard" 2400
baud modem?

       You will no doubt see various technical descriptions of a given
2400 baud modem touting it's features.  Be sure the modem you choose has
this specification:

       CCITT recommendation for a V.22 bis modem communicating at 2400 bps.

       Further explanation of this CCITT standard:
Frequency- Bell 212A
Encoding modulation-  16 level psk  (quadrature AM or QAM)

       This sounds a lot like the Bell 212A standard for 1200 baud--and it
is.  The difference is in the encoding or modulation scheme.  Bell 212A 1200
baud uses 4 level psk and 2400 baud uses 16 level psk.  If you "listen" to
the 2400 baud carrier it will sound exactly like the familiar 1200/212A-
like "static" or a scratchy noise.

       Features to look for in your search for the "right" 2400 baud modem:

1.  Does it retain 300 baud bell 103 capability?  (most offer 1200 baud as
    a "fallback")
2.  Is it "smart"--a biggy if you intend to call other systems a lot.
3.  Does it offer autoanswer--a biggy if you run a remote system.
4.  Price--a real biggy

       So far, none of the modems on the market offer all these features
in a "standalone" modem.  That is one big reason why Irv Hoff and I have
been involved with Racal-Vadic--not only beta testing to prove 2400 baud
technology...but to get the features most users prefer designed into the
modem.  Others may follow some day but Racal Vadic will introduce their
"standalone" modem in time for Christmas 84 with the following features:

1.  Smart-autodialing.  It will recognize both the Hayes and Vadic commands.
2.  0-300 baud at both Bell 103 and Vadic protocols
3.  1200 baud at both Bell 212A and Vadic protocols
4.  2400 baud CCITT V.22 bis
5.  Price is expected to be $695.00 retail

      The first release will be an external RS-232 model.  Early 1985 will
see the single card slot version for IBM PC's and compatiables.

       In order for 2400 baud to be in "great demand" there must be systems
available for the users to access.  I am working with Racal-Vadic to
identify RCP/M and RBBS systems where 2400 baud modems could be placed to
generate public interest in 2400 baud.  Sysop's should contact Potpourri
at 408-378-7474 if interested in participating.

       Now about software to support 2400 baud.

       Both MDM7 and MEX will support 2400 baud if the user modifies his
port overlay to setup his port for 2400 baud.

       For sysops who use BYE3, the problem is different.  Most
implementations of BYE rely on the hardware's Data Available signal (DAV)
to trigger a check-for-carriage-return sequence at different baud rates.
If most hardware is like mine (Z80 SIO), if the hardware is set to look
at 300 baud and the modem answers at 2400 baud the DAV is never set and
you are in an endless loop.  Same thing happens if you set the hardware
to 2400 and the modem answers at 300.
       I modified BYE3 (version 26 and up) to handle TSTBAUD differently.
I chose to look at each baud rate in 2 second windows, 300 first, then
1200 and 2400, and loop thru this sequence until a C/R or L/F is detected.
The caller is never more than 4 seconds away from his calling speed but
must continue to issue c/r's until the familiar message "Nulls, if needed"
is displayed.  Sysop's who choose to use BYE3 need only add the "SET2400"
code into their port insert.

       Well, enough for now.  Feel free to contact me if you are more
confused now than you were before reading this.

                     -wayne masters, Potpourri sysop-
                            408-378-7474
20-Dec-84 08:45:30-MST,1121;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 08:45:24-MST
Date:     Thu, 20 Dec 84 10:18:50 EST
From:     David Towson (SECAD) <[e-mail]>
To:       Paul Milazzo <[e-mail]>
cc:       [e-mail]
Subject:  Re:  Kaypro floppy format?

Paul and other list members - I would like to take this opportunity to poll
the readership:  Paul has asked an interesting question concerning the format
used for Kaypro disks, and he has asked for replies to be sent directly to him
in order to spare the list "the boring details".  I have seen this sort of plea
several times recently, and I would like to know whether our readers really
find this sort of thing boring.  Certainly, I don't find it boring.  It seems
to me that this is the sort of thing the list is for - an exchange of useful
information concerning CP/M and its many implementations.  In fact, I feel that
the list will die if such an exchange ever stops.

     So how do you all feel about this?  All views are solicited.


Dave

[e-mail]

20-Dec-84 08:47:03-MST,733;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 08:46:59-MST
Date:     Thu, 20 Dec 84 10:00:06 EST
From:     David Towson (SECAD) <[e-mail]>
To:       Jeff M. Gibson <cepu!bradley![e-mail]>
cc:       [e-mail]
Subject:  Re:  archive blurb

Jeff - Before I send you over 20-thousand characters of archive blurb, I
want you to know that it appears from your address that you cannot do FTP
file transfers from SIMTEL20.  Therefore, reading the archive blurb may
do you little good.  However, if you still want a copy, send your reply to
[e-mail] and I'll send you one.


Dave Towson
[e-mail]

20-Dec-84 09:53:01-MST,907;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 09:52:52-MST
Received: From mit-mc.arpa.ARPA by AMSAA via smtp;  20 Dec 84 11:14 EST
Date: Thu, 20 Dec 1984  11:18 EST
Message-ID: <SR.KROHN.12072957943.BABYL@MIT-SPEECH>
From: SR.KROHN@mit-speech
To:   David Towson (SECAD) <[e-mail]>
Cc:   Paul Milazzo <[e-mail]>, [e-mail]
Subject: Kaypro floppy format?
In-reply-to: Msg of 20 Dec 1984  10:18-EST from David Towson (SECAD) <towson at Amsaa.ARPA>


    I fully agree.  Much of the interest presented by the INFO-CPM
list consists in learning how specific implementation problems have
been or are suggested to be resolved.

    What IS truely boring is reading a lot of questions to which
one never sees the answer.

                              Ken Krohn
                      [e-mail]

20-Dec-84 12:12:34-MST,689;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 12:12:29-MST
Received: From nosc-tecr.arpa.ARPA by AMSAA via smtp;  20 Dec 84 13:39 EST
Date: 20 Dec 1984 1027-PST
From: Pawka <[e-mail]>
Subject: Perfect Writer Installation
To: [e-mail]
Reply-To: [e-mail]

    I'm trying to install Perfect Writer on a Z-80 based system
with a TVI 970 terminal which is supposed to emulate a VT-100. Although
PW claims it knows about a VT-100, it doesn't. Has anyone gone thru
the drill of changing the terminal definition strings? I'd appreciate
any help.
                    Mike
                    [e-mail]
------
20-Dec-84 12:32:28-MST,2355;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 12:32:12-MST
Received: From rice-gateway.ARPA by AMSAA via smtp;  20 Dec 84 13:42 EST
Received: by rice.ARPA (AA13164); Thu, 20 Dec 84 12:33:16 CST
Date:     Thu, 20 Dec 84 11:26:42 CST
From: Paul Milazzo <[e-mail]>
Subject:  Re:  Kaypro floppy format?  [appropriateness]
To: David Towson (SECAD) <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
In-Reply-To: a message from David Towson dated Thu, 20 Dec 84 10:18:50 EST

Dave:

I'm glad you found my question "interesting", since I was a bit unsure
that I had addressed it to the correct audience.  I believe that the
exchange of such technical information is of great value to those in
need, and of some interest to those who, like me, are blessed (?) with
an insatiable appetite for technical detail.

Still, the readership of this List, like that of most others, has a
broad range of needs, interests, and technical experience.  This
disparity is actually a blessing, because the novices have an
opportunity to learn from the discussions of wizards, and the dedicated
CP/M hackers get to hear what the rest of us *really* want.

Thus, I would hate to be the cause of a mass exodus of INFO-CPM readers
who cannot tolerate even one more letter about faster DMA on someone's
SuperZippy XYZ-4999 computer.  It seems to be the nature of electronic
mail that an individual's tolerance for irrelevant messages is
primarily a function of his terminal line speed and his mail or BBoard
system's facility in skipping unwanted information.  In deference to
those readers stuck with /bin/mail at 300 baud, I therefore offered to
summarize the responses to my question, possibly in a single message to
the List.  While this means more work for me, it still provides
everyone with the information, eliminates redundant messages, and
allows those uninterested to leap over the entire discussion in a
single keystroke.

Comments?

                Paul G. Milazzo <[e-mail]>
                Dept. of Computer Science
                Rice University, Houston, TX

P.S.   I take the sentiment recently expressed to mean that if nothing
       else, I should certainly send in a summary of responses (should
       any ever appear :-).
20-Dec-84 13:15:08-MST,1479;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 13:14:58-MST
Received: From utexas-20.arpa.ARPA by AMSAA via smtp;  20 Dec 84 14:40 EST
Date: Thu 20 Dec 84 13:40:23-CST
From: John Otken <[e-mail]>
Subject: Suggestion..
To: [e-mail]

Since the current policy is going in the direction of LBRs might I suggest that
you LBR the ZCPR3 files...  Right now there are so many that it would take
massive typing to down load.  Or people are going to do what I am about to do
which is to whip out an old SNOBOL program to turn directory listings into
submit files and down load them one at a time..

Another interesting idea I had not too long ago dealt with the problem of HEX
files.  You could create a special mail box where people could send requests
for converting COM files to HEX files.  A program could read the mail and auto-
matically do the conversions.  Of course the problem with this idea is that
like all ideas it would take somebody to do it.  I would volunteer but I
am not going to be working at UT much longer (Friday is my last "real" day)
so I guess this one can go in the bit bucket.

I not sure of my near future status but I would like to let you guys know
I appreciate all the work you have put into the maintenance of info-cpm &
MICRO:.  BTW, don't kill my subscription yet, I will let you know when
my UT account is going to die.

John Otken
-------
20-Dec-84 13:42:42-MST,929;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 13:42:33-MST
Received: From mitre.arpa.ARPA by AMSAA via smtp;  20 Dec 84 15:12 EST
Date: 20 Dec 1984 15:04:51 EST (Thursday)
From: Jeffrey Edelheit <[e-mail]>
Subject: Re:  Kaypro floppy format?
In-Reply-to: Your message of 20 Dec 1984 10:18:50 EST
To: David Towson (SECAD) <[e-mail]>
Cc: [e-mail]

Dave - Several of the other interest groups take the digest approach.  While
it's nice to have the msgs in a concise digest, it lacks the spontaneity
of info-cpm.  I don't think that having one person summarizing all of the
responses to his/her question is all that bad; it certainly reduces the
communications cost for all of those folks forced to use uucp at 300/1200
bps.

Any other comments from our fellow info-cpmer's is welcome.

Jeff Edelheit
(edelheit@mitre)

20-Dec-84 13:43:49-MST,729;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 13:43:44-MST
Date:     Thu, 20 Dec 84 15:03:28 EST
From:     David Towson (SECAD) <[e-mail]>
To:       John Otken <[e-mail]>
cc:       [e-mail]
Subject:  Re:  Suggestion..

John - I think the idea of librarying the ZCPR3 files makes a lot of sense.
How about it, Rick?

     I just updated my local copy of these files using an automatic FTP script.
There are now 231 files!  Next, I plan to write a UNIX shell script to combine
them into several libraries, each of which will fit on one microcomputer disk,
before I tackle the long download.


Dave
[e-mail]

20-Dec-84 14:25:07-MST,2944;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 14:24:53-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  20 Dec 84 15:49 EST
Received: from usenet by BRL-TGR.ARPA id a012655; 20 Dec 84 15:40 EST
From: [e-mail]
Newsgroups: net.micro.cpm
Subject: Re: EPROM burner wanted
Message-ID: <[e-mail]>
Date: 20 Dec 84 14:59:00 GMT
Nf-ID: #R:hpcvlo:14900003:acf4:10000017:000:2319
Nf-From: acf4!greenber    Dec 20 09:59:00 1984
To:       [e-mail]

<>

Looks like my last posting didn't get off the groud....so here it is
again(I moved the header to EOF...take a look you guys at tgr!):
====================================================================
<>

I use a really nice EPROM burner:

Programmer 4+
Periphco
1659 Scott Blvd #1
Santa Clara, CA 95050
(408)-244-5214

It costs about $200.  Features:
    -    Programs 2716, 2732, 2764, 27128's
    -    RS232
    -    Selectable as Data set or terminal
    -    All Dc is generated on board (you do have to buy your own
            transformer!)
    -    Handles the "A"'s too: 21/25 VDC
    -    ZIF on board
    -    Software is pretty good: Program, Read, Verify. Dumps in
            ASCII and HEX
    -    CP/M and other os's

It does not come in a pretty box, it is pretty slow, it isn't as nice as
the $5000 DataIo I use sometimes, but it meets my "home/hobby/business"
purposes.

I'm not attached to Periphco, except at the wrist and ankles.

Call them and ask for the spec sheet.


Ross M. Greenberg  @ NYU   ---->  allegra!cmcl2!acf4!greenber  <----
============================================================================
Here's what caused the problem with this message.  What's up tgr???

From seismo![e-mail] Thu Dec 20 01:55:58 1984
Received: from NYU-CMCL2.ARPA by NYU-ACF4.ARPA; Thu, 20 Dec 84 01:55:55 est
Received: by NYU-CMCL2.ARPA; Thu, 20 Dec 84 01:51:19 est
Received: from BRL-TGR (brl-tgr.ARPA) by seismo.ARPA with SMTP; Thu, 20 Dec 84 01:45:58 EST
Message-Id: <[e-mail]>
Received: from aerospace.arpa by BRL-TGR.ARPA id a000744; 20 Dec 84 1:43 EST
Date:           Wed, 19 Dec 84 10:16:53 PST
From: The System Postmaster <seismo![e-mail]>
Subject:        Undeliverable mail
In-Reply-To:    <[e-mail]>
To: [e-mail]
Status: R

===== POSTMAN output follows =====
"bond": not delivered (unknown user)

===== unsent message follows =====
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  19 Dec 84 12:56 EST
Received: from usenet by BRL-TGR.ARPA id a020907; 19 Dec 84 12:40 EST
From: [e-mail]
Newsgroups: net.micro.cpm
Subject: Re: EPROM burner wanted
Message-ID: <[e-mail]>
Date: 19 Dec 84 14:23:00 GMT
Nf-ID: #R:hpcvlo:14900003:acf4:10000016:000:799
Nf-From: acf4!greenber    Dec 19 09:23:00 1984
To:       [e-mail]
20-Dec-84 14:30:15-MST,623;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 14:30:11-MST
Received: From wsmr08.arpa.ARPA by AMSAA via smtp;  20 Dec 84 15:45 EST
Date: Thu, 20 Dec 84 13:44:33 MST
From: John Gilbert CD <[e-mail]>
Subject: Re:  Kaypro floppy format?  [appropriateness]
In-Reply-To: Your message of Thu, 20 Dec 84 11:26:42 CST
To: Paul Milazzo <[e-mail]>
Cc: David Towson (SECAD) <[e-mail]>, [e-mail]

Paul,

I like your suggestion. If you ask a question, you incur an obligation to
summarize the responses.

John Gilbert

20-Dec-84 14:31:30-MST,717;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 14:31:18-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  20 Dec 84 15:49 EST
Received: from usenet by BRL-TGR.ARPA id a012659; 20 Dec 84 15:40 EST
From: [e-mail]
Newsgroups: net.micro.cpm
Subject: Re: Warning: RIPOFF from GDL
Message-ID: <[e-mail]>
Date: 20 Dec 84 15:26:00 GMT
Nf-ID: #R:Mit-Mc:-667000:acf4:10000018:000:147
Nf-From: acf4!greenber    Dec 20 10:26:00 1984
To:       [e-mail]

<>

Jerry:

We can't arpa outa here...please mail me your uucp address....


Ross M. Greenberg  @ NYU   ---->  allegra!cmcl2!acf4!greenber  <----
20-Dec-84 15:18:13-MST,872;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 15:18:08-MST
Received: From ddn1.arpa.ARPA by AMSAA via smtp;  20 Dec 84 16:20 EST
Date: 20 Dec 84 15:48:45 EST
From: [e-mail]
Subject: COM to HEX conversion
To: [e-mail]
CC: [e-mail]


You may be interested to know that the following UNIX shell will convert
any file into hex format.

od -bh $1 | awk '/^.0/{print  substr($1,2,2) substr($2,2,2) substr($3,2,2) substr($4,2,2) substr($5,2,2) substr($6,2,2) substr($7,2,2) substr($8,2,2)}' | dd conv=ucase

Use 'CHMOD u+x conv' to make the shell (which I named conv) executable.
The shell is invoked as follows:

conv file.con   (The result will be sent to the terminal)

conv file.con >file.hex (the reult will be sent to the file called file.hex)


Doug

20-Dec-84 18:20:34-MST,1385;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 18:20:03-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  20 Dec 84 19:53 EST
Received: from usenet by BRL-TGR.ARPA id a015682; 20 Dec 84 19:41 EST
From: Michael Cooper <[e-mail]>
Newsgroups: net.micro,net.micro.cpm,net.micro.zx
Subject: Info on OmegaByte (Northstar) Z-80A wanted
Message-ID: <[e-mail]>
Date: 18 Dec 84 22:51:01 GMT
To:       [e-mail]

[ The Sleeper has awakened! ]

I am looking for info on the above mention system that the Electronics
Department at my school has just aquired.  We know almost nothing about
what it ran/runs.  It was donated by a Law Firm that used it for word
proccessing and some accounting.  It is believed to have run some version
of CP/M.  We don't have any software or even a bootable disk for it.
Would someone who has had some experience with or has any idea of where
I can find some info on this beast?


                    Michael Cooper

______________________________________________________________________________
{decvax, ucbvax, pur-ee, uw-beaver, masscomp, cbosg,
 mit-ems, psu-cs, uoregon, orstcs, ihnp4, uf-cgrl}!tektronix
                              \
                               +---!reed!mikec
{teneron, ogcvax, muddcs, cadic, oresoft, grpwre,     /
            psu-cs, omen, isonvax, nsc-pdc}---+
20-Dec-84 20:36:47-MST,1048;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 20:36:37-MST
Received: From utexas-20.arpa.ARPA by AMSAA via smtp;  18 Dec 84 22:54 EST
Date: Tue 18 Dec 84 21:57:13-CST
From: Douglas Good <[e-mail]>
Subject: Kaypro BIOS
To: [e-mail]
Resent-Date:  Thu, 20 Dec 84 22:12:50 EST
Resent-From:  [e-mail]
Resent-To:    [e-mail]

  I'm almost positive that this answer has been answered before but I didn't
catch it the first time around because I wasn't using ZCPR then. The problem
I think I've encountered in the Kaypro's BIOS is that the Warm Boot routine
calls part of the Cold Boot routine which causes ZCPR to rewrite the
maximum disk and maximum user number. Does this sound at all familiar?
Actually I'm using NZCPR which is only a little different than ZCPR. I'm
keeping the maximum user area in 3F, maximum disk in 3D, and wheel byte
in 3E. Any help is appreciated.
                               --Doug
-------
21-Dec-84 08:52:08-MST,511;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 21 Dec 84 08:52:04-MST
Received: From hi-multics.arpa.ARPA by AMSAA via smtp;  21 Dec 84 10:15 EST
Date:  Fri, 21 Dec 84 09:13 CST
From:  [e-mail]
Subject:  .REL format
To:  [e-mail]
Message-ID:  <[e-mail]>

Does there exist a document (underground or otherwise) which describes
the internal form of .REL files?

Thanx, Earl (Boebert -at HI-Multics)
21-Dec-84 09:15:55-MST,522;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 21 Dec 84 09:15:50-MST
Received: From hi-multics.arpa.ARPA by AMSAA via smtp;  21 Dec 84 10:15 EST
Date:  Fri, 21 Dec 84 09:12 CST
From:  [e-mail]
Subject:  James E. Hendrix's net address
To:  [e-mail]
Message-ID:  <[e-mail]>

Does anyone know if James E.  Hendrix, the author of Small C V2, is
reachable from the arpanet?

Thanx, Earl (Boebert -at HI-Multics)
21-Dec-84 09:41:12-MST,1159;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 21 Dec 84 09:41:06-MST
Received: From office-2.arpa.ARPA by AMSAA via smtp;  21 Dec 84 11:08 EST
Date: 21-Dec-84 08:08 PST
From: [e-mail]
Subject: Technical trivia
To: [e-mail]
Message-ID: <[e-mail]>

(everybody else puts a dummy line here. Why not?)

Speaking of technical data! I just spent most of a day discovering that BDS C
uses the interrupt vector at location x'30' (RST 6).  I have often thought of
using RST instructions for linkages in self relocating code BUT... I fear the
impact on some unsuspecting user with some hardware interrupt configuration or
some special storage locations (Some code uses the high end of interrupt vector
7 (DDT's RST location) already.  I read both CP/M documentation and BDS C
documentation and find that in the CP/M documentation RST 6 locations are
reserved and RST 7 is used by DDT.  I was a tad surprised to find that BDS C
used RST 6.  Of course that is because I was using it (caught in the act!)
although the use was unintentional (a bug!).

21-Dec-84 12:48:52-MST,1161;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 21 Dec 84 12:48:31-MST
Received: From isi-uci-gw.ARPA by AMSAA via smtp;  21 Dec 84 14:17 EST
Date: 21 Dec 84 10:05:02 PST (Fri)
Message-ID: <280.472500302@uci-icse>
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Re: Technical trivia
In-reply-to: Your message of 21-Dec-84 08:08 PST.
         <[e-mail]>
From: Jerry Sweet <[e-mail]>
Received: from Localhost by UCI-ICSE for jsweet; 21 Dec 84 10:05:47 PST (Fri)
Received: from Uci-Icse by UCI-750a; 21 Dec 84 11:17:40 PST (Fri)


Some errata for the BDS C version 1.50a explains how to reconfigure
the runtime to use a different RST address.  In general, it is unsafe
to use the RST locations unless your software can be reconfigured as
well.  The Z80 can arrange for hardware interrupt vectors to be placed
elsewhere in memory, but (a) not everyone has a Z80, (b) not everyone
uses the extended scheme, and (c) that still doesn't help when using
software that may already occupy the RST vectors.

-jns
21-Dec-84 21:33:29-MST,590;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 21 Dec 84 21:33:24-MST
Received: From mit-multics.arpa.ARPA by AMSAA via smtp;  21 Dec 84 23:08 EST
Date:  Fri, 21 Dec 84 23:09 EST
From:  [e-mail]
Subject:  ZCPRZCPR3 on Apple 2e
To:  [e-mail], [e-mail]
Message-ID:  <[e-mail]>

Has anyone implemented ZCPR3 on a 2e?  The only implementation I know
about uses addresses that screw up a 2e.  Also has anyone implemented
I/O redirection on an Apple?

Thanks,

Allan
22-Dec-84 04:52:04-MST,676;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 04:51:57-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  22 Dec 84 6:02 EST
Received: from usenet by BRL-TGR.ARPA id a006656; 22 Dec 84 5:50 EST
From: [e-mail]
Newsgroups: net.micro.cpm
Subject: 128k/192k Applicards
Message-ID: <[e-mail]>
Date: 21 Dec 84 14:54:03 GMT
Sender: [e-mail]
Nf-ID: #N:zeppo:24100001:000:110
Nf-From: zeppo!bob    Dec 21 09:53:00 1984
To:       [e-mail]

Has anyone had experience with the 128K or 192K expansions for the
PCPI Applicard used for CPM in Apple 2's?
22-Dec-84 08:58:10-MST,921;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 08:58:03-MST
Received: From hi-multics.arpa.ARPA by AMSAA via smtp;  22 Dec 84 10:37 EST
Date:  Sat, 22 Dec 84 09:32 CST
From:  [e-mail]
Subject:  Re: 128k/192k Applicards
To:  [e-mail]
Message-ID:  <[e-mail]>

I have a 192k Applicard on a ][+ and I think it's great.  I definitely
advise getting the 192k for use with text editors; Mince runs like stink
at 6mhz, swapping off the "silicon disk." It is extremely fast and
convenient to have your program set for a given application on the
silicon disk and be able to use both floppies for data.  PCPI
documentation is a little sparse, and I would definitely supplement it
with Cortesi's "Inside CP/M," but their technical assistance over the
phone is first-rate.

Earl (Boebert -at HI-Multics)
22-Dec-84 10:37:29-MST,6137;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 10:37:10-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  22 Dec 84 12:02 EST
Date: Sunday, 16 December 1984  20:39-MST
Message-ID: <[e-mail]>
Sender: decvax!ihnp4!mgnetp!we53!busch!wuphys![e-mail]
From: decvax!ihnp4!mgnetp!we53!busch!wuphys![e-mail]
To: [e-mail]
Subject:   summary of s-100 9-track cntrlr query
ReSent-From: [e-mail]
ReSent-To: [e-mail], [e-mail]
ReSent-Date: Sat 22 Dec 1984 09:53-MST

Here are the responses I got from my request for s-100 tape drive controllers.
My apologies for the long delay.

It turns out that we are going to use a "general purpose parrallel interface"
to hook the Kennedy 9100 to the s-100 Compupro.  The device is called
"Interfacer 2" and is made by Vector Electronic Co. (POB 4336, Sylar CA 91432,
phone [phone]).  It is triple parallel, single rs232serial I/O board.

I should say that I am not directly connected with the group that is
doing the work and cannot explain why it is they chose to go this route.
They are wiring it up and writing the code to manipulate the parallel
in/out registers on the interface to do al the functions of a standard
tape drive controller.  The last word with the principles
on the project indicated that they were able to read and write 800bpi tapes,
but were having troubles checking the CRC and LRC bytes.  This problem was
only on the Compupro end, as they could read perfectly s-100 written
tapes on the PDP11/34-EmulexTC11-Kennedy9100 system.

I have not asked these respondants for a release to forward this
information (it's hard to see why they would object), but if you
contact them you may catch them unawares.  Go accordingly.
I have edited out the headers; the bodies are intact.
Thanks for all your replies and I hope this is usefull to others.

Scott    ihnp4!wuphys!scott
"I am a child of the unixverse."


----------------------------original request-------------------------------

I am looking for a manufacture(s) of S-100 bus controllers for
9-track tape drives (industry std interface - Pertec; Kennedy 9100
to be exact).  I realize this is a little odd and is why I am having
trouble locating a seller.  Any pointers to even potential manufactures
would be much appreciated.

ihnp4!wuphys!scott

Thanks.    Scott Barthelmy, Washington U., Physics Dept., St. Louis, MO.

-----------------------------------reply-------------------------------
From: <ihnp4!hpda!hplabs!bragvax!david>
Subject: Re: S-100 controller for 9-track mt wanted

There was a company that used to have a small ad in the back of Byte
every month -- but I can't remember the name.

You might try:

Ibex Computer Corp.
20741 Marilla St.
Chatsworth CA 91311
[phone]
Bert Johnston

I know they have IBM PC, maybe S-100 too?

David DiGiacomo, BRAG Systems Inc., San Mateo CA  [phone]
(...decvax!ucbvax!hplabs!bragvax!david)


-----------------------------------reply-------------------------------
From: ihnp4!utcsrgv!mason

It seems to me there have been some ads in BYTE about tape drive/controllers
for IBM-PC & their ilk...you might try talking to one of them...or Pertec.

Dave


-----------------------------------reply-------------------------------
From: <ihnp4!hplabs!sdcrdcf!sdcsvax!bmcg!mikel>

There are 2 S-100 controller manufactures that I am aware of.

Konan Corp. in Phoenix AZ has a microprocessor based system but has a limited
block size of up to 8k.  It transfers data into internal ram, and then you use
programmed I/O to read the data.  The board also contains a centronics printer
port.  I have used this one and would highly recomend it.  Price is around
$1,000.

The other I know of, I have a data sheet somewhere is I beleave Overland Data
Systems (or something like it) in El Cajon, CA (I think).  It uses DMA and can
have block sizes of up to 64k.  I don't remember the price.  If the you need
to contact them and can't find them from the above info, mail me a message and
I'll try to find the data sheet.

Good luck.


[Row, row, row your bits, gently down the stream...]

Mike Lesher
Burroughs ASG, San Diego, CA.
(..!bmcg!mikel)


-----------------------------------reply-------------------------------
From: ihnp4!uw-beaver!uw-june!entropy!dataio!weil (Steve Weil)

I don't work there anymore, but when I left, Dual Systems was putting
the finishing touches on a 9-track controller.  My impression is that we
(they) have the highest quality boards available on the S-100 bus.
(They decided to make their own because there were no others that were
reliable.)  They are:    Dual Systems Corp.
            2530 San Pablo Ave.
            Berkeley, Ca. 94710
            [phone]

Steve Weil        Data I/O
ucbvax!lbl-unix!uw-beaver!teltone!dataio!weil
unisoft!teltone!dataio!weil    entropy!dataio!weil


-----------------------------------reply-------------------------------
From: (unknown)
Subject:  9tr on S100

Great news! SUch things DO exist. Contaact DUAL Systems, 2530
San Pablo Ave, Berkeley CA. Phone [phone]. They have a board
called TCON which drives industry-standard 9tr drives (several
particular drives `qualified' for their support; others may work)
up to 100 ips.

Ian Darwin, Toronto
{ihnp4|decvax}!utcs!ian

-----------------------------------reply-------------------------------
From: ihnp4!seismo!hadron!tsp-agv (T. Scott Pyne (AGV))
Subject: Re: 9-track on S-100

This may be a solved problem by now for you.  if not, a company called
Konan Systems makes one, along with other "large machine" peripheral
controllers for S-100 (like SMD drives).  They claim "strict compliance
with IEEE 696 standard", but who doesn't these days.  I don't have their
address/phone in front of me, but they advertise most months in Microsystems.
If you can't find an ad write back to me and I'll dig it up from a back issue.
Hope this helps.
                        Scott
                        seismo!hadron!tsp
22-Dec-84 10:47:51-MST,2110;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 10:47:43-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  22 Dec 84 12:17 EST
Date: Tuesday, 18 December 1984  13:57-MST
Message-ID: <[e-mail]>
Sender: decvax!ihnp4!ihuxe![e-mail]
From: decvax!ihnp4!ihuxe![e-mail]
To: [e-mail]
Subject:   S-100 div./696 corp
ReSent-From: [e-mail]
ReSent-To: [e-mail], [e-mail]
ReSent-Date: Sat 22 Dec 1984 10:01-MST

As many of you probably know, pixel corporatoin offered some winchester
disk drives at remarkable prices. Well a friend bought one and we started
to look for an interface/controller for the beast.

We called these people, s-100 , and asked if they had an interface card
and they recommended that we buy their DISK 2 controller from Compupro.
They assured us that this card was the proper interface for the SA1004.

We order the card and at the same time order the manual from Shugart.
The card came in about a month ago and the manual came last week. After
careful investigation it became apparent that the two did not go together.

We called the company and talked to the Technical Manager. He insists that
there is only one standard for 8 inch Winchester disk. He has never heard
of the SA1000 standard and refused to take the card back since we have had
it for over 30 days. We tried to assure him that the card had not be used,
in fact it is still in the original wrappers. So we have to eat his mistake.

For those of you who may not know, SA1000 is considered by Western digital
and Xebec to be the most popular standard for the 8 inch drives, and the
DISK 2 is for the Fujitsu drive and the SA4000, which we could neither find
the drives of the documentation.

The bottom line is that we suggest that no one buy from these people. Meanwhile
we are going to collect documentation for the owner of the company to enlighten
him/her to the actual standard and the ignorance of the "Technical Manager".
22-Dec-84 11:11:30-MST,1922;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 11:11:24-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  22 Dec 84 12:39 EST
Date: 22 Dec 1984  10:41 MST (Sat)
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: Revised Simtel20 CP/M directories quick reference list

Quick reference list to SIMTEL20's MICRO:<CPM.x> directories
as of Dec. 22, 1984 (where 'x' is one of the names below):

22RSX         CPM3          FORTH-83      MODEM2        SQUSQ
6502          CPM86         GENASM        MODEM7        STARTER-KIT
AMETHYST      CPMLIB        GENCOM        MODEM903      SUBMIT
APPLE         CPR86         GENDOC        MSOFT         SYSLIB
ASMUTL        CUG           HAMMING       NEWS          SYSLIB3
ATARI         DBASEII       HAMRADIO      NSTAR         SYSUTL
BASIC         DEBUG         HDUTL         OSBORN        TERM
BDOS          DIRUTL        HEATH         PACKET        TOPS-20
BDSC-1        DISASM        HELP          PASCAL        TRS-80
BDSC-2        DISKPLOT      HEX           PCDOS         TURBODOS
BDSC-3        DSKBUF        IBM-PC        PILOT80       TXTUTL
BDSC-4        DSKUTL        INSIDCPM      PLOT33        V2CMAC
BSTAM         EDITC80       KAYPRO        PPSPEL        VAXVMS
BYE3          EDITOR        LIST          PUBKEY        VOICE
C80           EPSON         MACLIB        PUBPATCH      WSTAR
CATLOG        EZCPR         MATH          RBBS          XCCP
CB80          FAST2         MEMTEST       RBBS4         YAM
CBIOS         FIDO          MEX           RCPM          Z3LIBS
CCP           FILCPY        MICNET        SMALLC2       ZCPR
COBOL         FILUTL        MISC          SORT          ZCPR2
COMMODORE     FORTH         MODEM         SPELL         ZCPR3
22-Dec-84 14:35:27-MST,1808;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 14:35:22-MST
Received: From mit-mc.arpa.ARPA by AMSAA via smtp;  22 Dec 84 16:07 EST
Date: 22 December 1984 16:06-EST
From: Leor Zolman <[e-mail]>
Subject: RST 6
To: [e-mail]

Some early versions of BDS C v1.5 did indeed use RST 6, but as soon as I
realized this was wiping out console I/O vectors left and right I stopped
distributing it that way. The usage of a RST vector is solely connected with
the CDB (C symbolic debugger) mechanism...when you do not intend to use  CDB
on a program, there is no reason for any RST locations to be clobbered. The
reason I originally had the run-time package write into RST 6 was for the case
where someone creates a COM file intended for use under CDB (and thus filled
with RST 6 calls), then tries to run it standalone. It would bomb if CDB were
not there to intercept the RST 6 calls. So, I had the run-time package put
a little "no-op" subroutine at location 30h. Bad idea.

The way it works NOW is: the mechanism for writing the dummy subroutine is
still there, but it is not enabled until you go in and change some EQU's and
reassemble the run-time package. Apologies to those of you who have wasted
time puzzling over bombing BDS C programs because of this.

One more note: the phenomena where BDS C-coded utilities refuse to put out
characters until the keyboard is hit can be fixed by recompiling the programs
under v1.5. Eariler versions of the library did indeed do the wrong thing
when looking at the return value from "check consle status". This problem
is likely to keep popping up and biting people until the binary versions of
programs like SQ-USQ are updated with more current libraries.
    -leor

22-Dec-84 15:09:04-MST,2373;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 15:08:56-MST
Received: From xerox.arpa.ARPA by AMSAA via smtp;  22 Dec 84 16:46 EST
Received: from Flora.ms by ArpaGateway.ms ; 21 DEC 84 22:43:44 PST
From: [e-mail]
Date: 21 Dec 84 22:43:42 PST
Subject: Basic "MBOOT" program
To: [e-mail]
cc: [e-mail], [e-mail]


Andrew: I think that this program will do what you are looking for.
    Let me know how it truns out...
--------------------

80 REM It will work with the Xerox as well as the Kaypro
 90 REM FOR THE KAYPRO
100 GOTO 280
110 X=(INP(STATUS)AND RMASK):RETURN
120 Y=INP(MODEM):RETURN
130 X=(INP(STATUS)AND SMASK):RETURN
140 OUT MODEM,Y:RETURN
150 GOSUB 130:IF X THEN 140 ELSE 150
160 GOSUB 110:IF X THEN 120 ELSE 160
170 GOSUB 110:IF X THEN GOSUB 120:PRINT CHR$(Y);:GOTO 170
180 Y$="":Y$=INKEY$:IF Y$=""THEN 170
190 IF Y$=T$ THEN Y$=DC3$ ELSE IF Y$=ESC$ THEN Y$=ETX$
200 IF Y$<>E$ THEN Y=ASC(Y$):GOSUB 140:GOTO 170
210 INPUT "ENTER FILE NAME TO RECEIVE? ",F$:OPEN "R",1,F$
220 FIELD 1,128 AS A$:Y=NAK:GOSUB 150:FOR I=1 TO 1E+06:PRINT I;CHR$(13);
230 C=0:GOSUB 160:IF Y=EOT THEN Y=ACK:GOSUB 150:CLOSE 1:PRINT CHR$(7):GOTO 170
240 GOSUB 160:J=Y:GOSUB 160:IF J+Y<>255 THEN C=13
250 FOR J=1 TO 128:GOSUB 160:MID$(B$,J,1)=CHR$(Y):C=C+Y:NEXT
260 GOSUB 160:C=(C AND 255):IF C<>Y THEN Y=NAK:GOSUB 150:GOTO 230
270 LSET A$=B$:PUT 1,I:Y=ACK:GOSUB 150:NEXT
280 MODEM=&H04:STATUS=&H06:RMASK=1:SMASK=4
290 B$=STRING$(128,0):ACK=6:NAK=21:E$=CHR$(5):WIDTH 255:EOT=4
300 ESC$=CHR$(27):ETX$=CHR$(3):DC3$=CHR$(19):T$="~":GOTO 170
--------------------

     BMODEM.DOC
THIS IS A VERY BASIC MODEM PROGRAM FOR THOSE WHO DON'T HAVE
THE PATIENCE FOR DEALING WITH MBOOT3.
THE ONLY LINE THAT NEEDS ALTERING IS 280 IN WHICH YOU PUT
MODEM PORTS IN (HEX OR DEC) AND THE RECIEVE & SEND BIT MASKS.
When you run the program it will act like a very dumb terminal
Use it to log on and setup XMODEM to send you a
better modem program or USQ.
CTRL E asks you for the filename to be received.
An ESC will transmit CTRL C to the remote machine.
A tilde will transmit a CTRL S.
To dial the Hayes modem enter ATDT <phone number>

Altered for the Xerox 820,820-II, and 16/8 on 12/07/84


                -Arun Baheti
               [[e-mail]]
22-Dec-84 17:22:02-MST,4141;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 17:21:48-MST
Received: From xerox.arpa.ARPA by AMSAA via smtp;  22 Dec 84 18:42 EST
Received: from Flora.ms by ArpaGateway.ms ; 22 DEC 84 15:40:14 PST
From: [e-mail]
Date: 22 Dec 84 15:40:00 PST
Subject: Mogur case
To: [e-mail]
cc: Arun Baheti <[e-mail]>


The following text file was taken off of a local bulletin board. It looks
as if Tom may be loosing some of his support. I am sorry if you have
already seen the file...

-----------------------------------







                      Southern California Sysops
                      Pull the Plug on Tcimpidis

                                  by
                             David Brown
                               10/19/84


The tide of public opinion seems to be turning against Southern
California Bulletin Board operator Tom Tcimpidis, following revelation
that the pilfered credit card number found on his system was that of
Tcimpidis' former employer.

Even though most regard John Dvorak a "Smug Twit," his discovery has
prompted many Southern California Bulletin Board System operators --
some of whom shut down or altered their own systems in support of
Tcimpidis' defense -- to change their minds about this matter.

They find highly suspicious the coincidence that the number belonged
to Tcimpidis' former employer.  More incriminating, they say, is the
fact that Tcimpidis never mentioned it to anyone in the local BBS
community.

Tcimpidis claims the number was placed on his board by a caller using
an assumed name.  He also claims he did not know the number in
question belonged to a former employer.  ...And we all thought Tom was
a pretty smart guy.

Dvorak, who says he employed the cunning investigative reporter's
technique of ACTUALLY CALLING THE TELEPHONE NUMBER, revealed in a
copyrighted article in the Sunday, Oct. 7, San Francisco Examiner that
the credit card was owned by a television producer who once employed
Tcimpidis.

Now we all know that Dvorak was tipped to this by an attorney from the
phone company.  But I guess we've all got to try to preserve a little
credibility, John.

Although local Sysops had stuck up for Tcimpidis from the beginning,
their dedication was at least in part based on a feeling that "any of
us could be next."  As one Sysop told me: "All some turkey has to do
is stick a bogus credit card number on your system and you're up shit
creek!"  But operators now feel this latest revelation indicates that
Pacific Bell's intentions in pressing the case against Tcimpidis are
not an effort to intimidate local bulletin board operators.  "This
shows they're not going after Sysops," one operator said, "they're
going after crooks!"

But even before the recent discovery, local Sysops had confided to
this writer that Tcimpidis was, at least, "very careless."

One operator described Tcimpidis' system as the "Pimple Butt BBS."
"There wasn't one worthwhile P.D. (Public Domain) program on that
system," he said, "just a bunch of adolescents passing dirty notes...."

In all fairness, I HAVE downloaded some worthwhile programs from his
massive Heath system.  But I also have seen plenty of inane ramblings
from local Pimple-Poppers who have nothing better to do with their
computers.

By the way, Smug John, all agree with you that the ultimate solution
to this problem is "a sincere effort at self-policing these boards by
the people who run them."  But you are DEAD WRONG when you say
"Unfortunately, there has been NO real movement in that direction."
Local Sysops would like to know why the hell YOU haven't talked with
them?

To sum up, Southern California Sysops are ready to pull the plug on
their support of Tcimpidis and let the telephone company have its way
with him.  Hope he doesn't lose his mouse!

                              -End-

-----------------------------------

    Arun Baheti
   [e-mail]
23-Dec-84 02:03:25-MST,1155;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 23 Dec 84 02:03:19-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  23 Dec 84 3:40 EST
Received: from usenet by BRL-TGR.ARPA id a015274; 23 Dec 84 3:40 EST
From: [e-mail]
Newsgroups: net.micro.cpm
Subject: Re: RST 6
Message-ID: <[e-mail]>
Date: 23 Dec 84 00:02:00 GMT
Nf-ID: #R:Mit-Mc:-674500:acf4:10000019:000:598
Nf-From: acf4!greenber    Dec 22 19:02:00 1984
To:       [e-mail]

<>

While we have you on the line.....do you think that you could
put the infamous "printf" problem in your documentation.  Took me
about two days to figure out what was going on (For those who don't
know: BDS C can handle lines of only MAXLINE in length.  Printf goes
out to lunch, even with 'printf("%20.20s", string);' if string is longer
than MAXLINE).


For those who haven't experienced yet --- I'll bet you a dollar that you
do. But you only experience it once!!!


------------------------------------------------------
Ross M. Greenberg  @ NYU   ---->  allegra!cmcl2!acf4!greenber  <----
23-Dec-84 21:12:56-MST,791;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 23 Dec 84 21:12:52-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  23 Dec 84 22:44 EST
Received: from usenet by BRL-TGR.ARPA id a024076; 23 Dec 84 22:44 EST
From: Andrew Klossner <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Re: .REL format
Message-ID: <[e-mail]>
Date: 23 Dec 84 10:03:55 GMT
To:       [e-mail]


    "Does there exist a document (underground or otherwise) which
    describes the internal form of .REL files?"

Look in the MACRO-80 manual, in the chapter which describes the loader.

  -- Andrew Klossner   (decvax!tektronix!orca!andrew)       [UUCP]
                       (orca!andrew.tektronix@csnet-relay)  [ARPA]
24-Dec-84 11:07:45-MST,1095;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 24 Dec 84 11:07:28-MST
Received: From lll-mfe.arpa.ARPA by AMSAA via smtp;  24 Dec 84 12:20 EST
Date: Mon, 24 Dec 84 09:21 PST
From: "Webb Mike"@LLL-MFE.ARPA
Subject: ADDING A HARD DISK ?
To: [e-mail]

DOES ANYONE OUT THERE HAVE ANY EXPERIENCE ADDING A WINCHESTER INTERFACE
TO A Z80 BASED CP/M 2.2 SYSTEM,WHICH DOSE NOT HAVE THE LOGIC TO TALK
TO A WINCHESTER CONTROLLER. I HAVE HAD SEVERAL PEOPLE TELL ME ABOUT
ADDING THE LOGIC TO A CPU WHICH INVOLVES 'PIGGY-BACKING' A BOARD BETWEEN
THE Z80 CHIP AND IT'S SOCKET. THIS SOUNDS LIKE A NEAT IDEA,BUT IF IT WAS
SO GREAT AN IDEA WHY AREN'T THERE A ZILLION GUY'S OUT THERE SELLING
THIS BETTER MOUSE TRAP???

I WOULD LIKE TO HEAR FROM ANYONE WITH EXPERIENCE IN DOING THIS. IS IT COST
EFFECTIVE (AM I GOING TO END UP BUYING ANOTHER COMPUTER ANYHOW),WHO BUILDS/
SELLS THE MODULE IF THERE IS ONE,ANY HORROR STORIES ETC.

AS RECENTLY DISCUSED I WILL POST A SUMMARY IF THERE ARE ANY ANSWERS.


MIKE WEBB

[e-mail]

25-Dec-84 00:11:46-MST,1294;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 25 Dec 84 00:11:41-MST
Received: From mit-mc.arpa.ARPA by AMSAA via smtp;  25 Dec 84 1:42 EST
Date: 25 December 1984 01:43-EST
From: Jerry E. Pournelle <[e-mail]>
Subject:  Mogur case
To: [e-mail]
cc: [e-mail]
In-reply-to: Msg of 22 Dec 84 15:40:00 PST from NBaheti.es at XEROX.ARPA

Not everyone has abandoned Tom; Peggy Watt continues to believe
in him.  It is unfortunate that the case is no longer so clean
and clear cut as it was.  If Tcimpidis did actually put that
humber up, or knew it was there, then we're in a different ball
game than if things are as he says.  On the other hand, it isn't
all that clear that Tcimpidas had any real motive to put the
number up; and, after all, it's not beyond the bounds of
credibility that some third party who knew the one knew the
other; even that some other former or current employee posted
the number.  Is it at all possible that whoever did it MET
Tcimpidas while  Tcimpidas was employed with the number's owner?
And so forth.
    I do wish it had stayed clean, thouhg.
    Query--did Dvorak REALLY get the info from the phone
company?  Do you KNOW this?  I'd love to have proof of that...


25-Dec-84 00:12:11-MST,528;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 25 Dec 84 00:12:07-MST
Received: From mit-mc.arpa.ARPA by AMSAA via smtp;  25 Dec 84 1:48 EST
Date: 25 December 1984 01:49-EST
From: Jerry E. Pournelle <[e-mail]>
Subject:  128k/192k Applicards
To: [e-mail]
cc: [e-mail]
In-reply-to: Msg of Sat 22 Dec 84 09:32 CST from Boebert at HI-MULTICS.ARPA

I can second Applicard as a good item; we've had one for years
in thge kids' apple ][

25-Dec-84 00:45:59-MST,558;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 25 Dec 84 00:45:56-MST
Received: From mit-mc.arpa.ARPA by AMSAA via smtp;  25 Dec 84 2:24 EST
Date: 25 December 1984 02:25-EST
From: Jerry E. Pournelle <[e-mail]>
Subject:  Warning: RIPOFF from GDL
To: [e-mail]
cc: [e-mail]
In-reply-to: Msg of 20 Dec 84 15:26:00 GMT from greenber%acf4.uucp at BRL-TGR.ARPA

uucp address?  dinna ken uucp
J E Pournelle
BYTE
70 Main St
Peterborough New hampshire
03458

25-Dec-84 12:45:41-MST,660;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 25 Dec 84 12:45:37-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  25 Dec 84 14:06 EST
Received: from mit-mc.arpa by BRL-AOS.ARPA id a015648; 25 Dec 84 14:02 EST
Date: 25 December 1984 14:01-EST
From: "Michael C. Adler" <[e-mail]>
Subject: cp/m+ incompatibility
To: [e-mail]

I have heard that my spelling checker, SPELL, does not work on the
Osborne Executive running CP/M+.  Has anybody used SPELL successfully
on CP/M+?  SPELL makes heavy use of random file I/O.  Is there any
incompatibility there?
Thanks,
-Michael

25-Dec-84 15:23:31-MST,1116;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 25 Dec 84 15:23:26-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  25 Dec 84 16:59 EST
Date: 25 Dec 1984  15:01 MST (Tue)
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   "Michael C. Adler" <[e-mail]>
Cc:   [e-mail]
Subject: cp/m+ incompatibility
In-reply-to: Msg of 25 Dec 1984  12:01-MST from Michael C. Adler <MADLER at mit-mc.ARPA>

The Osborne Executive destroys some of the Z80 alternate registers in
the CBIOS.  This could be the problem if your spelling checker program
uses them and does not save the registers when calling BDOS or CBIOS.
There is a fix for the Osborne Exec. users:

Filename            Type     Bytes     CRC

Directory MICRO:<CPM.OSBORN>
TPATCH.LBR.1            COM      1664  9126H

This is a program that patches the Osborne Exec. CBIOS so it preserves
the Z80 alternate registers.  It is run once when cold booting and
remains thereafter until the next cold boot.
--Keith
25-Dec-84 21:08:28-MST,1329;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 25 Dec 84 21:08:22-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  25 Dec 84 22:37 EST
Received: from mit-mc.arpa by BRL-AOS.ARPA id a015962; 25 Dec 84 22:32 EST
Date: 25 December 1984 22:31-EST
From: "Robert L. Plouffe" <[e-mail]>
Subject: Patches for MODM700
To: [e-mail]
cc: [e-mail]

There is now a patch file at SIMTEL20 in the CPM.MODEM7 archive
that allows patching of MODM700 for the following features:

    1.    Allow rubout to go to console and optionally
    eliminate the control character feature.

    2.    The UNDO-J option that restores terminal mode
    as the default at the calling end and command mode at
    the called end after completion of file transfers.  Yhis
    is how Ward originally wrote it and the preferred mode
    by many.

    3.    Corrected error that caused the wrong file to be
    erased (in some instances) when overwiting files in
    batch mode.  This patch was in PAT730Vx.ASM but did not
    make it into MODM700.

    4.    Allows for optional MAXWAIT times in the protocol
    to improve operation when operating with satellite
    communication links or with packet switched networks
    that can sometimes throttle and give excessive and
    variable packet delays.

26-Dec-84 07:02:19-MST,692;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 26 Dec 84 07:02:14-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  26 Dec 84 8:39 EST
Date: 26 Dec 1984  06:40 MST (Wed)
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: Patches for MODM700
In-reply-to: Msg of 25 Dec 1984  20:31-MST from Robert L. Plouffe <PLOUFF at mit-mc.ARPA>

The patch file for MODM700 announced by Bob Plouffe is:

Filename            Type     Bytes     CRC

Simtel20 directory MICRO:<CPM.MODEM7>
PAT700V1.ASM.1            ASCII      3292  9C76H

--Keith
27-Dec-84 07:48:34-MST,6387;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 27 Dec 84 07:48:12-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  27 Dec 84 9:05 EST
Date: Wednesday, 5 December 1984  16:27-MST
Message-ID: <[e-mail]>
Sender: Bruce Factor <philabs!sbcs![e-mail]>
From: Bruce Factor <philabs!sbcs![e-mail]>
Subject:   2400 baud modems
ReSent-From: [e-mail]
ReSent-To: [e-mail], [e-mail]
ReSent-Date: Thu 27 Dec 1984 07:03-MST

For those of you in the market to buy 2400 baud modems I want to
inform you of a great deal.  I would like to state that I am not
affiliated with ANY of these companies, and I am not receiving and
benefits by posting this information!

After spending a few days pricing modems I have compiled the following
information (saving the best for last).  If anyone has any additional
information I would greatly appreciate it.

We were interested in rack mounting them so most of the prices given
are for cards that would plug into a rack.  "box" refers to a stand
alone modem.

DEC     1 - (800) 962 - 3244

now     DF112-AM        300/1200        card    $ 506
now     DF126-AM        2400 only       card    $ 634


Racal Vadic     1 - (800) 482 - 3427

now     VA212PAR        300/1200        card    $ 445
3/85    VA4224          1200/2400       card    $ 740
now     VA1681          houses 16       rack    $ not priced yet


Concord Data Systems    (617) 890 - 1394
                                                                Q10-24
now     CDS224 AA/ORG   1200/2400       box/card$ 845           $ 825
now     CDS224 Autodial 1200/2400          "    $ 995           $ 975
now     CDS224 ARQ      1200/2400          "    $1295
now     CDS224 ARQ Auto 1200/2400          "    $1395
now     CDS224 Super    1200/2400          "    $1695
now     CDSRM-07A       houses 7        rack    $ 750


Hayes   1 - (800) 241 - 6492

now     Hayes1200       300/1200        box/card$ 499
2/85    Hayes2400       300/1200/2400   box/card$ none
now     08-00056        houses 6        rack    $ 766

Quantity Discounts are minimal.


Micom   1 - (800) 527 - 0204
                                                                Q >16
now     M3012           300/1200        box     $ 495
now     M3012 plus      300/1200        box     $ 595
1/85    M3024           1200/2400       box     $ 795
1/85    M3024 plus      1200/2400       box     $ 895           $ 805
  "        "                "           card    $ 845           $ 760
now     M3200           houses 16       rack    $ 750


General Datacomm                (203) 574 - 1118
                                                                Q 10 - 19
now     DC211AL         300/1200        box     $ 675           $ 595
 "         "                "           card    $ 585           $ 520
1/85    DC2412          1200/2400       box     $1195           $1050
 "         "                "           card    $1105           $ 790
 "      DS1             houses 16       rack    $ 795

Paradyne        1 - (800) 482 - 3333 or 1 - (800) 342 - 3532

now     DTU1200D        300/1200                $
now                     1200/2400               $ 900


NEC     1 - (800) 538 - 8166
                                                                Q 11 -20
now     N212BRL         300/1200        box     $ 795           $ 669
 "         "                "           card    $ 725           $ 606
 "      DSP2430         1200/2400       box     $1095           $ 976
 "         "                "           card    $ 965           $ 855
 "      N4083           houses 8 - 1200 rack    $ 625
 "      SR0801          houses 8 - 2400 rack    $ 900


QUADRAM         (404) 923 - 6666
                                                        Q > 3
now     QM10000         300/1200                $ 695           $ 625
not available           ?/2400                  $

NO Rack mounting.


Ven-Tel         1 - (800) 538 - 5121
Will Call me back.

                        300/1200                $
                        ?/2400                  $


Promethus       (415) 490 - 2370        (check 800)
        Distributor:
Will call me back.

                        300/1200                $
                        ?/2400                  $


Fujitsu         (408) 946 - 8777        ext 576

not available           300/1200                $
now     F1935B          1200/2400               $ 895

                        -------------------------------

CTS Datacomm    (203) 743 - 3681        Pete Coccaro
        Distributor:    Professional Network Services
                        Harvey Schlesinger      (617) 449 - 6460

Model:  CTS2424AD

These people had by far the best deal.
The list price for the Stand Alone (box) modem is  $ 795
The list price for the (rack) mounted modem is ~$ 700.

Besides starting off $ 200 less than everyone else their
quantity discounts are very good.  The Stand Alone modem
will be available starting January, and their rack mount
modem should be available February.

Here is a Quantity discount price list.

Quantity    %dicount    S.A.    rack
========    ========    ====    ====
    1           list        $795    $700
  2-5           10 %         716     630
  6-10           20 %         636     560
 11-25           25 %         596     525
 25-           30 %         556     490

For all of you usenet sites that are still running 1200
(or possibly even 300) the modems will pay for themselves
very quickly.

From all of the literature that I have recieved here are
a few of the advantages of this modem above the others:

1) works at 300 or 1200 or 2400 asyn    (others only 1200/2400)
           1200 or 2400 sync

2) Stores 10 numbers (40 chars each)    (others only 1)

3) For tone dialing it dials ALL 12    (others only can generate
   tones including (* and #)         numbers 0-9)

   This last one caused a nasty problem when we needed to
   generate the extra tones because some of the sites we talk to
   have switching systems that require them (Gandalf).

4) Will automatically change the speed   (some of the others needed
   to the other modem.             a manual intervention).

---------------

usenet:  {philabs, allegra}!sbcs!bruce            Bruce Factor
27-Dec-84 08:27:44-MST,570;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 27 Dec 84 08:27:40-MST
Received: From mitre.arpa.ARPA by AMSAA via smtp;  27 Dec 84 9:58 EST
Date: 27 Dec 1984  9:59:46 EST (Thursday)
From: Jeffrey Edelheit <[e-mail]>
Subject: Mailing Label program
To: [e-mail]
Cc: [e-mail]

Does anyone know if there is a mailing label program written in BASIC that
is kept in the SIMTEL20 archives?  Any directory/file name pointers would
be appreciated.

Jeff Edelheit
(edelheit@mitre)

27-Dec-84 18:01:33-MST,530;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 27 Dec 84 18:01:29-MST
Received: From xerox.arpa.ARPA by AMSAA via smtp;  27 Dec 84 19:35 EST
Received: from CheninBlanc.ms by ArpaGateway.ms ; 27 DEC 84 10:40:22 PST
Date: Thu, 27 Dec 84 10:39 PST
From: [e-mail]
Subject: Re: Mattel Intellivoice info wanted
In-reply-to: <[e-mail]>
To: Shields <[e-mail]>
cc: [e-mail]

PLEASE COPY ME IN ON ALL ANSWERS.

BILL

27-Dec-84 19:14:33-MST,899;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 27 Dec 84 19:14:26-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  27 Dec 84 20:44 EST
Date: 27 Dec 1984  18:39 MST (Thu)
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: RCPM-057.LQT list of all known RCPMs updated

The latest list of all known RCPM (Remote CP/M) systems is now
available from SIMTEL20.  If you cannot FTP and you are not already on
the list to automatically receive updates of RCPM-xx.LST, please send
a note to me and I'll add you to the mailing list.

Filename            Type     Bytes     CRC

Directory MICRO:<CPM.MISC>
RCPM-057.LQT.1            COM     36864  72DAH

--Keith <W8SDZ@SIMTEL20>
Usenet: ...decvax!brl-bmd!w8sdz
  or    ...seismo!brl-tgr!w8sdz
27-Dec-84 22:15:12-MST,675;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 27 Dec 84 22:15:07-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  27 Dec 84 23:50 EST
Received: from usenet by BRL-TGR.ARPA id a007323; 27 Dec 84 23:40 EST
From: "David Herron, NPR Lover" <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Re: Need a BREAK key.
Message-ID: <[e-mail]>
Date: 24 Dec 84 07:38:20 GMT
To:       [e-mail]

You could do what the 4.2 tip program does.  For break it lowers the
baud rate to like 50 baud and sends characters out.  Gauranteed to make
framing errors on the receiver.  And it works too.
28-Dec-84 10:11:40-MST,738;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 28 Dec 84 10:11:31-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  28 Dec 84 11:40 EST
Date: 28 Dec 1984  07:55 MST (Fri)
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Cc:   [e-mail]
Subject: PAT700V2.ASM revised patches for MODM700

PAT700V1.ASM patches for MODM700, previously announced, had some errors
in patch addresses.  A revised patch file is now available from Simtel20:

Filename            Type     Bytes     CRC

Directory MICRO:<CPM.MODEM7>
PAT700V2.ASM.1            ASCII      3104  CFC6H

--Keith
28-Dec-84 10:13:49-MST,1873;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 28 Dec 84 10:13:38-MST
Received: From mit-mc.arpa.ARPA by AMSAA via smtp;  28 Dec 84 11:40 EST
Date: 28 December 1984 11:42-EST
From: Herb Lin <[e-mail]>
Subject:  report on macro-tech board (80286/z80) - of interest to 8085/8088 users
To: [e-mail]
cc: [e-mail], [e-mail]

a report to netland about the Macrotech dual processor board,
 (with an 80286 (10 MHz) and a Z-80 (8 MHz) advertised as a "drop in
replacement" for the Compupro dual processor board (8085/8088).

It isn't.

No doubt it does adequately with certain configurations, but with
mine, it does not.  The symptom of difficulty is that when I boot my
system (a Compupro System 8/16 C) running MPM 8-16 (Gifford Computer
Systems), the system does not boot properly (but only intermittently).
It sometimes takes me a few pushes of the reset button to even start
the system; then, sometimes, the system seems unable to find the right
INIT files.  Sometimes, it finds the files, but then branches off into
some strange part of the code.  It has never entirely failed to work,
and these troubles seem to happen only when I am doing my boot.  Once
the system has booted properly, it appears to operate properly after
that.

The problem has been diagnosed as an interaction problem between the
processor board and my hard disk controller board, a Morrow HDCA, that
probably results from timing problems.

Gifford has offered to refund in full the cost of the dual processor
board; they have also suggested that I upgrade my hard disk controller
to a COMPUPRO Disk 2 board.  They have explicitly refused to develop a
fix to my problem.

Since I would really like Z-80 capability for my 8 bit processor, can
anyone make suggestions to me?

tnx.

28-Dec-84 10:19:09-MST,1617;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 28 Dec 84 10:18:58-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  28 Dec 84 11:41 EST
Date: 28 Dec 1984  07:02 MST (Fri)
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   "Robert L. Plouffe" <[e-mail]>
Cc:   [e-mail], [e-mail]
Subject: PAT700V1.ASM bugs?
In-reply-to: Msg of 27 Dec 1984  23:16-MST from Robert L. Plouffe <PLOUFF at MIT-MC>

    Date: Thursday, 27 December 1984  23:16-MST
    From: Robert L. Plouffe <PLOUFF at MIT-MC>
    To:   KPETERSEN at SIMTEL20
    Re:   PAT700V1.ASM bugs?

    Thanks for checking out that patch file.  Indeed, the copy of
    MODM700 that I had (dated as of 11/04/84 - same date as current
    file) was different and was off by 5 bytes in a number of
    locations.  I have fixed up the file and it should be now correct
    as PAT700V2.ASM.  It will be in GUEST1 at MC as usual.  This one
    contains the correct addresses to match the MODM700 at SIMTEL20.
    I thought that we were done with different releases under the
    same release number.

There have been no changes to MODM700.AQM or MODM700.LBR since its
release on November 4, 1984.  Where did you get your copy?  The one on
Simtel20 hasn't been touched, according to WDIR's display of the
creation date.

Filename            Type     Bytes     CRC

Directory MICRO:<CPM.MODEM7>
MODM700.AQM.1            COM    104320  8B0AH
MODM700.LBR.1            COM     71936  0477H

--Keith
28-Dec-84 10:55:56-MST,1676;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 28 Dec 84 10:55:49-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  28 Dec 84 11:54 EST
Received: from usenet by BRL-TGR.ARPA id a002312; 28 Dec 84 11:48 EST
From: Jim Gutman <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Kaypro DSDD
Message-ID: <[e-mail]>
Date: 27 Dec 84 19:33:03 GMT
To:       [e-mail]



Hi.  I've got a *new* Kaypro II.  The one with double density
single sided drives.  Well, it turns out that Kaypro
goofed and provided me with double sided drives.  Great!
But, without a double sided rom (format program also), the
drives can only be used as single sided.  Does anyone
out there know of the patches that need to be made to the
BIOS and format to allow double sided?  Or, does anyone
out there know of a place to buy a rom, at a reasonable price?

Please keep in mind that this is a *new* verison Kaypro.  It
has the same motherboard as the Kaypro 10's.  I know that
there are roms available to convert to double sided for the
older Kaypro's.  Can anyone help???  I hate to either
disassemble the BIOS and format program or not use double
sided.   Thanks in advance, Jim.


--

                                The more I live,
     Jim Gutman                     the more I learn.
     NBI, Inc
     Boulder, CO                The more I learn,
                                    the more I realize,
     [phone]                 the less I know.

     Path ---> (ucbvax,allegra,hao)!nbires!jim  :)
28-Dec-84 12:07:35-MST,1109;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 28 Dec 84 12:07:16-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  28 Dec 84 13:34 EST
Received: from usenet by BRL-TGR.ARPA id a005255; 28 Dec 84 13:18 EST
From: "Mark A. Ryding" <[e-mail]>
Newsgroups: net.micro.cpm
Subject: BIOS Source Wanted
Message-ID: <[e-mail]>
Date: 28 Dec 84 04:17:07 GMT
To:       [e-mail]

<run away, run away>
I am looking for the source for the BIOS for a Vector Graphic Vector 3
micro.  I have been trying to use RAID (a debugger of course) to
dis-assemble the one I've got, but there are alot of things that I
don't understand going on.  Any help, hints, leads, tips, suggestions,
or copies will be greatly appreciated.  I will even pay for a copy, but
donations are much cheaper.

        E-mail:     ..!trwrb!trwrba!ryding

    or

        U. S. Snail-mail:    Mark Ryding
                    4515 Harrison Blvd #23
                    Ogden, UT  84403

    'I don't mind not knowing the answers, but do they have to keep
            changing the questions?'
28-Dec-84 13:24:17-MST,3808;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 28 Dec 84 13:24:03-MST
Received: From brl-gateway2.ARPA by AMSAA via smtp;  28 Dec 84 14:35 EST
Received: from mit-mc.arpa by BRL-AOS.ARPA id a006118; 28 Dec 84 8:23 EST
Date: 28 December 1984 08:21-EST
From: "Robert L. Plouffe" <[e-mail]>
Subject: modm700 patches
To: [e-mail]

The following corrected file replaces the one announced
previously.  It will be in SIMTEL20 at micro:<cpm.modem7>.

DO NOT USE THE ONE PREVIOUSLY ANNOUNCED.  THE ADDRESSES WERE
OFF BY 5 BYTES IN SEVERAL PLACES BECAUSE I HAD AN EARLY COPY OF
MODM700 THAT DID NOT MATCH THE ONE AT SIMTEL20.

;        PAT700V2.ASM

;These patches should be made to MODM700 to obtain the results
;described.  They were previously described as patches to MDM730
;in the file PAT730V8.ASM and were not done in the source code
;for MODM700.  It appears that all of the other patches in PAT730
;were included properly. The object code addresses may have changed
;from MDM730 to MODM700 so use those given below only for MODM700.
;            ....    Bob Plouffe   12/28/84

TRUE     EQU    0FFH
FALSE     EQU    0

MAXWAIT     EQU    16        ;USE AT LEAST A '5' HERE.
RUB     EQU    7FH
TERM     EQU    1618H
MENU     EQU    32EDH

RUBCON     EQU    TRUE        ;want rubout to go to console?
UNDO$J     EQU    TRUE        ;set to TRUE to restore the 'T'
                ;option so that remote end doesn't
                ;automatically come up in terminal
                ;mode at the end of a file transfer
;*************************************************************
;
;This restores the feature that allows the RUBOUT character to
;go to the console if you desire it.  Code was added in MDM730
;that prevented rubout being sent to console in terminal mode.
;
;In the routine TERML
    ORG    1F0FH
    IF    RUBCON
    DB    0,0,0,0,0    ;deletes rubout filter
    ENDIF

    IF    NOT RUBCON
    CPI    RUB
    JZ    TERM
    ENDIF

;***********************************************************
;THIS ONE CONTRIBUTED ANONYMOUSLY AS undo-j.asm AND INCLUDED
;HERE AS AN ADDITIONAL OPTION.
;To undo the 'J' option and restore the 'T' option as it has
;always been. Set UNDO$J to TRUE to enjoy this option.  Irv
;never did change the help screens to describe his 'J' option
;anyhow.  The 'T' option is still the one described there.

;The following code is in the DONETC routine:
    ORG    2AFBH
    IF    UNDO$J
    JNZ    MENU
    ENDIF
    ;
    IF    NOT UNDO$J
    JZ    MENU
    ENDIF

; and at the following storage locations near the end of the file.
    ORG    4952H
    IF    UNDO$J
    DB    'T'
    ENDIF
    ;
    IF    NOT UNDO$J
    DB    'J'
    ENDIF

    ORG    495FH
    IF    UNDO$J
    DB    'T'
    ENDIF
    ;
    IF    NOT UNDO$J
    DB    'J'
    ENDIF

;
;*******************************************************************
;This patch fixes a bug found by Ron Fowler that causes the wrong
;file to be erased in the directory when overwriting existing files
;in batch mode.
;..in the routine at CKCPM2:
    ORG    2238H
    NOP            ;These 2 bytes replace 'CPI  0FFH'
    INR    A

;*******************************************************************
;This patch makes the program MUCH more tolerant of network or
;transmission delays such as found in packet switched nets (ARPANET)
;as well as on satellite communication links.  Do not use a value for
;MAXWAIT less than 5 (5 seconds) and even as high as 16 seconds is ok
;which will then tolerate some of the large throttling delays often
;encountered.

    ORG    1B8FH
    MVI    B,MAXWAIT

    ORG    1BF3H
    MVI    B,MAXWAIT

    ORG    1C0CH
    MVI    B,MAXWAIT

    ORG    1CA0H
    MVI    B,MAXWAIT

    ORG    1D03H
    MVI    B,MAXWAIT

    ORG    240AH
    MVI    B,MAXWAIT

    ORG    2413H
    MVI    B,MAXWAIT

    ORG    245EH
    MVI    B,MAXWAIT

    ORG    2477H
    MVI    B,MAXWAIT

    ORG    2496H
    MVI    B,MAXWAIT

;*******************************************************************
    ;the
    END

29-Dec-84 04:42:57-MST,976;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 29 Dec 84 04:42:52-MST
Received: From cmu-cs-c.arpa.ARPA by AMSAA via smtp;  29 Dec 84 6:16 EST
Received: ID <[e-mail]>; Sat 29 Dec 84 06:17:09-EST
Date: Sat 29 Dec 84 06:17:01-EST
From: Penny Anderson <[e-mail]>
Subject: Problem with ZCPR3 MENU.COM
To: [e-mail]
cc: [e-mail], [e-mail]

Rick,

    I'm using version 3.2 of MENU.COM and running into a glitch that
might be nasty for those trying to run a secure ZCPR3 with menus:

    on a menu with the 'exit to CP/M' option disabled,
    a control-C followed by a CR moves on to the next menu, even if
        a system menu ($) follows the current menu.

    I've heard a rumor that there is a new version of MENU.COM and .MAC.
Do the fixes address this problem?  Is this a real problem, can anyone else
duplicate it?

            Don Shields c/o APA@CMU-C
-------
29-Dec-84 06:34:40-MST,1352;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 29 Dec 84 06:34:35-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  29 Dec 84 8:11 EST
Received: from usenet by BRL-TGR.ARPA id a017417; 29 Dec 84 7:54 EST
From: "M.GALE" <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Re: 2400 baud modems
Message-ID: <[e-mail]>
Date: 28 Dec 84 14:20:51 GMT
To:       [e-mail]

Please note at the beginning that this is coming from an account
on an AT&T computer.
<Reach out and byte someone...>
Just wanted to point out that in the recent summeries of
modems available people seem to be missing a major manufacturer
of modems -- A T & T.

Check it out with an A T & T - I S sales rep. They've got
1200/2400 standalone and rackmount systems. And you don't
call it the Bell 212 standard for nothing.

Please note that I do not work in that department and know
only the basics concerning such hardware i.e. it exists.

I am not an employee nor an authorized representative of
any part of AT&T, I only help solve problems for them on
a contract basis. To think that my opinions are those of
the company is ludicrous.

Michael D. Gale
"I just like blinking lights-the DECsystem 10 operator's panel
    is a work of art" blink-blink-blink-burnout-blink
29-Dec-84 12:30:04-MST,1244;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 29 Dec 84 12:29:59-MST
Received: From brl.arpa.ARPA by AMSAA via smtp;  29 Dec 84 14:05 EST
Received: from simtel20.arpa by BRL-AOS.ARPA id a003060; 29 Dec 84 13:59 EST
Date: 29 Dec 1984  11:58 MST (Sat)
Message-ID: <[e-mail]>
From: [e-mail]
To:   Herb Lin <[e-mail]>
CC:   [e-mail], [e-mail], [e-mail]
Subject: report on macro-tech board (80286/z80) - of interest to 8085/8088 users
In-reply-to: Msg of 28 Dec 1984  09:42-MST from Herb Lin <LIN at Mit-Mc.ARPA>

Have you spoken to the people at Macrotech? It is possible that the
hard disk controller you have is incompatible because of timing
problems, but I cannot say for sure. I don't recall hearing of the
MI-286 operating with the Morrow controller, but it does indeed
operate with the Konan and CompuPro controllers. The technical
suppoert people at Macrotech are _very_ cooperative and will go out of
their way to try to assist you.
The MI-286 board buys much more than 8-bit Z80 operation - the speed
improvement over the 8085/88 board is impressive. Don't give up just
yet!

-Charlie
30-Dec-84 11:50:20-MST,757;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 30 Dec 84 11:50:15-MST
Received: From brl.arpa.ARPA by AMSAA via smtp;  30 Dec 84 12:41 EST
Received: from mit-mc.arpa by BRL-AOS.ARPA id a000152; 30 Dec 84 12:41 EST
Date: 30 December 1984 04:54-EST
From: "Jerry E. Pournelle" <[e-mail]>
Subject:  report on macro-tech board (80286/z80) - of interest to 8085/8088 users
To: [e-mail]
cc: [e-mail], [e-mail], [e-mail]
In-reply-to: Msg of 29 Dec 1984  11:58 MST (Sat) from CSTROM at SIMTEL20.ARPA

see my report on Macrotech board in January BYTE.  It is a very
good board.  Now all I need is a BIOS that lets me use my
memory-map video with it.
JEP

30-Dec-84 11:51:32-MST,1626;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 30 Dec 84 11:51:27-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  30 Dec 84 12:45 EST
Received: from usenet by BRL-TGR.ARPA id a001580; 30 Dec 84 12:00 EST
From: [e-mail]
Newsgroups: net.micro.cpm
Subject: Re:  Apple & Applicard with ram extenders
Message-ID: <[e-mail]>
Date: 28 Dec 84 08:43:27 GMT
To:       [e-mail]

-------------------------------------------

[Re: inquiry by Bob@zeppo & reply from Boebert@HI-Multics.]
It may not be widely known that two extenders can be piggybacked
for up to 256K extra ram or a 223K ramdisk under PCPI version 2
software (version 2 has a number of enhancements and improved
documentation); the ramdisk can be declared to be drive A and
files can be automatically pipped to it on bootup, giving
convenience in startups and very impressive speed when
overlays are in the ramdisk -- at 6 MHz, applications like
Wordstar or Dbase II zip along with instant screen updates
from the user viewpoint.  With two extenders, the Applicard is
thick at the Apple keyboard end, but can be installed in slot 7
to get it out of the way of other long cards.  I have this
setup in an Apple //e and am pleased with it; I agree with
the comment that telephone support from PCPI is good.
Question:  Does anyone else with a two-extender setup have
any comment regarding heat generation in the closely-spaced
ram board areas?  I have not had problems so far in this
respect myself, but that region obviously does warm itself up.
30-Dec-84 11:52:52-MST,683;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 30 Dec 84 11:52:49-MST
Received: From brl-tgr.arpa.ARPA by AMSAA via smtp;  30 Dec 84 12:45 EST
Received: from usenet by BRL-TGR.ARPA id a001614; 30 Dec 84 12:01 EST
From: Art Zemon <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Re:  Kaypro floppy format?
Message-ID: <[e-mail]>
Date: 28 Dec 84 16:09:30 GMT
To:       [e-mail]

I like to see the "boring" details of such technical
discussions.  If I find it truly boring, I can always use
"n".
--
    -- Art Zemon
       FileNet Corp.
       ...! {decvax, ihnp4, ucbvax} !trwrb!felix!zemon
30-Dec-84 12:23:25-MST,761;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 30 Dec 84 12:23:22-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  30 Dec 84 14:02 EST
Date: Sun 30 Dec 84 12:03:46-MST
From: Rick Conn <[e-mail]>
Subject: Re: Problem with ZCPR3 MENU.COM
To: [e-mail]
cc: [e-mail], [e-mail], [e-mail]
In-Reply-To: Message from "Penny Anderson <[e-mail]>" of Sat 29 Dec 84 04:17:31-MST

Don,

    The ^C problem has been addressed, and to my knowledge solved.
The current version of MENU is 3.5 (several versions from the old 3.2),
and you may want to look into getting a copy to see if your problem goes away.

        Rick
-------
30-Dec-84 12:42:23-MST,470;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 30 Dec 84 12:42:20-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  30 Dec 84 14:13 EST
Date: Sun 30 Dec 84 12:15:44-MST
From: Rick Conn <[e-mail]>
Subject: ZCPR3 Newsletter 102 ...
To: [e-mail]

... is now in MICRO:<CPM.ZCPR3> as Z3NEWS.102.  Lots of tidbits of info
there about ZRDOS, new versions of tools, etc.

        Rick
-------
30-Dec-84 14:12:15-MST,1386;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 30 Dec 84 14:12:10-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  30 Dec 84 15:45 EST
Date: 30 Dec 1984  13:47 MST (Sun)
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: BU - hard disk backup utility

BU, a new hard disk backup utility, is now available from SIMTEL20:

Filename            Type     Bytes     CRC

Directory MICRO:<CPM.HDUTL>
BU.LBR.1            COM     36992  7E8AH

Here's the author's message about it:

Date: 12/09/84
From: Kim Levitt
To:   All
Re:   BU.LBR

BU is a new "Backup Utility" program that will allow hard disk owners
to quickly back up their system onto floppies.  It was originally based
on BAK25KP, but has been almost completely re-written.  It is not
hardware specific (except for the clear screen sequence, but that is
easily patched without reassembly) and is set up to copy files in
disk/user/alphabetical order and so works nicely on ZCPR/ZCPR2/ZCPR3
systems, but will work on a normal CP/M 2.2 system as well.  Not sure
it will work under 3.0 as it chases the DPH/DPB blocks to determine
disk capacity/blocking size/etc.  May not work under CP/M v1.4 either,
but should work fine on all CP/M v2.2 systems.
30-Dec-84 21:38:13-MST,1358;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 30 Dec 84 21:38:08-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  30 Dec 84 23:04 EST
Date: 30 Dec 1984  21:06 MST (Sun)
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: FBAD58 latest version of bad sector lockout program

The latest version of FINDBAD, the program which does a
non-destructive read of a disk and then creates a dummy file to
allocate bad sectors so CP/M won't use them, is now available from
SIMTEL20:

Filename            Type     Bytes     CRC

Directory MICRO:<CPM.DSKUTL>
FBAD58.AQM.1            COM     25216  F3D9H
FBAD58.COM.1            COM      2176  D033H

Here's the update author's comments on what's new in this version:

...Added the ability to keep bad blocks that were flagged in a
previous [UNUSED].BAD file.  If a block was ever flagged as bad by
this program, it is probably weak.  If on a subsequent test, it makes
it through the BIOS retries and is read successfully, I want the block
to stay in the UNUSED.BAD file.  Removed the code in LTOP which
cleared the high byte of HL after a call to SECTRN.  My BIOS (Morrow
DJDMA) sets the high bit of HL to indicate SIDE 1 of a double sided
drive.

--Keith
31-Dec-84 08:55:47-MST,1328;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 31 Dec 84 08:55:39-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  31 Dec 84 10:20 EST
Date: 31 Dec 1984  08:21 MST (Mon)
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: Warning - VDIR bomb

Relayed from the RCPM Sysop Clearinghouse:

Msg 128 on 12/28/84 from KEN STRITZEL to ALL about VERDIR.LBR BOMB

The program VDIR.COM that is being distributed in VERDIR.LBR is a real
time bomb.  Although the DOC file says that this program produces a
vertical directory listing.  When run, the program destroys all data
on the system and directory tracks and fills them with garbage.  Then
it prints a vulgar message to the effect that "you have just been
had!"  Anyone that has this file on their system should erase it!  I
can not imagine the mentality behind this program, but it should not
be allowed to damage any RCPM or innocent user who happens to download
it.  Another case for NOT distributing .COM files without the source
code.  Thanks to Robert Blacher, sysop of the Computer Connection,
Washington DC, who brought this bomb to my attention.  Flanders, NJ
RCPM, 201+584-9227
31-Dec-84 13:19:01-MST,776;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 31 Dec 84 13:18:48-MST
Received: From brl.arpa.ARPA by AMSAA via smtp;  31 Dec 84 14:57 EST
Received: from mit-mc.arpa by BRL-AOS.ARPA id a003613; 31 Dec 84 14:57 EST
Received: from tennessee by csnet-relay.csnet id a007194; 31 Dec 84 14:54 EST
Date:     Mon, 31 Dec 84 08:57 EST
From:     Phil Geraci <[e-mail]>
To:       [e-mail]

Has anyone tried the Z-80 macro assembler by Mitek?  I saw it advertized
in the January 1985 Dr. Dobbs Journal.  I'd be interested in any comments
about it.  As I am not on the CP/M distribution list, I'd appreciate having
any comments sent to me directly.  Thanks in advance,  Phil Geraci

31-Dec-84 20:39:35-MST,739;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 31 Dec 84 20:39:31-MST
Received: From brl.arpa.ARPA by AMSAA via smtp;  31 Dec 84 22:12 EST
Received: from wisc-rsch.arpa by BRL-AOS.ARPA id a004187; 31 Dec 84 22:09 EST
Date: Mon, 31 Dec 84 21:07:58 cst
From: David Neves <[e-mail]>
Message-Id: <[e-mail]>
Received: by wisc-rsch.arpa; Mon, 31 Dec 84 21:07:58 cst
To: [e-mail]
Subject: CPM to UCSD pascal transfer

Help.  I need a CPM to UCSD file transfer program.  I have one that was
published in Dr. Dobbs in 1980 but the copy I have is garbled in the
middle.  I think I got it at SIMTEL20 but I can't find it now.
-Thanks, David
31-Dec-84 21:26:01-MST,993;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 31 Dec 84 21:25:53-MST
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  31 Dec 84 22:56 EST
Date: 31 Dec 1984  20:58 MST (Mon)
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   David Neves <[e-mail]>
Cc:   [e-mail]
Subject: CPM to UCSD pascal transfer
In-reply-to: Msg of 31 Dec 1984  20:07-MST from David Neves <neves at WISC-RSCH.ARPA>

    Help.  I need a CPM to UCSD file transfer program.  I have one
    that was published in Dr. Dobbs in 1980 but the copy I have is
    garbled in the middle.  I think I got it at SIMTEL20 but I can't
    find it now.  -Thanks, David

There are two available from Simtel20:

Filename            Type     Bytes     CRC

Directory MICRO:<SIGM.VOL008>
PAS2CPM.ASM.2            ASCII      7500  50C6H
PASTOCPM.ASM.2            ASCII     11660  D8DEH

--Keith