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

Text File | 1993-02-13 | 255.1 KB | 6,355 lines

 2-Jul-84 00:48:39-MDT,1680;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 00:48:32-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  2 Jul 84 2:20 EDT
Received: From dca-eur.arpa.ARPA by BRL-AOS via smtp;  2 Jul 84 2:18 EDT
Date: 2 July 1984 06:17 GMT
From: [e-mail]
Subject: MOVCPM generalities
To: [e-mail]
CC: [e-mail]

Date: 2 Jul 1984 05:59:10 Z
Text: Reference your query on MOVCPM.
   Can't help you specifically, but a general description might help.
The program contains general prompt routines, a routine to compare
the imbedded serial number against the serial number in the operating
BDOS, and a relocation module.
   Binary versions of the CCP and BDOS are in the upper portion of
MOVCPM 'orged' to a starting location of 0000H.  When the size of the
new system is selected, (assuming the serial numbers match), the
relocation program starts scanning the "dummy" CCP/BDOS/BIOS and
adding an offset byte to all jumps, calls and references to addresses.
The identification of those bytes is from a table of "bit maps".  If
you are familiar with the Digital Research Page Relocatable Files,
(file type .PRL) this will all be familiar.  If not, trust me, it
works.  The new locations for the "moved" system is as stated in the
system documentation.
   I suffered through an episode similar to yours when I integrated
ZCPR2 into my MOVCPM to make installation easier, and wound up
writing my own linker for relocatable files (.REL), since I use
Microsoft's Macro-80 assembler which does not produce .PRL files.
   Hope this helps.
                         Hal Bower

 2-Jul-84 07:00:40-MDT,1267;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 07:00:34-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  2 Jul 84 8:32 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  2 Jul 84 8:23 EDT
Date: 2 Jul 1984  06:23 MDT (Mon)
Message-ID: <RCONN.12028088413.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Subject: ZCPR3 Phase 1 Release ongoing

    The Phase 1 release of ZCPR3 is definitely taking place.  I
received a call from the San Diego Computer Society (Dick Mason) last
night, and they have received the disks and plan to begin distributing
on Monday (today).  Also, in a phone call with Frank Gaude of Echelon,
I found out that ZCPR3 is now on several large (multi-meg) BBSs in
Silicon Valley and at lease one large on in Los Angeles.
    As of a few days ago, SIG/M had not received theirs, but since
the others are, I suspect it is just a matter of time before SIG/M
does (hopefully days).  Will let you know about things as I find out
myself.
    One other thing -- SIMTEL20 does not yet have ZCPR3 on line,
but we suspect that the package is somewhere in the mail system at
White Sands.  In the words of JEP -- Real Soon Now.

        Rick
 2-Jul-84 07:39:08-MDT,4307;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 07:38:54-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  2 Jul 84 8:56 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  2 Jul 84 8:47 EDT
Date: 2 Jul 1984  06:47 MDT (Mon)
Message-ID: <RCONN.12028092810.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Subject: ZCPR3 Phase 2

... is coming along quite nicely.  The new DU3 is finished, complete
with its online documentation (which is rather extensive) and its new
screen-oriented editor.  The editor ties in as an optional
command-line interface.  You can select it in place of the simple DU3
prompt, and it displays the block you are currently positioned to, a
small menu of commands, and a cursor which points to a byte in that
block.  You can move the cursor around to select any particular byte,
and then you can enter a string of chars or a list of hex values to
place into the block starting at the cursor.  You can then write the
block to disk, advance to the next block, backup to the previous, etc,
as well as issue any value DU3 command string, including macros, to go
through a more complex command sequence and then return to the editor
automatically at the last block you were positioned at.

    DU3, by the way, stands for Disk Utility version 3.  There now
exists the prototype of MU3, a screen-oriented Memory Utility, which
resembles the DU3 screen-oriented editor but works on memory only.
Great for looking at ZCPR3 itself, testing RCPs and FCPs, etc.  I am
concurrently creating the DEBUG Resident Command Package which is a
scaled-down version of MU3, but it can be invoked without impacting
the TPA at all.

    Finally, the new VFILER for ZCPR3 is almost done.  Just a few
hours work on it to go.  I was in the middle of VFILER when Hal Carter
came up with the idea of having an MU3 utility after he saw DU3 run,
and so the break to create MU3 occurred.  I need to play with MU3 a
little to decide what features it really needs before it will be
finished.

    Once  DU3, MU3, and VFILER are done, the last major utility,
VMENU, will be on the agenda.  VMENU is a combination of VFILER and
MENU which I think will be a neat tool by itself.  I have some
concerns about how fast it will be, creating new directory displays
every time it is invoked, and I think these concerns will be resolved
only after VMENU is running and I have used it a few times.

    A few little utilities will also be included in the ZCPR3
Phase 2 release, but they are minor in terms of effort.

    The book is now outlined, with Hal Carter providing many
useful ideas on what its structure and nature should be (thanks, Hal).
I think it will be vastly superior to the ZCPR2 documentation, having
a nice table of contents, index, appendices summarizing commands
available with the various utilities and subsystems, etc.  A lot of
the book can be put together from the online documentation, so that
should go quickly, but there are still major portions which I need to
write.  I hope to have the outline and online documentation fill
complete and sent to the publisher by the end of this week, so this
part can be edited while I proceed with the newer, detailed sections.
The second book, on the ZCPR3 libraries, will also be started soon,
but I'm not sure when.

    In the meantime, the installation manual and user's
perspective document are being printed by Echelon now, and Echelon
plans to distribute it with the $39 basic set of disks.  You can also
get these books independently from Echelon for a small price ($9 was
the last figure I heard).  Contact Echelon for details.  You, of
course, have several options in acquiring hardcopy of this
documentation -- it is on disk and can be printed, but the whole thing
is on the order of 160 pages.  Your local computer club may decide to
make a print run on it also.  Note that I have been talking about the
Phase 1 manuals (on the Phase 1 disks) so far.  The books are a
different matter and will not be available on disk (who would want to
print something THAT BIG anyway?).

    Finally, there may be a ZCPR3 newsletter in the works.  More
details later if this becomes reality.

        Rick
 2-Jul-84 11:52:38-MDT,697;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 11:52:29-MDT
Received: From xerox.arpa.ARPA by AMSAA via smtp;  2 Jul 84 10:57 EDT
Received: from CheninBlanc.ms by ArpaGateway.ms ; 02 JUL 84 07:55:50 PDT
Date: Mon, 2 Jul 84 07:53 PDT
From: [e-mail]
Subject: Help on Enchanter needed
To: [e-mail]
cc: [e-mail]
Reply-To: [e-mail]

I am playing the CP/M version of Infocom's ENCHANTER, but am currently
stuck at 285 points.  I would like to hear from anyone who has gotten
further.

George

PS:  Let me know if there is a better distribution list for type of
request.


 2-Jul-84 15:03:20-MDT,1356;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 15:03:11-MDT
Date:     Mon, 2 Jul 84 16:15:16 EDT
From:     Dave Towson (info-cpm) <[e-mail]>
To:       [e-mail]
Subject:  [Roz:  Touch Typing Teaching Request]

This message was addressed to info-cpm-request.  I don't have any information
about the subject.  Can anyone else help?

----- Forwarded message # 1:

Received: From radc-multics.arpa.ARPA by AMSAA via smtp;  2 Jul 84 13:19 EDT
Date:  Mon, 2 Jul 84 12:26 EDT
From:  "     Roz     " <[e-mail]>
Subject:  Touch Typing Teaching Request
To:  [e-mail]
cc:  [e-mail]
Message-ID:  <[e-mail]>

My husband wants to learn to touch type.  (Due to spending approx 1.5
hrs typing a 7 line letter via hunt-and-peck, last week.)  I have an
S-100 Z-80 based CP/M system with 8" disk drives.  Pointers, comments,
recommendations (both for and against) on software ("games" which teach
are acceptable) are welcome.  Please use E-mail, and if there are any
replies, I will consolidate to the BB (assuming the info isn't already
there).  Thanks a bunch!
                                  Roz

----- End of forwarded messages



Dave Towson
[e-mail]


 2-Jul-84 15:30:24-MDT,689;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 15:30:17-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  2 Jul 84 16:49 EDT
Received: From apg-1.arpa.ARPA by BRL-AOS via smtp;  2 Jul 84 16:43 EDT
Date:  2 Jul 1984 16:28:36 EDT (Monday)
From: William Skidmore DRSTE-TOF 5323 <[e-mail]>
Subject: Dan Jones<[e-mail]>
To: [e-mail]
Cc: [e-mail]

I have modem 7xx overlays for md-2, md-3 and md-11 computers which I
will gladly share with you.  My work phone number is AVN 283-5517.

                                             Bill Skidmore

 2-Jul-84 17:37:49-MDT,698;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 17:37:42-MDT
Received: From su-score.arpa.ARPA by AMSAA via smtp;  2 Jul 84 18:54 EDT
Date: Mon 2 Jul 84 15:43:26-PDT
From: Sam Hahn <[e-mail]>
Subject: Re: [Roz:  Touch Typing Teaching Request]
To: [e-mail]
cc: [e-mail], [e-mail]
In-Reply-To: Message from "Dave Towson (info-cpm) <[e-mail]>" of Mon 2 Jul 84 14:06:05-PDT

I find that HyperTyper is a good piece of software.  Simple, and
easy to use.  Works on about a dozen different areas, eg. asdf/jkl; etc.
It will time you for speed, if that's of interest.
-------
 2-Jul-84 18:39:57-MDT,504;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 18:39:48-MDT
Received: From utexas-20.arpa.ARPA by AMSAA via smtp;  2 Jul 84 20:06 EDT
Date: Mon 2 Jul 84 19:07:23-CDT
From: Douglas Good <[e-mail]>
Subject: BBSes for CP/M
To: [e-mail]

<real systems don't eat lines>

I am trying to open up a BBS but currently have no BBS software. Are there
any other BBS's for CP/M other than RBBS?

        --Doug Good
-------
 2-Jul-84 21:30:11-MDT,2262;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 21:30:01-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  2 Jul 84 22:56 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  2 Jul 84 22:45 EDT
Received: from Usenet.uucp by sri-unix.uucp with rs232; 2 Jul 84 18:41-PDT
Date: 27 Jun 84 8:44:49-PDT (Wed)
To: [e-mail]
From: decvax!decwrl!flairvax![e-mail]
Subject: Re: Zilog SIO as a network controller
Article-I.D.: flairvax.599
In-Reply-To: Article <[e-mail]>

(Get thee behind me!)

First, an appology for posting this netwide, but we are not an ARPANET
site.  Besides, it might be generally amusing.

Z80 SIO's as network controllers are pretty common.  Sytek's Localnet
broadband LAN uses SIO's running at 128Kbits.  I believe that
Corvus' Omninet uses them also (corrections, folks?), and I know of
others more obscure ("Bestnet", for instance).  At usefully high
speeds, one needs to run in a synchronous mode, because in asynchronous
modes the SIO requires a 16*bitrate clock for character framing, whereas in
synch modes it uses a 1*bitrate clock, so for a given quality of clock
circuit one can run 16 times faster in synch mode.  Forget the bisync
mode, as it requires more processor intervention than HDLC mode.  At
speeds in excess of 500Kbits, you will probably need some kind of DMA
circuitry to move the data for you.  The SIO has only one DMA request
line per channel (it is a 2 channel device), so If you want to run
full duplex (and you might, depending on your access method), you will
have to send on one channel and recieve on the other.  No big deal, but
it makes some of the software a little bizzare.  I'm not going to dump
a monologue on possible access methods on the net, except to say that chapter
7 of Tannenbaum's "Computer Networks" is a good place to start, but by
no means an exhaustive look at the problem.

Kevin D. Kissell
Fairchild Research Center
Advanced Processor Development
uucp: {ihnp4 decvax}!decwrl!\
                             >flairvax!kissell
    {ucbvax sdcrdcf}!hplabs!/

"Any closing epigram, regardless of truth or wit, grows galling
 after a number of repetitions"
 2-Jul-84 23:32:49-MDT,1117;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 2 Jul 84 23:32:44-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  3 Jul 84 0:42 EDT
Received: From apg-1.arpa.ARPA by BRL-AOS via smtp;  3 Jul 84 0:30 EDT
Date:  2 Jul 1984 21:06:30 EDT (Monday)
From: Robert Bloom DRSTE-TOI 3775 <[e-mail]>
Subject: Touch Type Tutor
To: [e-mail]
Cc: [e-mail]

I have a public domain typing tutor for cp/m.
It was written by (i fergit - i think it's a Canadian though) and runs
under mbasic.
It supposed to be compilabile, but not having a compiler, I don't know
for sure.  I've adapted it for nearly vanilla CP/M - it needs only a
cursor position sequence and hi/low lighting if you have it.
I'm willing to upload it but think it's already somewhere in the
sig/m or cpmug catalogs - maybe someone else knows.

{Ah-hah ... found it! Sig/m vol 83.  Lessons are TTYPEX?.DAT,
main program ttype.bas, help files tthelp?.dat, and doc file ttype.doc.
And it's from Australia, not Canada (only 180 degrees wrong!).

-bob bloom
 3-Jul-84 01:27:10-MDT,662;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 01:27:06-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  3 Jul 84 2:51 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  3 Jul 84 2:43 EDT
Date: Tue 3 Jul 84 00:43:09-MDT
From: Ron Fowler <[e-mail]>
Subject: MEXNEWS.004 now available
To: [e-mail]

The new MEXNEWS (on SIMTEL20 as MICRO:<CPM.MEX>MEXNEWS.004> provides
an important bug fix for batch-transfer users, some information on
stubborn MDM7 overlays, and the previously missing documentation for
ALDS features provided by MEX.            --Ron Fowler
-------
 3-Jul-84 02:22:29-MDT,2298;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 02:22:06-MDT
Received: From mit-mc.arpa.ARPA by AMSAA via smtp;  3 Jul 84 3:54 EDT
Date: 3 July 1984 03:55-EDT
From: Jerry E. Pournelle <[e-mail]>
Subject:  Magazine Articles
To: [e-mail]
cc: [e-mail]
In-reply-to: Msg of 29 Jun 1984 17:00-EDT from ABN.ISCAMS at USC-ISID.ARPA

As a general case, software in magazines is copyrighted; the
ownership of the rights involved depends on the contract between
author and magazine.  Most magazines buy "all rights" and give
back most to the authors; some professional authors however
never sell anything but "first serial" or some such.
    Thus articles in magazines and programs in magazines
have about the same status: you'd not take a short story from
Analog Science Fiction and put it on the net for all to use
without the author's consent, would you?
    Some authors will give their blessing.  Some authors
would but they don't own the rights and the magazines won't.
    Eventually there will be on line versions of those
programs and download fees (reasonable) which will take care of
your problem.
    Meanwhile, if you type in a program from a magazine and
run it, you are on safe ground; this is clearly "fair use" and
indeed how could you enjoy the magazine which you bought if you
could not?  If you give a copy to a friend, you are in technical
violation of someone's -- probably the author's -- rights, but
no one is likely to complain.  If you type it in and sell it you
are clearly in violation of both ethics and the law.
    Putting it on a bulletin board is, therefore, clearly
illegal; in the past, before there was any way for authors and
publishers to exploit their rights, no one much cared, and
indeed many BYTE programs went the user group and club rounds
with blessing; but now, when it is getting possible to put the
programs on line and charge, I think the authors are entitled to
some consultation.  Many will of course give their programs
away.
    Some cannot afford to do that.
    I could not afford to give my stories and novels away; I
have no other source of income.  I expect that some programmers
must feel the same way about their programs.
JEP

 3-Jul-84 03:50:50-MDT,1166;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 03:50:44-MDT
Received: From xerox.arpa.ARPA by AMSAA via smtp;  3 Jul 84 5:17 EDT
Received: from GreeneKing.ms by ArpaGateway.ms ; 03 JUL 84 02:16:32 PDT
Date: 3 Jul 84 10:16:39+0100 (Tuesday)
From: [e-mail]
Subject: Re: BBS's for CP/M
In-reply-to: CMP.DOUG's message of Mon, 2 Jul 84 19:07:23 CDT
To: Douglas Good <[e-mail]>
cc: [e-mail]

Doug,

After phoning around, I chose CBBS by Ward Christensen and Randy Suess
(spelling?)
and have installed CBBS to my Xerox 820.

It's written in 8080 code and has many features. As well as being
straight forward to use, it runs fast in a small amount of code and has
nice features for unwanted or frivolous guests. It does cost $50 payable
to Randy in Chicago.

If you want to use a high level language you could look into the new one
written in 'C' which has "rooms", can't remember the name offhand,

I'd be interested to hear if anyone has used PL/I for this sort of
thing, I'd heard its the most portable language across the 8 & 16 bit
world.

Ken
 3-Jul-84 10:10:24-MDT,1556;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 10:10:16-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  3 Jul 84 11:31 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  3 Jul 84 9:37 EDT
Date: 3 Jul 1984  07:37 MDT (Tue)
Message-ID: <RCONN.12028364121.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Subject: To Zemon (bad ret adr)

The following was addressed to felix!zemon@berkeley, but the mailer
keeps trapping it.  Sorry for the additional traffic on INFO-CPM.

From: MAILER-DAEMON at Berkeley (Mail Delivery Subsystem)
To:   <RCONN at SIMTEL20.ARPA>
Re:   Returned mail: Host unknown

   ----- Transcript of session follows -----
bad system name: felix
550 <felix![e-mail]>... Host unknown

   ----- Unsent message follows -----
Date: 2 Jul 1984  23:00 MDT (Mon)
From: Richard Conn <RCONN@SIMTEL20>
To: Art Zemon <felix!zemon@BERKELEY>
Subject: Some Metrics on the ZCPR3 Release
In-Reply-To: Msg of 2 Jul 1984  10:31-MDT from Art Zemon <felix!zemon at Ucb-Vax.ARPA>

One other thing -- if a COMPANY wants to include ZCPR3 with their
product, it is here where I hope to make the money.  Echelon grants
licenses for this, and the company can feel that they are not
"ripping off" the author.  If a company goes ahead without the
license, the resulting bad PR could hurt it.  I really don't like the
idea of someone making an outright profit off of the PD, and I am
trying to make a statement here.
 3-Jul-84 10:32:23-MDT,967;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 10:32:18-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  3 Jul 84 11:30 EDT
Received: From apg-1.arpa.ARPA by BRL-AOS via smtp;  3 Jul 84 9:02 EDT
Date:  3 Jul 1984  8:50:27 EDT (Tuesday)
From: Norman Pentz DRSTE-ADA 5279 <[e-mail]>
Subject: Olivetti Printer
To: [e-mail]
Cc: [e-mail]

To anyone having experience or knowledge about the following, please
send your recommendation/advice---------

I am in the market for a printer.  DAK is offering the Olivetti PR-2300
"Dry Ink Jet" printer at 60% off list price.  Is this really a good
printer or are there problems with it or the dry ink technology?

Any information or opinions will be greatly appreciated.  Please
respond directly.  If useful information is generated,  I will
summarize for the net.  Thank you!

                    Norm Pentz
                    npentz@apg-1

 3-Jul-84 11:06:35-MDT,1418;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 11:06:27-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  3 Jul 84 12:22 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  3 Jul 84 12:17 EDT
Date: 2 Jul 1984  22:55 MDT (Mon)
Message-ID: <RCONN.12028269160.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   Art Zemon <felix![e-mail]>
Cc:   [e-mail], [e-mail]
Subject: Some Metrics on the ZCPR3 Release
In-reply-to: Msg of 2 Jul 1984  10:31-MDT from Art Zemon <felix!zemon at Ucb-Vax.ARPA>

ZCPR3 is not in the public domain.  However, I have no intentions of
making any money on it (altho I may make some thru Echelon, but that
is just gravy), and distribution is taking place via the
conventional "public domain" channels.  ZCPR3 is being released to the
User Community, whatever that is.

You see, the whole issue of PD software has turned into such a mess
... if I "call" it PD software, I lose all rights to it.  In the
manner it is going out, the PD community can freely access it without
any loss of rights on my part.  There are conveniences in acquiring it
thru Echelon, such as hardcopy of the documentation and support, but
Echelon is just an alternative you have (as opposed to SIG/M, BBSes,
etc).  Feel free to access it in any manner convenient to yourself.

Rick
 3-Jul-84 12:28:09-MDT,861;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 12:28:01-MDT
Received: From hi-multics.arpa.ARPA by AMSAA via smtp;  3 Jul 84 13:23 EDT
Date:  Tue, 3 Jul 84 12:18 CDT
From:  "David S. Cargo" <[e-mail]>
Subject:  ? OMNIET i/f for S-100
To:  [e-mail]
Message-ID:  <[e-mail]>

Does anybody know if anybody makes/distributes/supports an OMNINET
interface for S-100 computers (ideally with software that runs with
CP/M-80)?  I'm interested in interfacing my IMSAI 8080 to something like
the Corvus Bank, Corvus hard disk servers, and other machines on
OMNINET.  I thought I saw mention of a CompuPro interface in the latest
BYTE.  Any pointers, experiences, war stories, or horror stories
appreciated.

David S.  Cargo (Cargo at HI-Multics)
 3-Jul-84 20:19:00-MDT,1181;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 3 Jul 84 20:18:51-MDT
Date:     Tue, 3 Jul 84 21:29:26 EDT
From:     Dave Towson (info-cpm) <[e-mail]>
To:       [e-mail]
Subject:  [Douglas Good:  Pascal]

I have answered Doug's question regarding BDS-C.  Can anyone help with the
other question?

----- Forwarded message # 1:

Received: From utexas-20.arpa.ARPA by AMSAA via smtp;  2 Jul 84 20:09 EDT
Date: Mon 2 Jul 84 19:10:16-CDT
From: Douglas Good <[e-mail]>
Subject: Pascal
To: [e-mail]

I'm having trouble starting up Pascal on my system (UCSD) and am not finding
the documentation very much help. I have a 64k system and am pretty sure
I have the standard 512byte BIOS. But I can't figure out from reading the
only helpful documentation I could find, BOOTER.DOC, how to set it up. I'm
also looking for BDS-C in the downloads and can't figure out if it's
public domain or not. If so can you tell me where it is?

    All help appreciated,
                Doug Good
-------

----- End of forwarded messages



Dave Towson
[e-mail]


 4-Jul-84 09:42:57-MDT,7008;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 4 Jul 84 09:42:39-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  4 Jul 84 10:54 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  4 Jul 84 10:51 EDT
Date: 4 Jul 1984  08:51 MDT (Wed)
Message-ID: <RCONN.12028639756.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
MMDF-Warning:  Parse error in preceeding line at BRL-AOS.ARPA
Cc:   [e-mail]
Subject: Some Metrics on the ZCPR3 Release
In-reply-to: Msg of 4 Jul 1984  00:00-MDT from <APratt.PA at XEROX.ARPA>

    The following is my reply to a query I have been hearing
recently -- if I know how to modify a BIOS to install ZCPR3, do I
really want to or would ZCPR1 or ZCPR2 do the job?  I felt the
community in general may be interested in the reply.

Yes, it sounds like you *could* install ZCPR3 if you wanted to.  Make
sure you get the source to your BIOS ... all you need to modify is the
BIOS cold boot routine.

ZCPR3 is small in general, depending, of course, upon the features you
select.  My "standard" ZCPR3 system which I use on the AMPRO in slave
mode only interjects about 60K of overhead on disk, but the AMPRO acts
only as a slave in this mode, providing screen display recording and
(in the future) printer spooling.  If used as a primary system will
all of the bells and whistles of ZCPR3 enabled, around 200K of disk
space on the system disk will be taken up by the tools.

Whether you want ZCPR3 for a small system or not depends upon what you
want to do with that system.  ZCPR1 provided a minimum of features to
make any CP/M system more livable.  All (in most cases) COM files
could be placed on disk A and B could be left blank for data and
applications.  ZCPR1 would search along a simple path each time a
command was issued.  ZCPR2 will also do this, as will ZCPR3.  ZCPR1
offered a simple, fixed command-search path, ZCPR2 offered a more
complex command-search path which could be dynamically changed by the
user as he desires (the user could select search from $$ [current
disk/user] to A$ [disk A/current user] to A0, etc), and ZCPR3 offers
what ZCPR2 offered plus flow command packages (IF/ELSE/FI(Endif)),
resident command packages, error handlers, and shells which can all be
dynamically changed by the user at any time.  With these additional
features of ZCPR3 comes additional cost, with the worst cost being
around 10K of additional disk overhead and 2 1/2K less TPA.  The
bottom line is that if your needs are simple (ie, "all I want to do is
run dBASE II"), then ZCPR1 could be all you need.  If your needs are
or could grow into something more complex (ie, "I want command files
which can do looping and IF-THEN-ELSE tests, MENU-driven front ends
for applications environments, the ability to replace the command
processor dynamically with another command processor (shell), and
scripts which can expand into complex command streams from a simple
command I issue"), then ZCPR2 is an intermediate step (with MENUs) and
ZCPR3 is a more advanced step (with all the features mentioned above).

    ZCPR2, while it offered a lot of interesting features and
capabilities, did so at some cost.  A lot of the operating system
overhead existed in the utilities themselves.  ZCPR3 has utilities on
the order of 1/2 to 1/3 the size of their ZCPR2 counterparts because
almost all of the opsys overhead in the ZCPR2 utilities is now gone.
In the phase 1 distribution, the largest utilities were 8K in size
while most of them fell into the 4K or under range.  This makes ZCPR3
more attractive than ZCPR2 for almost all types of systems.

    The smallest system I have seen ZCPR3 run on so far is the
AMPRO Bookshelf.  It has two 400K floppies, and the system overhead on
the A drive, which includes my editors, communications software, and
ZCPR3 tools (not all of them) still leaves about 200K free on the A
drive and all 400K free on the B drive.  With the new AMPRO Bookshelf
coming out with two 800K floppies, I don't see a need to increase the
system overhead at all.

    So, I hope this answers most of your questions.  Your interest
in I/O redirection is answered in the I/O packages of ZCPR3.  These
are packages which can be reloaded dynamically by the system and
provide hosts of I/O drivers beyond what the CP/M I/O byte supports.
In my main system, my prime I/O package supports 8 consoles (which are
combinations of devices, like CRT and modem in parallel and CRT input
with CRT and remote computer output for display recording), 6
printers, and two each of the readers and punches.  It is NOT like
UNIX I/O redirection (using < and > on the command line), but it can
support similar functions.  The standard question which is probably on
your mind is if redirection to a disk file is possible.  The answer is
yes, but I am not happy with any of the solutions I have found except
one, and I don't plan to give that one away.  The heart of the problem
is that the BDOS is not reentrant -- a routine which calls the BDOS,
which in turn calls the BIOS, which in turn calls the BDOS for disk
output will not work since the data from the first BDOS call will be
lost.  I am using a reentrant BDOS (still in testing) which will allow
this, and, with this, disk I/O redirection can be done (especially
with an I/O package doing the work).  If this BDOS is released,
however, a complete competator to CP/M will be out, and it would be
tantamount to stabbing DR in the back, which I would hate to see
happen, especially considering that without them, we wouldn't be in
the world we are with CP/M and its clones, like MS-DOS.  Note that all
of the ZCPRs do not compete directly with DR since you still need the
CP/M 2.2 BDOS to run them.  The ZCPRs do cause competition with CP/M
3.0, but I don't feel that this is a problem since it is all in the
family (one DR product vs another).  Besides, we may someday see a
CP/M 3.0-based ZCPR, and that would be that.

Finally, a Z80 is required for ZCPR1 and ZCPR2 (altho Charlie Strom
created ZC8080 from ZCPR2 which runs on 8080's).  ZCPR3 runs best with
a Z80, but a simple flag makes it run with 8080's as well.

As a bottom line, from my perspective having the needs to use MENUs,
shells, and aliases (scripts) with shell variables, I have moved over
to ZCPR3 completely.  My I/O redirection needs are met by the I/O
packages (note that even with disk I/O redirection, I prefer using a
slave machine [the AMPRO] to direct disk I/O because of some added
flexibility I am discovering with this approach).  And my applications
needs with dBASE II, Word Star et al, MultiPlan, etc, are also met.
Even when I have applications which need large amounts of TPA (the 48K
TPA [out of 62K possible] I have under a full ZCPR3 is not enough), I have
applications-oriented disks which I use which give the needed larger
TPA.

    Rick
 4-Jul-84 22:17:12-MDT,983;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 4 Jul 84 22:17:07-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  4 Jul 84 23:17 EDT
Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp;  4 Jul 84 23:08 EDT
Date: 4 July 1984 23:09-EDT
From: Robert L. Plouffe <[e-mail]>
Subject: MDM730 bug fix
To: [e-mail], [e-mail]

PAT730 V8ASM is in AR101:FJW; at MIT-MC.  The last patch in this
file fixes a serious bug found by Ron Fowler that has been in the MDM
series but not in previous versions of MODEM7.  The bug is a file
pointer error that can cause the 'next' directory entry to be
erased instead of the desired on when overwriting files in batch
mode.  It is highly probable that this bug is also in MDM740, but
I have not searched through the object code to find it, -nor will I.
This again points out the necessity to keep the source code for
public domain programs 'open'..
 4-Jul-84 22:31:07-MDT,15323;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 4 Jul 84 22:30:14-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  4 Jul 84 23:29 EDT
Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp;  4 Jul 84 23:23 EDT
Date: 4 July 1984 23:23-EDT
From: Robert L. Plouffe <[e-mail]>
Subject: pat730 v8asm
To: [e-mail]
cc: [e-mail]

Here is the PAT730 V8ASM file for those that can't FTP:

;    PAT730V8.ASM   --Bob Plouffe  7/4/1984

;    THE CONDITIONAL ASSEMBLY EQUATES ARE DEFAULTED TO
;    GIVE A PLAIN VANILLA MDM730 AS DISTRIBUTED, EXCEPT
;    FOR CERTAIN CHANGES WHICH ARE CONSIDERED AS BUG FIXES.
;    THESE ARE LISTED UNDER THE 'FIXED' EQUATE WHICH IS NOW
;    ALWAYS TRUE.  THE REMAINDER OF THESE PATCHES ARE OPTIONS.
;      SET THEM AS YOU WISH FOR THE OPTIONS ALLOWED BELOW.

; V8    Fixed a bug found by Ron Fowler that causes the wrong
;       file to be erased in the directory when overwriting existing
;       files in batch mode. This bug has been in all the MDM series
;    but not prior versions of generic MODEM7    -Bob Plouffe

; V7    Added Hoff fix for alternate long distance dialling
;    and his fix for "DISK-FULL" when in ASCII capture mode.
;    Removed code at CKSMLP that caused endless loop in batch
;    mode with filenames that have checksum of 1AH, 0DH or 0AH.
;                           -Bob Plouffe

; V6    Added FIXFNK option to patch logon send routine to work right
;               in 'half-duplex' (L) terminal mode
;       Added LOCSTRT option to start terminal mode in 'half-duplex'
;               (L) mode when connection made.  This modification
;               overrides the ONERING and NORING mods.  It rings
;               once, then jumps to local mode.     -Ross Alford
;***********************************************************************
;IMPORTANT:     if FIXFNK is used, SAVE 74 rather than 73 after
;               overlaying the patches
;***********************************************************************

; V5    Added UNDO-J as an option.
;    Corrected bug in SENDFN routine.
;    Corrected bug in Irv's NORING option.       - Bob Plouffe

;This patch overlay file will retain the capability to get
;progress reports at a remote-end that answers under BYE and
;when the "Q" switch is not used on the command line.

;Also changes the max-wait times at several locations
;including inside the receive-sector loop.  This SUBSTANTIALLY
;improves performance on networks with packet delays.
;Suggest 16 seconds but not less than 5.

;Just assemble this file as an ASM file and overlay the HEX file
;on MDM730.COM with DDT  and SAVE 73 MDM730.COM.   If you have
;the source code, you should be able to locate the changes at
;the labels shown below.   It is NOT INTENDED to change the
;revision number of MDM730 at this time. Treat this patch file
;as a customization just like when you use one of the patch
;overlays for a specific hardware configuration.

;This file also includes the Hoff patches for BELL and RUB
;and can be conditionally assembled for the way you want it.


TRUE    EQU    0FFH
FALSE    EQU    0


;Setting LOCSTRT to true will make two modifications to MDM730:
;       -it will perform the equivalent of the ONERING modification
;        that appears elsewhere in this file
;       -MDM730 will go into L terminal mode (local echo) rather
;        than T terminal mode when a connection is made by an autodial
;        modem.

LOCSTRT  EQU     FALSE

;Set both of these bytes FALSE if you wish to have console bell
;continuously beep until a keyboard character is hit after doing
;a dial retry and a connection occurs.  Set ONERING to TRUE if
;you want only one beep to occur and NORING to TRUE if you don't
;want any beeps at all.   DON'T set both of these bytes to TRUE.

ONERING    EQU    FALSE
NORING    EQU    FALSE
;
;
RUB2BKSP EQU    TRUE    ;want to convert RUB key to BKSPC?
;
;***********************************************************
;
;To get rubout character to go to console set RUBCON to TRUE
;and IGNORCTL to FALSE.  If you wish to have control chars
;filtered, then RUB will be filtered also. You can also set
;both of these to FALSE. TRUE/TRUE will filter control chars
;but will not feed RUB to console.

RUBCON     EQU    FALSE    ;want rubout to go to console?
IGNORCTL EQU    TRUE    ;TRUE sets control character filter
;
FIXED EQU    TRUE    ;Fix to directory pointer problem
            ;Fix to alt long distance dialling.
            ;Fix "DISK-FULL" problem in capture mode.
;(ALWAYS TRUE)        ;Fix to remove endless loop with some
            ;filenames in batch mode.
            ;Fix to SENDFN routine so that if remote
            ;end is under BYE and 'Q' switch not set
            ;on command line, and if a file name begins
            ;with a 'C', the next file name is not
            ;aborted.   Also provides a slight format
            ;improvement for the "Bad sector # in header"
            ;message.  This is no longer a conditional
            ;equate and is always true.

UNDO$J     EQU    FALSE    ;Set to TRUE to restore the 'T' option and
            ;so that remote end doesn't automatically
            ;come up in terminal mode. (Unless remote is
            ;using MDM730 with this option set FALSE).

MAXWAIT     EQU    5    ;suggested value is 16 for packet networks
            ;which may exhibit excessive packet delays.

FIXFNK   EQU    FALSE   ;patch LOGLP logon transmit routine to echo
                        ;to console in L mode, and not to wait so
                        ;long between characters in L mode
                        ;***NOTE that if you use this modification the
                        ;size of MDM730.com must be increased to 74 pages
                        ;when you save it***

BELL     EQU    07H
LF     EQU    0AH
CR     EQU    0DH
RUB     EQU    7FH
TERM     EQU    1618H
RETURN     EQU    197EH
EXITTEST EQU    1E79H
SENDRDY  EQU    1E41H
WAITNLP     EQU    2958H
SENDACK     EQU    18A4H
GETACK     EQU    2581H
STAT     EQU    2B88H
TYPE     EQU    2B9DH
DIALAD2     EQU    0803H
DIALEXIT EQU    0799H
WREXIT     EQU    2126H
CLOS3     EQU    476CH
WRERR0     EQU    0DC5H
LOGLP   EQU     1E5DH           ;send logon message or fnk key
LOGLP1  EQU     1E6DH           ;get echo if T mode
LOCFLG  EQU     499BH           ;set if L mode
MFNAME6 EQU     4A9BH           ;this +12 is start of stack area
SPEED2  EQU     1A57H           ;delay routine

;*************************************************************
;
;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

;At the IGNORCTL byte storage location
    ;
    IF    IGNORCTL
    ORG    011DH
    DB    0FFH        ;sets control character filter
    ENDIF

    IF    NOT IGNORCTL
    ORG    011DH
    DB    0
    ENDIF

;
;***********************************************************



;In routine SENDC2
    ORG    1782H
    MVI    E,120

;In routine SENDFN
    ORG    1BB2H
    DB    0,0
    ;
    CALL    GETACK
    CC    SENDACK


;In routine ACKLP
    ORG    1BF3H
    MVI    B,MAXWAIT

;In routine CKSMLP
    ORG    1C0CH
    MVI    B,MAXWAIT

;In routine SCKSER
    ORG    1C56H
    MVI    E,120

;In routine NMLP1:
    ORG    1D03H
    MVI    B,MAXWAIT

;In routine HSNAK
    ORG    1D51H
    MVI    E,180
    ;
;In routine HSNAK1
    ORG    1D5FH
    MVI    B,1        ;Yes, a 1



    ORG    1E4AH
;Suggested by Irv Hoff to improve the ability to catch extra
;function key characters.

SENDNOW CALL    EXITTEST    ;see if ready to quit now
    CALL    SENDRDY        ;ready to send a character?
    JNZ    SENDNOW        ;if not ready,wait some more
    RET            ;exit if ready


;In routine RCVSOH
    ORG    240AH
    MVI    B,MAXWAIT
    ;
    ORG    2413H
    MVI    B,MAXWAIT

;At label RCVBSE
    ;
    ORG    242AH
            ;These 2 bytes replace CR,LF
    DB    80H,80H    ;slight format improvement here for:
            ;'++ Bad record # in header '


;In routine RCVCHR
    ORG    245EH
    MVI    B,MAXWAIT
    ;
    ORG    2477H
    MVI    B,MAXWAIT

;In routine RCVCRC2
    ORG    2496H
    MVI    B,MAXWAIT


;In routine WAITNLP
    ORG    2988H
    MVI    B,1        ;yes, a 1
;

;***********************************************************
;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.

    ORG    2AFBH
    IF    UNDO$J
    DB    0C2H
    ENDIF
    ;
    IF    NOT UNDO$J
    DB    0CAH
    ENDIF

    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

;*******************************************************************
;The LOCSTRT patch
;(Starts in L mode after successful dial of phone)
;Overrides the ONERING and NORING patches below:
;  result is equivalent to ONERING
;
        ORG     06EAH           ;Same place as the ONERING mod
;
        IF      LOCSTRT
        PUSH    PSW             ;save A reg
        MVI     A,0FFH          ;load FF into A to
        STA     LOCFLG          ;set LOCFLG for L mode
        POP     PSW             ;restore A
        JMP     RETURN          ;continue as in ONERING
        ENDIF                   ;LOCSTRT
;
           IF      NOT LOCSTRT     ;Restores original
        CALL    STAT
        JZ      06F7H           ;?
        CALL    2B93H           ;?
        XRA     A
        ENDIF                   ;NOT LOCSTRT

;*********************************************************************
;This patch removes code at CKSMLP which was intended to provide
;compatibility with older versions of MODEM7 only when used in batch
;mode and only when a remote is under 'BYE' and the 'Q' switch not set.
;Unfortunately, the incompatibility can't be resolved and the only
;penalty is that the 'Q' switch MUST be set at remote-under-BYE in
;batch mode if that end is an older version of MODEM7.  The code
;that is herewith removed caused a problem when (in batch mode) filenames
;had a checksum of 1AH, 0DH or 0AH. It was possible to go into an
;endless loop.  This patch cures that disease.

    ORG    1C11H
    DB    0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
        ;27 of them.
        ;Removes lines in CKSMLP routine beginning with
        ;CPI EOFCHR and ending with MVI A,LF inclusively.
;**************************************************************************
;The following patches are inserted into the LOGLP routine that
;sends the LOGON message and programmable function keys.  A call is altered
;to point to the patch, which is located at the bottom of the stack area.
;This should be a fairly safe location in MDM730, which seems to have lots
;of stack space
;
        ORG     LOGLP+9
        IF      FIXFNK
;
        CALL    LPATCH          ;replaces CALL LOGLP1
;
        ORG     MFNAME6+12      ;put the patch at start of stack
LPATCH:    MOV     B,A             ;save A in B
        LDA     LOCFLG          ;flag for L mode
        ORA     A               ;check if set
    JZ      LOGLP1          ;not set-do normal stuff
        MOV     A,B             ;reclaim A
        CALL    TYPE            ;character -> console
        MVI     C,01H           ;delay a short while
        JMP     SPEED2          ;and return
        ENDIF                   ;FIXFNK
;
        IF      NOT FIXFNK
        CALL    LOGLP1
        ENDIF                   ;Not FIXFNK

;*********************************************************************
;
;Options below are by Irv Hoff modified for inclusion in this
;patch overlay file by Bob Plouffe:

;     Some people have mentioned they are annoyed with the bell ringing
;constantly after a connect when auto-dialing with MDM730.  The following
;two small changes will stop that:

;
;1) WILL ONLY RING ONE TIME then go to terminal mode after announcing it
;   has connected:


;At CONMADE2
    ORG    06EAH
        IF      ONERING AND (NOT LOCSTRT)
    JMP    RETURN
    ENDIF
    ;
    IF      NOT (ONERING OR LOCSTRT)
    CALL    STAT
    ENDIF
    ;

;2) WILL NOT RING AT ALL, but go right to terminal mode after announcing
;   it has connected.

;In routine at CONMADE1
    ORG    06E3H
        IF      NORING AND (NOT LOCSTRT)
    DB    00
    JMP    RETURN
    ENDIF
    ;
    IF     NOT NORING
    DB    BELL,0
    MVI    B,5
    ENDIF
;

;     Several people were having trouble getting normal backspace with
;their rub (delete) key.  MDM730 offers the option of changing rub to
;backspace.

;    1)  Can preset the default option so rub comes up as backspace
;        (or preset the default so it comes up as normal rub)
;    2)  At any time use the menu option to change it temporarily
;        to the opposite configuration.


;     Some mainframes will not accept a normal backspace and require a
;rub (delete) character to provide a type of "forward backspace".  If
;you need this feature and your terminal does not have a rub (delete)
;key, or if inconvenient to use, then set RUB2BKSP to TRUE

;In the routine TERM:
    IF    RUB2BKSP
    ORG    1629H
    CPI     7FH    ;RUB
    ;    ....
    ORG    1635H
    MVI     B,08H    ;BCKSPC
    ENDIF

    IF    NOT RUB2BKSP
    ORG    1629H
    CPI    08H
    ;    ....
    ORG    1635H
    MVI    B,7FH
    ENDIF

;     (The menu will still indicate you are changing rub to backspace,
;ignore this statment and realize just the opposite is happening with
;this change.)           - Irv Hoff


;-----------------------------------------------------------------------

;     There are two obscure bugs in the MDM730 program.  The first in-
;     volves the alternate long distance dialing system - occasionally
;     the last digit of the billing code would be entered twice, messing
;     up the correct dialing.  The second involves a problem existing
;     since the early MODEM7 days which has never been corrected.  When
;     copying to disk in the terminal mode, if the disk fills, the pro-
;     gram says it is saving as much of the copy as it can.  It then
;     closes the file - only it was closing the file normally used for
;     file transfers.  The following patch corrects both problems.  As
;     they only recently came to my attention, it is obvious the typical
;     user (including me) has never run into either problem.
;                        --    Irv Hoff

;       THIS IS THE ALTERNATE LONG DISTANCE DIALING CHANGE
;       FOR 'SPRINT', 'MCI', ETC. USERS.

;in the routine at DIALAD2
    ORG    806H
    JZ    DIALAD3    ;same but DIALAD3 has a new address

    ORG    0DC0H
BRIDGE:    CALL     TYPE    ;patch added at this empty location
    POP    H
    RET

;in DIALAD2
    ORG    819H
    JNZ    DIALAD2
    POP    H
    JMP    DIALEXIT
;
DIALAD3:MVI    A,' '
    MOV    B,A
    JMP    BRIDGE    ;out of space here


;      THIS IS THE CHANGE FOR "DISK-FULL WHEN IN ASCII
;      CAPTURE MODE.  EVERYBODY NEEDS THIS ONE.


    ORG    0DC5H
WRERR0:    CALL    CLOS3
    JMP    WREXIT    ;WREXIT label is at the call to ERXIT
            ;in the routine WRERR

;in the routine at WRTDSK2
    ORG    210CH
    JNZ    WRERR0    ;instead of JNZ    WRERR

;in the routine at NOWRITE
    ORG    214EH
    CALL    CLOS3    ;instead of CALL CLOSFIL.
            ;CLOS3 label is at the line LXI D,FCB3
            ;in the WRTFIL1 routine

;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

    ;the
    END

 5-Jul-84 06:58:12-MDT,617;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 5 Jul 84 06:58:07-MDT
Received: From brl-vgr.arpa.ARPA by AMSAA via smtp;  5 Jul 84 8:31 EDT
Received: from simtel20.arpa by BRL-VGR.ARPA id a004496; 5 Jul 84 8:25 EDT
Date: Thu 5 Jul 84 06:21:17-MDT
From: Jim Forrest <[e-mail]>
Subject: BYE AND ANCHOR MARK XII
To: [e-mail]
cc: [e-mail]

Has anyone been able to successfully run any version of BYE with a
Signalman Anchor Mark XII ? I have been trying on a Kaypro 10 with no
luck (refusal to answer).

Jim
-------
 5-Jul-84 07:52:00-MDT,974;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 5 Jul 84 07:51:53-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  5 Jul 84 9:21 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  5 Jul 84 9:18 EDT
Received: from Usenet.uucp by sri-unix.uucp with rs232; 5 Jul 84 6:07-PDT
Date: 2 Jul 84 7:07:11-PDT (Mon)
To: [e-mail]
From: ihnp4!inuxc!inuxd![e-mail]
Subject: 5.25 Disk Formats
Article-I.D.: inuxd.570



I am trying to customize a CPM BIOS for an homebrew Z80 based
system.  I would like to know if anyone has suggestions as to
what 5.25" SSDD disk format to use so that I might be able
to order CPM sotware in a format familiar to distributors.
Any suggestions would be welcome especially if detailed information
such as number of sectors/track and number of bytes/sector is
available.

                Ron Wolenty (ATT Consumer Products)
                Indianapolis, IN
                inuxd!wolenty
 6-Jul-84 05:58:18-MDT,661;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 6 Jul 84 05:58:15-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  6 Jul 84 7:37 EDT
Received: From ucla-locus.arpa.ARPA by BRL-AOS via smtp;  5 Jul 84 23:52 EDT
Date:           Thu, 5 Jul 84 20:06:28 PDT
From:           Jody Paul <[e-mail]>
To:             [e-mail]
Subject:        XLISP on SIMTEL20? (REQUEST)

I thought I saw a message just a little while ago that said that
XLISP was on SIMTEL20.  If that's so, what directory is it in?
If not, where can I locate the source?

            Thanks,
             Jody Paul
            jody@ucla-locus
 6-Jul-84 06:47:07-MDT,2028;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 6 Jul 84 06:46:59-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  6 Jul 84 7:42 EDT
Date: 5 Jul 1984  20:31 MDT (Thu)
Message-ID: <WANCHO.12029029331.BABYL@SIMTEL20>
From: "Frank J. Wancho" <[e-mail]>
To:   [e-mail]
Subject: CUG Software Tools Available

Courtesy of Bernie Eiben, the CUG Software Tools collection is now
available in MICRO:<CPM.CUG> as a set of 12 .LBR files and a 13th
SQueezed file containing the LDIR output of the 12.  The current space
crunch and the pending upload of several new SIG/M and PC-BLUE volumes
prevent me from running DE-LBR on these files.

Here's an extract of Bernie's original announcement:

    Based on RATFOR programs published in Software Tools by Brian
    Kerrighan and P.J. Plauger, published by Addison-Wesley in 1976.
    Updated and maintained by the Software Tools Users Group [CUG] -
    distributed on the "basic tape" or 12 floppies.  Here they are in
    LBR-form and squeezed.  SOFTTDIR.QQQ is a squeezed directory of
    all 12 of them - have fun [buy some floppies before You start..].
--------------------

Note that these files are BINARY, and thus do not have the ITS header.

Filename            Type     Bytes     Sectors     CRC

Directory MICRO:<CPM.CUG>
SOFTT-1.LBR.1            BINARY    118528  926 = 39EH  57BBH
SOFTT-10.LBR.1            BINARY    106112  829 = 33DH  9B85H
SOFTT-11.LBR.1            BINARY    133888 1046 = 416H  8830H
SOFTT-12.LBR.1            BINARY    100480  785 = 311H  3875H
SOFTT-2.LBR.1            BINARY    107904  843 = 34BH  9D40H
SOFTT-3.LBR.1            BINARY     92160  720 = 2D0H  A353H
SOFTT-4.LBR.1            BINARY    102528  801 = 321H  EC05H
SOFTT-5.LBR.1            BINARY     86400  675 = 2A3H  2C10H
SOFTT-6.LBR.1            BINARY     93824  733 = 2DDH  6194H
SOFTT-7.LBR.1            BINARY    140544 1098 = 44AH  A36FH
SOFTT-8.LBR.1            BINARY    114432  894 = 37EH  B4D0H
SOFTT-9.LBR.1            BINARY    119936  937 = 3A9H  300EH
SOFTTDIR.QQQ.1            BINARY      4608   36 =  24H  6291H

--Frank
 6-Jul-84 07:56:14-MDT,855;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 6 Jul 84 07:56:10-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  6 Jul 84 9:30 EDT
Received: From xerox.arpa.ARPA by BRL-AOS via smtp;  6 Jul 84 9:24 EDT
Received: from GreeneKing.ms by ArpaGateway.ms ; 06 JUL 84 06:23:52 PDT
Date: 6 Jul 84 14:19:04+0100 (Friday)
From: [e-mail]
Subject: Re: 5.25 Disk Formats
In-reply-to: ihnp4!inuxc!inuxd!wolenty's message of 2 Jul 84 7:07:11 PDT
 (Mon)
To: ihnp4!inuxc!inuxd![e-mail]
cc: [e-mail]

The format that I would suggest if you are using 40 tracks is;

    256 bytes per sector
    17 sectors per track
    3 reserved tracks
    155K bytes disk capacity

The data architecture could be to an IBM system 34 format or modified as per Xerox


Hope this helps//Ken

 6-Jul-84 14:31:55-MDT,632;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 6 Jul 84 14:31:45-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  6 Jul 84 16:04 EDT
Received: From crdc.arpa.ARPA by BRL-AOS via smtp;  6 Jul 84 15:53 EDT
Date:     Fri, 6 Jul 84 15:37:23 EDT
From:     George R. Famini <[e-mail]>
To:       [e-mail], [e-mail],
          [e-mail]
Subject:  userid change

Our Vax seems to be functioning now... please change my userid in the mailing
lists from famini@amsaa to grfamini@crdc.    Thanks.... George Famini
 7-Jul-84 11:50:27-MDT,536;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 7 Jul 84 11:50:23-MDT
Received: From mit-mc.arpa.ARPA by AMSAA via smtp;  7 Jul 84 13:30 EDT
Date: 7 July 1984 04:47-EDT
From: Jerry E. Pournelle <[e-mail]>
Subject:  ? OMNIET i/f for S-100
To: [e-mail]
cc: [e-mail]
In-reply-to: Msg of Tue 3 Jul 84 12:18 CDT from David S. Cargo <Cargo at HI-MULTICS.ARPA>

yes. Corvus has an S-100 imninet as well as for PC apple and
their own corvus concept

 7-Jul-84 13:17:01-MDT,1873;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 7 Jul 84 13:16:53-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  7 Jul 84 14:54 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  7 Jul 84 14:43 EDT
Date: 7 Jul 1984  12:43 MDT (Sat)
Message-ID: <RCONN.12029468347.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Subject: ZCPR3 Phase 1 Being Received

    I received a phone call from Steve Leon at SIG/M this morning,
and SIG/M has now received ZCPR3 Phase 1.  It will be released
starting at Volume 184.  All CRCs of all files check out.

    Frank Wancho at White Sands has also received the Phase 1
distribution, and Frank plans to upload it to SIMTEL20 soon.  Will let
you know when it is available.

    I have been receiving several reports from Silicon Valley on
ZCPR3 progress, and all have been favorable.  People are getting the
system up without too much difficulty (especially if they have ZCPR2
knowledge already), and absolutely no bugs have been reported.  The
beta testing seems to have been quite successful.

    The ZCPR3 Phase 2 effort is coming along quite nicely, with
everything coming up.  DU3, with its new screen-oriented editor, and
VFILER are complete now.  I am working on VMENU, which is a cross
between VFILER and MENU, allowing the user to point to a file in the
file display and invoke a menu command on that file.  All of these
utilities are screen-oriented, using highlighting, clear screen,
cursor addressing, etc, and they port very easily between ZCPR3
systems, with a simple installation via the Z3INS routine being all
that is necessary to do the port.  To say the least, with ZCPR3 now we
have the CP/M transportability concept extended to include
screen-oriented utilities.

    Will keep you posted.

        Rick
 8-Jul-84 00:50:11-MDT,1471;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 8 Jul 84 00:50:05-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  8 Jul 84 2:29 EDT
Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp;  8 Jul 84 2:26 EDT
Date: 8 July 1984 02:25-EDT
From: Paul L. Kelley <[e-mail]>
Subject: movcpm synchronization errors
To: [e-mail]
cc: [e-mail]



        BDOS jump checking in MOVCPM.


    LXI    B,STORAGE    ;MOVCPM has already read the presumed address
                ;of the running BDOS from 0006 and stored it
                ;away
    LDAX    B        ;get least significant byte of running BDOS
                ;address
    CPI    6        ;is it really BDOS or perhaps DDT?
    MVI    A,0        ;get ready to put the address of the running
                ;serial number in STORAGE
    JNZ    SYNCERR        ;give synchronization error if not the correct
                ;BDOS address modulo a page
    STAX    B        ;STORAGE now has address of start of running
                ;serial number


        Serial number checking in MOVCPM.


    LXI    D,MOVCPM$SERNO    ;location of serial number in MOVCPM's
                ;relocatable version of BDOS. This is at
                ;the start of the relocatable BDOS.
    LHLD    STORAGE        ;get the address of the running serial number
    MVI    C,6        ;length of serial number
LOOP:    LDAX    D        ;compare MOVCPM's serial number with
    CMP    M        ;running BDOS's serial number
    JNZ    SYNCERR        ;give synchronization error if CMP fails
    INX    H        ;check
    INX    D        ;    all
    DCR    C        ;        six
    JNZ    LOOP        ;            bytes


 8-Jul-84 02:43:12-MDT,1421;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 8 Jul 84 02:43:07-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  8 Jul 84 4:11 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  8 Jul 84 4:02 EDT
Received: from Usenet.uucp by sri-unix.uucp with rs232; 7 Jul 84 1:14-PDT
Date: 5 Jul 84 13:24:19-PDT (Thu)
To: [e-mail]
From: hplabs!sdcrdcf!sdcsvax!sdccs6![e-mail]
Subject: Big Board II - Take 2
Article-I.D.: sdccs6.1588

I am looking into the purchase of a Big Board II from CalTex computers of
San Jose.  { [phone] } The price of an A&T board just dropped to
$550.  The board supports 5.25" and 8" drives, single/double density, has a
terminal chip which emulates a Lear Seagler ADM 31, four par. ports, two
serial ports, two CTCs and 64k of RAM (60k available to user)

Considering I could get the board, and CP/M 2.2 for $700.  It seems to be a
very good deal.  Anyone have any good or bad experiences with it?  Where
can I get decent drives, power supplies, and keyboards to go with it.
Caltex mentioned a place called Halted in San Jose.  Anyone ever dealt with
this company.

Thanks again.



                                    John Antypas
                                    U.C. San Diego

               UUCP:   ...!sdcsvax!sdccs6!ix255
               arpanet: sdcsvax!sdccs6!ix255@Berkeley
 8-Jul-84 02:43:34-MDT,771;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 8 Jul 84 02:43:30-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  8 Jul 84 4:11 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  8 Jul 84 4:03 EDT
Received: from Usenet.uucp by sri-unix.uucp with rs232; 7 Jul 84 1:25-PDT
Date: 5 Jul 84 5:15:56-PDT (Thu)
To: [e-mail]
From: hplabs!sdcrdcf!sdcsvax!akgua![e-mail]
Subject: Dobbs Screen Editor Documentation
Article-I.D.: akgua.867

   Now that I have a copy of the Dobbs screen editor, it
sure would be nice to get a little direction on how to use
it. I suppose it would be best to post lengthy stuff to net.sources.

                              Thanks in Advance <-<-<-<-<-<-<
 8-Jul-84 02:44:18-MDT,2292;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 8 Jul 84 02:44:12-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  8 Jul 84 4:12 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  8 Jul 84 4:06 EDT
Received: from Usenet.uucp by sri-unix.uucp with rs232; 7 Jul 84 3:21-PDT
Date: 5 Jul 84 6:10:40-PDT (Thu)
To: [e-mail]
From: ihnp4!mgnetp!burl![e-mail]
Subject: National 8250 initialization routine needed
Article-I.D.: burl.490

--
Well, I've gotten the terminal emulator to work on my h-89, but I'm
still having problems with my downloading routine. Is there anyone
out there who can verify that I'm setting my I/O up correctly? I
have my modem on a port that I have initialized for 8 bits no parity
at 300 baud. I am not using an interrupt driven routine so the
interrupt enable register is zeroed out. To determine if data is
present I test the DATA READY bit in the line status register. I
guess what I really need (assuming all the previously mentioned
parameters are correct) is for someone to explain the Christiansen
Protocol. I am able to retrieve 1 record of data from an RCPM, but
subsequent records get trashed. HELP!! What I need to know is:
    1. What is the actual length of each transfer (including
       checksum, etc)?
    2. What handshaking signals are necessary and when?
    3. Any other pertinent info.
Presently, to start the transfer, I send a NAK and after each 128
byte record received, I send an ACK. I've set up the software to
return the RCPM's EOT with one of it's own.
If anyone has a working modem program on a Heath H-89, please let me
know. I'll mail you a disk if you can copy it for me. I'd like to
get my program running, but that's not the foremost consideration if
I can procure an already operating one. My dilemma is that <gasp>
I'm still using hard-sectored disks. I've had people offer me stuff
in the past, but alas, my machine can't read it because they only
use sft sectored disks. Again HELP!
Thanks in advance.
--
>From the non-linear mind of a non-anonymous hacker!!
                Pete Hermsen
ihnp4!    \            PO Box 2304
akgua!     \burl!pmh        Burlington, NC 27216
cornell! /            [phone] (w)
ulysses!/

"Not all roads lead to Hollywood..."
 8-Jul-84 15:38:21-MDT,847;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 8 Jul 84 15:38:17-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  8 Jul 84 17:13 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  8 Jul 84 17:11 EDT
Received: from Usenet.uucp by sri-unix.uucp with rs232; 7 Jul 84 7:05-PDT
Date: 6 Jul 84 7:23:16-PDT (Fri)
To: [e-mail]
From: hplabs!sdcrdcf!sdcsvax!akgua!psuvax1!burdvax![e-mail]
Subject: Xerox 820-I clearinghouse/mailing list/bulletin board system
Article-I.D.: burdvax.1591

Does anyone know of any information clearinghouses dedicated to
the Xerox 820-I system?  If not, and there is sufficient interest,
I'm willing to start a mailing list.  Please reply by mail if
you'd be interested in exchanging 820-specific information.

                    - Ralph Droms
 9-Jul-84 00:21:46-MDT,1498;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 9 Jul 84 00:21:40-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  9 Jul 84 1:52 EDT
Date: 8 Jul 1984  23:53 MDT (Sun)
Message-ID: <WANCHO.12029852532.BABYL@SIMTEL20>
From: "Frank J. Wancho" <[e-mail]>
To:   [e-mail]
Subject: MICRO:<SIGM.VOL165> Reloaded

The files in the subject directory have been reloaded due to problems
with the original uploaded files.

My thanks to those who discovered the problems and reported the
situation.  If problems are discovered with any files in
MICRO:<SIGM.*>, <CPMUG.*>, <PC-BLUE.*>, or <UNIX.*>, let me know.

Note: as many of you who are able to use FTP to SIMTEL20 have
discovered, the use of CWD (Change Working Directory) does NOT work
with the ANONYMOUS FTP Login.  Please don't bother to try it until you
see an announcement from me that something has been worked out.

After going through three disk controllers and associated software, I
have (finally!) been able to transfer Rick's 10 ZCPR3 and 4 SYSLIB3 8"
disks to N* format, and all CRCs match!  The disks are now ready to be
uploaded and should be available before the weekend.  Look for another
announcement.  (Anybody have a *working* CCS2422 Rev B driver for
TurboDOS 1.22 or 1.3 that doesn't generate memory parity errors, or
know why a DJDMA Rev 3B decides it can only read double density disks
under CP/M 2.2, contact me.)

--Frank
 9-Jul-84 10:03:57-MDT,1205;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 9 Jul 84 10:03:47-MDT
Received: From ucb-vax.arpa.ARPA by AMSAA via smtp;  9 Jul 84 11:28 EDT
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.31)
    id AA09487; Mon, 9 Jul 84 08:29:12 pdt
Received: from ucbpopuli.CC.Berkeley.ARPA (ucbpopuli.ARPA) by ucbjade.CC.Berkeley.ARPA
    (4.14/4.20) id AA06771; Mon, 9 Jul 84 08:28:55 pdt
Received: by ucbpopuli.CC.Berkeley.ARPA
    (4.14.3/4.20) id AA14724; Mon, 9 Jul 84 08:28:46 pdt
Message-Id: <[e-mail]>
Mailed-From: Bitnet-site Boston University (IBM 3081-D VM/SP(MP))
Return-Path:  <eng20201%BostonU.Bitnet@Berkeley>
Date:       9-Jul-84
From: John Sutter <[e-mail]>
Subject: Superbrain...
To: [e-mail]

------

  I have a Superbrain and an ATR8000.  My secretary uses the Superbrain
for Wordstar.  What I would like to do is use some small utility so
that I could hack over what she did on the Superbrain with Wordstar
on my ATR8000...
  If anyone has any ideas, or utilities!!!, I would really appreciate it...

  ----  John
------

 9-Jul-84 12:01:33-MDT,11516;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 9 Jul 84 12:01:00-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  9 Jul 84 13:07 EDT
Received: From amsaa.arpa.ARPA by BRL-AOS via smtp;  9 Jul 84 12:59 EDT
Date:     Mon, 9 Jul 84 12:53:31 EDT
From:     David Towson (CSD) <[e-mail]>
To:       Jody Paul <[e-mail]>
cc:       [e-mail]
Subject:  Re:  XLISP on SIMTEL20? (REQUEST)

Jody - Here is a collection of messages pertaining to XLISP.  Please let me
know if you successfully obtain a copy, and how.


Dave
[e-mail]


Received: From Brl-Bmd.ARPA by AMSAA via smtp;  1 Jan 84 22:57 EST
Date:     Sun, 1 Jan 84 22:43:51 EST
From:     Paul Broome <broome@brl-bmd>
To:       BRINT <abc@brl-bmd>
cc:       steve@brl-bmd, broome@brl-bmd, howard@brl-bmd, towson@amsaa
Subject:  Re:  XLISP

Here's a message on XLISP I had filed away long ago.  It sounds very
interesting; it's theme is object oriented programming in LISP.  Since
he referred to the book LISP by Winston and Horn in building it, it'll
look like MACLISP.  Can  you pick up a copy to run under UNIX also?   -p

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





Date: 18 Mar 83 17:48:51-PST (Fri)
To: [e-mail]
From: David Betz <decvax!betz (David Betz)@ucb-vax.arpa>
Subject: New XLISP release
Article-I.D.: decvax.441
Received: from Usenet.uucp by SRI-Unix.uucp with rs232; 19 Mar 83 0:03-PST
Received: From Sri-Unix.ARPA via smtptcp;  19 Mar 83 3:10 EST
Received: From Brl.ARPA via smtptcp;  19 Mar 83 10:33 EST
Received: From Brl-Bmd.ARPA via smtptcp;  19 Mar 83 10:42 EST
Received: From Brl.ARPA via smtptcp;  19 Mar 83 10:48 EST

XLISP: An Experimental Object Oriented Language       Page 1


XLISP is an experimental programming language combining some
of  the  features  of LISP with an object oriented extension
capability.  It was  implemented  to  allow  experimentation
with  object oriented programming on small computers.  There
are currently implementations running on  the  PDP-11  under
RSX,  RT-11,  and  UNIX-V7,  on the VAX-11 under VAX/VMS and
Berkeley VAX/UNIX and on the Z-80 running CP/M-80 (the  CP/M
version  was  compiled  using  the AZTEC C compiler).  It is
completely written in the programming language  'C'  and  is
believed  to  be  easily  extended with user written builtin
functions and classes.  It is available in source form  free
of charge and is in the public domain.

Many traditional LISP functions are built  into  XLISP.   In
addition,   XLISP   defines  the  object  classes  'Object',
'Class', and 'Keymap' as primitives.  'Object' is  the  only
class  that  has  no superclass and hence is the root of the
class heirarchy.  'Class' is the class of which all  classes
are  instances (it is the only object that is an instance of
itself).  'Keymap' is a class whose instances  are  mappings
from input key sequences to messages.

This version of XLISP is much improved over the version that
I  submitted  to net.sources a while ago.  The code has been
cleaned up to allow  it  to  compile  without  errors  under
Berkley  UNIX  (actually  there is still one warning message
generated  having  something  to  do  with  a  zero   length
structure  member,  but  it  can be ignored).  The functions
with names that parallel LISP function names  actually  work
the  same  as  their  counterparts  in  LISP  (my source for
information on 'real' LISP was the book 'LISP',  by  Patrick
Henry  Winston  and  Berthold  Klaus Paul Horn, published by
Addison Wesley).  The keymap functions  have  gone  away  in
favor   of   a  'Keymap'  class  that  implements  the  same
functionality.  The internal representation of  objects  has
changed such that objects now take about half the space that
they took before.  I have introduced an 'Object' class  that
is  at  the  top  of  the  class heirarchy and provides some
useful default messages like 'isnew' so that you don't  have
to  provide  an  'isnew' message for a class whose instances
don't need initialization.

I hope to resubmit XLISP to net.sources sometime in the next
few weeks.  If anyone is interested in a version of XLISP to
run on Z-80s under CP/M-80, contact  me  directly  as  there
were  some  changes  to  the  sources necessary to get it to
compile under the AZTEC C compiler (by the way, I  have  had
very  good  luck  with  the AZTEC C compiler.  It is sold by
MANX software systems in Shrewsbury, NJ)

XLISP is available from:

    David Betz
    114 Davenport Ave.
    Manchester, NH  03103

XLISP: An Experimental Object Oriented Language       Page 2



    home:       [phone]
    work:       [phone]
    usenet:     decvax!betz

XLISP: An Experimental Object Oriented Language       Page 3


Classes and Messages:

    Object
        isnew           default initialization message
        print           default print message
        show            default show message
        class           return the class of an object
        sendsuper       send an object's superclass a message

    Class
        new             create a new instance
        isnew           initialize a new class
        ivars           define the instance variables
        cvars           define the class variables
        answer          define a method for a message

    Keymap
        isnew           initialize a new keymap instance
        key             define a key mapping
        process         process input using the keymap


The LISP functions included with XLISP are:

    List functions:
        car     cdr     cons    cond    atom    eq
        list    append  null    listp   equal   read
        reverse length  nth     print   princ   set
        setq    eval    quote   defun

    I/O functions:
        fopen   fclose  getc    putc    fgets   fputs

    String functions:
        strcat  strlen  substr  ascii   chr     atoi
        itoa

    Arithmetic functions:
        +       -       *       /       %       &
        |       ~       min     max     abs

    Boolean functions:
        &&      ||      !

    Relational functions:
        <       <=      ==      !=      >=      >

    Control functions:
        if      while   foreach exit

    Utility functions:
        load    mem     gc      alloc   expand










Received: From Brl-Bmd.ARPA by AMSAA via smtp;  5 Jan 84 12:35 EST
Date:     Thu, 5 Jan 84 12:31:19 EST
From:     BRINT <abc@brl-bmd>
To:       towson@amsaa
Subject:  [betz:  Re: XLISP]

Dave,

    What is SIG/M?  Can we easily get software from them?

Brint

----- Forwarded message # 1:

Received: From Ucb-Vax.ARPA by BRL-BMD via smtp;  5 Jan 84 11:59 EST
Received: by UCB-VAX.ARPA (4.22/4.18)
    id AA01905; Thu, 5 Jan 84 08:59:28 pst
Received: by decvax.UUCP (4.12/4.13)
    id AA16492; Thu, 5 Jan 84 10:33:22 est
Date: Thu, 5 Jan 84 10:33:22 est
From: decvax!betz@Berkeley (David Betz)
Message-Id: <[e-mail]>
To: decvax!betz@Berkeley, [e-mail]
Subject: Re:  XLISP

You can now order XLISP from SIG/M.  I'm not sure what the volume number is
for it.  You can also get it from DECUS.  It comes in CP/M format from SIG/M
and RT-11 format from DECUS.  I have recompiled the same source code for
VMS, UNIX V7 and Berkeley UNIX as well as CP/M-80.  You also might be interested
to know that I have a new LISP interpreter called OBLISP.  It fixes some of the
problems that XLISP had as well as being somewhat more compatible with 'real'
LISP.  It still supports object oriented programming.  It also has a builtin
function called 'prove' that is a simple prolog style theorm prover.  Actually
it is just a C implementation of a program called PIL that was distributed
over the NET a while ago.  I will be submitting this new version of LISP to
Dr. Dobbs Journal soon.  I will also be sending it to SIG/M.  I am sorry to
say that I am no longer accepting floppy disks sent directly to me.  I had
too much trouble with people sending the wrong kind of floppies or not enough
return postage, etc.  I was thinking of making the software available for a
small fee (like $25) with the understanding that once you ordered a copy, you
could make as many copies as you wanted and give them to your friends.  The
software really is in the public domain.  I just don't know of a good way of
distributing it.

    David Betz

P.S.  What are you planning on doing with XLISP/OBLISP?

----- End of forwarded messages

Received: From Brl-Bmd.ARPA by AMSAA via smtp;  27 Dec 83 19:59 EST
Date:     Tue, 27 Dec 83 19:49:36 EST
From:     BRINT <abc@brl-bmd>
To:       steve@brl-bmd, broome@brl-bmd, howard@brl-bmd
cc:       towson@amsaa
Subject:  XLISP

Do any of you know anything about XLISP (se following)?  Is
this public domain?  Is it anything like Pure Lisp, Franx, or
MAC?


I suppose the floppy is to be an 8" variety.

Brint

?

Date: 28 Apr 83 10:52:46-PDT (Thu)
To: [e-mail]
From: David Betz <decvax!betz (David Betz)@ucb-vax.arpa>
Subject: New distribution policy for XLISP
Article-I.D.: decvax.524
Received: from Usenet.uucp by SRI-Unix.uucp with rs232; 29 Apr 83 1:34-PDT

I have received a large number of requests from people who have not received
parts of the last XLISP distribution.  For a while I was honoring requests
to send individuals the files that they were missing.  Then, when that became
unreasonable due to the number of requests, I reposted several of the
original files.  Even then I got requests from people who hadn't gotten either
the original version or the redistributed version.  Because of all of this I
have decided that net.sources isn't a reliable way of distributing a program
as large as XLISP.  Rather than replying to each of the people who sent me
mail, I am sending this news article to explain my next plan for distributing
XLISP.  Would anyone who wants a copy of XLISP please send me a stamped,
self addressed SSSD floppy at the following address:

    David Betz
    Digital Equipment Corporation
    110 Spit Brook Rd.
    Nashua, NH  03062

Please specify whether you want the disk in CP/M format, RT-11 format,
VMS format, or UNIX (tar) format.

I'm sorry about this being a less than convienient form of distribution,
but I don't think that its fair to the rest of the users of the network
to continue sending the large XLISP distribution files over and over
again just so that the few people who didn't receive them correctly the
first time can have another chance.

David Betz
decvax!betz


Received: From Brl-Vgr.ARPA by AMSAA via smtp;  3 Feb 84 14:12 EST
Received: From brl-gateway2.ARPA by BRL-VGR via smtp;  3 Feb 84 14:08 EST
Received: From Sumex-Aim.ARPA by BRL via smtp;  3 Feb 84 14:03 EST
Received: from ISL by SUMEX-AIM with Pup; Fri 3 Feb 84 11:03:05-PST
Date: Friday,  3 Feb 1984 11:02-PST
To: info-micro@brl
Subject: xlisp
Reply-to: kevinw@su-dsn
From: kevinw@su-dsn
Sender: [e-mail]

has anyone had any success with xlisp from simtel-20?  i downloaded
it and the checksums verified but i can't get it to run under unix
after recompiling and the canned version has bombed two different
machines running cpm (z80 and 8085).  it sounds like a great program
but if it doesn't work...

thanks for any assistance,
  -- Kevin
     kevinw@su-dsn
 9-Jul-84 13:59:25-MDT,668;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 9 Jul 84 13:59:20-MDT
Date:     Mon, 9 Jul 84 15:25:11 EDT
From:     David Towson (CSD) <[e-mail]>
To:       Paul L. Kelley <[e-mail]>
cc:       [e-mail]
Subject:  Re:  movcpm synchronization errors

Paul - Thanks for posting the nice disassembly of the serial number checker
portion of MOVCPM.  That should help those who get into some of the more
unusual hacks, such as David Kirschbaum did.  My Omikron CP/M for the TRS-80
was legally bought and paid for, but came without MOVCPM.  I don't know why.


Dave
[e-mail]

 9-Jul-84 15:06:53-MDT,687;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 9 Jul 84 15:06:47-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  9 Jul 84 16:33 EDT
Received: From darcom-hq.arpa.ARPA by BRL-AOS via smtp;  9 Jul 84 16:23 EDT
Date:     Mon, 9 Jul 84 16:24:54 EDT
From:     [e-mail]
To:       [e-mail]
Subject:  KAYPRO Terminal Emulators??

Has anyone run into a public domain emulator for the VT-100 terminal
that runs on the Kaypro II or 4? In a pinch, I could go for a commercial
version if the price is not outrageous.

Please respond to me to keep from over-burdening this list.

thanks,
rick
 9-Jul-84 20:16:33-MDT,756;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 9 Jul 84 20:16:25-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  9 Jul 84 21:54 EDT
Received: From xerox.arpa.ARPA by BRL-AOS via smtp;  9 Jul 84 21:50 EDT
Received: from CheninBlanc.ms by ArpaGateway.ms ; 09 JUL 84 18:46:40 PDT
Date: Mon, 9 Jul 84 18:46 PDT
From: [e-mail]
Subject: Re: Xerox 820-I clearinghouse/mailing list/bulletin board
 system
In-reply-to:
 "hplabs!sdcrdcf!sdcsvax!akgua!psuvax1!burdvax![e-mail]'s
 message of 6 Jul 84 7:23:16 PDT (Fri)"
To: hplabs!sdcrdcf!sdcsvax!akgua!psuvax1!burdvax![e-mail]
cc: [e-mail]

Here's one vote for your 820 mailing list.

Larry Shilkoff

10-Jul-84 05:53:26-MDT,5275;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 10 Jul 84 05:53:12-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  10 Jul 84 6:59 EDT
Date: 10 Jul 1984  05:00 MDT (Tue)
Message-ID: <KPETERSEN.12030170577.BABYL@SIMTEL20>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: Cold boot initialization for Kaypro-10

Relayed from RCPM Royal Oak:
-----
J. Steele
7-6-84

COLD BOOT INITIALIZATION K10 CPM 2.2 F

Purpose: KAYPRO, in it's corporate wisdom decided to go for the most common
         IO configuration which is 300 baud on the serial ports and using
         the parallel printer.  Those who don't do this, and especially
         those who use a variety of customized CP/M's have to use CONFIG
         or a special boot-up routine to overcome the Kaypro scheme. The
         following technique avoids this problem once and for all plus
         you learn a few added things about the "inner" secrets of the
         Kaypro BIOS. (It might be easier on Kaypro to release the BIOS
         and let the hackers have at it. No telling what good things might
         be done.)

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

On the COLD BOOT the IO byte and the baud ports are initialized from high
memory locations which means we can get to them for our own needs.

    o The initial IO byte is loaded from EA33h
    o The initial Printer Baud is loaded from EA48h
    o  "    "     Modem    "    "   "     "   EA47h

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

These locations are on either side of the cursor-keypad table which makes
them very easy to find and change with EDFILE to eliminate continual
use of the (barf) CONFIG program.


 +-> This is the IO byte                                    +----> Modem Bd
 |    +>cursor <+  +--> keypad table here <---------------+ |  +-> Printer Bd
 |    | keys    |  |                                      | |  |
81 00 0B 0A 08 0C 30 31 32 33 34 35 36 37 38 39 2D 2C 0D 2E 05 05
      ^  v  <- ->| 0  1  2  3  4  5  6  7  8  9  -  , EN  .|
      up dn lf rt|   keypad face values for above bytes    |
--------------------------------------------------------------------------
Changing the values with the EDFILE disk editor (any will do that can find
a string in the file)

>EDFILE PUTSYS.COM   (whatever putsys you are using)

S \123456\           (search for the string "123456"

This will put you in the sector and you can edit the appropriate bytes
as you desire. Consult the KAYPRO manual for baud rates and any good
CPM text for a discussion of the IO byte.
--------------------------------------------------------------------------

The IO byte is comes stock set to 81h which enables the Parallel Printer
and can be set for the serial printer by changing it to 01h. Don't make
any other changes as the PUNCH and READER don't care and if you set the
CONSOLE to 0 it will bring the system up looking to the PRINTER port
for keyboard-screen. Nice, though if you use the K10 with a "real"
terminal.

Both the MODEM and PRINTER baud come in set at 300 baud which is  05h.
I set the printer to 07h as I use a 1200 baud serial printer. (an OKI
that has a parallel port but is two feet too far from the box and I
can make a long RS232 cable a heck of a lot cheaper than a Centronics)

Note that at the same time, you can alter the initial values of the cursor
keys and the keypad. The keypad keys can be changed directly to a single
byte value or by changing the desired key to 00h you may then make up to
a 4 byte value in the table which follows this stuff. Best to do what you
want with config first, use DDT to look at the area and then make the final
edit with EDFILE or another disk file editor. (I am assuming this isn't
compu-garbage talk to you, but if it is, then you need the experience of
learning a bit more before you hack up the main software of the machine)

When you have made your changes, just run the PUTSYS (or whatever) and
reboot from a RESET. If the computer chokes, try again. I suggest you
work on RENamed copies of PUTSYS.COM to avoid junking your on disk
backup. These bytes only affect the COLD boot from power-up or reset so
any later finagling you do with Config, Stat, or Whatzit.com will be on
your head.

The only r-e-a-l bad thing you can do playing around with the BIOS
would be to accidentally call on the ROM monitor to junk up a disk
area. This doesn't even go close. (Ask me about the time a WS went
bonkers and dumped a file on the directory tracks - Real soon after,
KAYPRO gave me a brand new main board, HD controller and a new Hdisk
that worked right. That was before the bean counters started adding up
the cost of in-the-field fixes on THEIR engineering errors. They've
stopped being so nice now, but Lord help you with the first versions of
the Western Digital board. The big expensive chips roast out and KAYPRO
only stocks assemblies, not replacement chips. $210 in exchange cost to
the dealer. Ask me how I know!!)

THAT'S ALL FOLKS !!!!!

PS: Works just fine with ZCPR2 for the K-10. Enjoy!
10-Jul-84 18:46:23-MDT,1079;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 10 Jul 84 18:46:16-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  10 Jul 84 20:23 EDT
Date: 10 Jul 1984  18:23 MDT (Tue)
Message-ID: <KPETERSEN.12030316793.BABYL@SIMTEL20>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   David Towson (CSD) <[e-mail]>
Cc:   [e-mail]
Subject: [towson: Cold boot initialization for Kaypro-10]

   Date: Tuesday, 10 July 1984  06:44-MDT
   From: David Towson (CSD) <towson at Amsaa.ARPA>
   To:   Keith Petersen <W8SDZ at Simtel20.ARPA>
   Re:   Cold boot initialization for Kaypro-10

   Keith - This message has some really good stuff for those with an
   interest (which doesn't, at this moment, include me).  Have you any
   plans for stashing this goodie in the archives?  I know it will be in
   the info-cpm message archive, but one would have to know it was there
   to go looking for it.

Yes, I put it in MICRO:<CPM.KAYPRO>KP-CBOOT.DOC on SIMTEL20.
--Keith
10-Jul-84 23:06:20-MDT,847;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 10 Jul 84 23:06:14-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  11 Jul 84 0:40 EDT
Received: From xerox.arpa.ARPA by BRL-AOS via smtp;  11 Jul 84 0:34 EDT
Received: from Muscat.ms by ArpaGateway.ms ; 10 JUL 84 05:36:11 PDT
Date: 10 Jul 84 08:34:32 EDT (Tuesday)
Subject: Re: Xerox 820-I clearinghouse/mailing list/bulletin board
 system
In-reply-to: hplabs!sdcrdcf!sdcsvax!akgua!psuvax1!burdvax!droms' message
 of 6 Jul 84 7:23:16 PDT (Fri)
To: hplabs!sdcrdcf!sdcsvax!akgua!psuvax1!burdvax![e-mail]
cc: [e-mail]
From: Jeff <[e-mail]>

I beleive that there is probably a fairly large community of people
within Xerox that would be interested in participating.  I'd like to see
it setup.

Jeff
11-Jul-84 03:30:30-MDT,1258;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 11 Jul 84 03:30:21-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  11 Jul 84 5:09 EDT
Received: From xerox.arpa.ARPA by BRL-AOS via smtp;  11 Jul 84 5:08 EDT
Received: from GreeneKing.ms by ArpaGateway.ms ; 11 JUL 84 02:06:24 PDT
Date: 11 Jul 84 10:01:10+0100 (Wednesday)
From: [e-mail]
Subject: CBBS for CP/M
To: [e-mail], Jim Forrest <[e-mail]>
cc: [e-mail], [e-mail]

Russ & Jim,

The full address is

    Randy Suess
    5219 West Warwick
    Chicago
    Illinios
    60641

You can obtain this software (2 or 3  S/S S/D 8" disks) from any SYSOP
using CBBS, but payment should still be made to Randy ($50).

You can of course dial into this first CBBS at [phone]

For those of you who are not aware, CBBS is written in 8080 code, is
assembled with the Public domain LINKASM (~25K), has significant help
files, supports messages and binary transfer and contains flags for a
variety of applications. My version even supports private messages. CBBS
was originally written by Ward C & Randy.


//Ken

----------------------------------------------------------------
11-Jul-84 06:46:57-MDT,919;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 11 Jul 84 06:46:50-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  11 Jul 84 8:16 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  11 Jul 84 8:08 EDT
Date: 11 Jul 1984  06:08 MDT (Wed)
Message-ID: <RCONN.12030445034.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Cc:   [e-mail]
Subject: ZCPR3 and SYSLIB3 on SIMTEL20


    Thanks to the efforts of Frank Wancho at White Sands, all ten
ZCPR3 disks and four SYSLIB3 disks are now on SIMTEL20.  All files
have been verified.  They are located in MICRO:<CPM.ZCPR3> and
MICRO:<CPM.SYSLIB3>, and they are stored in ITS binary format.  The
anonymous login convention can be used to access these files.

    Thanks again, Frank, for the effort you expended in putting
the files on the system.

        Rick
11-Jul-84 07:38:18-MDT,4700;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 11 Jul 84 07:38:04-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  11 Jul 84 9:09 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  11 Jul 84 9:01 EDT
Date: 11 Jul 1984  07:00 MDT (Wed)
Message-ID: <RCONN.12030454605.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Subject: ZCPR3 Phase 1 complete


    All recipients of ZCPR3 Phase 1 are now distributing the
software.  SIG/M remote distribution sites (sites away from the main
SIG/M organization in NJ) could still be waiting for receipt of the
disks from SIG/M HQ, but that is the only further delay I can see now.
For those of you who want to acquire ZCPR3, your alternatives are
many:

    1. you can order disks thru SIG/M
    2. you can transfer files from your local BBS if it has
        them (I've been told that several large BBSs in
        CA have it online now [perhaps sans all the
        source files])
    3. you can transfer files from SIMTEL20 if you are on the
        DDN
    4. the San Diego Computer Society has a full set
    5. the disks are available within XEROX and will soon
        be available within DEC
    6. Echelon is distributing the disks in a variety of
        formats (8", Kaypro, Osborne) [all formats are
        uninstalled at this time] and Echelon includes
        hardcopy of the installation manual and user's
        perspective
    7. ZCPR3 is included in sales of the Ampro Little Board
        and Ampro Bookshelf computers

    In a discussion with Frank Gaude of Echelon last night, Frank
mentioned that over 700 disks have gone out so far in various
combinations (basic ZCPR3 core, SYSLIB3, full set of 14 disks, etc).
I have been getting reports back from the field thru Echelon, and
people seem to be happy, bringing the system up, and no bugs have been
reported yet.

---- What's Next? ----

    1.  ZCPR3 Phase 2 is moving along quite smoothly.  DU3,
VFILER, and VMENU are now done, and they all run very efficiently in
the ZCPR3 environment.  I will be completing documentation on VMENU
tonight and probably putting the final touches on MU3 as well.  Once
MU3 is done, it will be the last of the major Phase 2 utilities.  All
Phase 2 utilities will then go out for beta testing.  I plan to review
the system overall, fill in what minor functions I feel are necessary
which I may have missed, complete the documentation on Z3LIB (VLIB is
already done), get the beta test results and correct bugs reported,
and then release [DO NOT ask me when -- I'll let you know].
    2. With the utilities done [or at least very nearly so], I can
complete the ZCPR3 book and then the SYSLIB3/Z3LIB/VLIB book.  I hope
to send drafts out to various editors in a few days.  My contract with
the publisher [NY Zoetrope] calls for delivery of the first full draft
by 1 Aug, and I think that not only will this deadline be met, but the
draft they will see will be very close to the final draft.  Once they
start going, they claim the book will be out within a month!  This we
will have to see.
    3. Echelon has been addressing the problem of ZCPR3
installation for some time now, and they now have working, unrefined
prototypes of an automatically-installing ZCPR3 system.  The concept
is simple: too many people do not have source to their BIOS [political
commentary -- boo, hiss, on the manufacturers] and even if they did,
many would find the effort to bring up ZCPR3 to be extreme.  For these
reasons, Echelon is working on a version of ZCPR3 that installs itself
with a simple command that can be issued at cold boot.  I feel that
the best possible ZCPR3 installation is done with BIOS modification,
but this should be the next best thing to it.  I don't know for sure
if the project will succeed in terms of a generic CP/M [Echelon may
have to provide specific versions for the Kaypro, Osborne, etc], but
it does look hopeful at this time.  Of course, Echelon does intend to
sell this, but the cost should be minor.  I'll let you know when this
project is complete [which should be Real Soon Now (where have I heard
THAT before???)].
    4. More and more interest is developing in ZCPR3 [political
commentary -- no, most of the 1.5M CP/M 2.2 users are NOT out on a
limb now -- new things are coming out for them], and I've been
interviewed for three articles by various people so far.  Also, if you
want to hear some words about the Ampro and ZCPR3 from someone other
than me, the latest issue of User's Guide contains a review of the
Ampro which includes some coverage of ZCPR3.  Several articles (and
the book) should be coming out in the months to come.

        Rick
11-Jul-84 10:10:36-MDT,749;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 11 Jul 84 10:10:31-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  11 Jul 84 11:45 EDT
Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp;  11 Jul 84 11:42 EDT
Date: Wed, 11 Jul 84  9:08:29 EDT
From: Manny Crivello <[e-mail]>
Subject: ALS GSX-80 GRAPHICS + CPM-PLUS UPGRADE FOR APPLE
To: [e-mail]

 ALS has finlly came out with GSX-80 graphic package for there CPM-PLUS
, plus they upgraded there CPM-PLUS to 3.01B2. I also heard that they
also upgraded there toolkit. I recived my GSX-80 + CPM-PLUS UPGRADE kit
yeserday, so I haven't played with to much yet,but, it does seem to much
nicer.
M.D.Crivello


12-Jul-84 05:19:16-MDT,3363;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 12 Jul 84 05:19:06-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  12 Jul 84 6:48 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  12 Jul 84 6:38 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 12 Jul 84 3:34-PDT
Date: 9 Jul 84 7:05:51-PDT (Mon)
To: [e-mail]
From: ihnp4!ihuxq![e-mail]
Subject: Irv Hoff's side of the MDM7xx story
Article-I.D.: ihuxq.1053

<>
A while ago I posted a query on how Irv Hoff could sell the mdm740 program
after it has been in the public domain for so long. Most people seem to
agree that legally Irv can sell it as he has made his own original
alterations to it. After this message was posted I conacted Ward Christensen
(the original author of the mdm7xx programs) and asked for his opinion.
The following message is Ward Christensen's ideas (and do not reflect mine):
__________________________
Msg 23035 is 20 line(s) on 07/03/84 from WARD CHRISTENSEN
to RICHARD COVERT re: IRV HOFF/COPYRIGHT/MDM7XX

Irv has no intention of selling MDM7xx. This whole thing is blown
out of proportion. Like so many rumors ABOUT someone - no one thought
to go back to the "source" (Irv himself). I have now had "many K-char"
of dialog w/Irv on CompuServe, and all pleasnat and understanding.
Like me copyrighting CBBS and Resource (the latter more relevant
because its "in the public domain" - (an admitted inconsistency)) Irv
worked VERY HARD to make MDM7xxx available for a WIDE variety of
machines. Inevitably, with his VAST erperience customizing MODEM
(much more than mine) he got frustrated like I did with people who
tack on inconsistent or worse yet, "buggy" bells and whistles,
that aren't in the general interest with his ideas. Thus,
just as I don't distribute the source for RESOURCE, he stopped
distributing MDMxxx source - so he'd not have to fight the "someone
else puts something in, he takes it back out" battle. This would allow
him to concentrate on getting new overlay files out for more modems,
more systems, and stop "fighting brush fires" of people "hacking"
the code. I see nothing wrong with what he has done; he plans to
eventually re-release source; PS: He thinks MEX came to be as another way
to release, could be (I have nothing bas and have heard
much good about MEX, too).
___________________________________

My own feelings about not releasing source to a program being distributing
to the hobbyist market is that if the author doesn't provide the source
then he OWNS it to the community to provide support for his program.
For example, I wrote a 8080-z80 translator for which I distributed only
the object file (copyrighted by myself) for use by CP/Mers. I promptly
fixed any bugs in my program and released it. It has worked fine for me
as I am up to release 4.1 now. It does appear that Irv has provided
support for mdm7xx in the form of bug fixes. What he has not done is
to implement changes as suggested by others.. I feel that it is hard
to corrdinate such a program amongst many different programmers.
Oh well, I hope that this helps clear up any misunderstandings about
Irv's intentions with MDM7xx..

--
            Richard Covert
            AT&T Bell Laboratories
            ...ihnp4!ihuxq!covert
            [phone]

12-Jul-84 08:17:02-MDT,1127;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 12 Jul 84 08:16:57-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  12 Jul 84 9:42 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  12 Jul 84 9:41 EDT
Date: 12 Jul 1984  07:41 MDT (Thu)
Message-ID: <RCONN.12030724121.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Cc:   [e-mail], [e-mail]
Subject: ITS-to-Normal and Normal-to-ITS File Conversion

Rick,

    In response to your message, I created a pair of tools to use
under UNIX (the design is so simple that I believe they will port to
virtually any UNIX - they all have putchar and getchar, right?).  The
tools are in MICRO:<UNIX.CPM> and they are:

itstonorm.c    convert ITS format files to normal format
normtoits.c    convert normal format files to ITS

itstonorm.man    doc (rename to itstonorm.1 under UNIX)
normtoits.man    doc (rename to normtoits.1 under UNIX)

    I tested them on an ITS binary file from the MICRO:<CPM.ZCPR3>
archive, and they ran nicely.

    Enjoy!

        Rick
12-Jul-84 08:17:26-MDT,3100;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 12 Jul 84 08:17:17-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  12 Jul 84 9:41 EDT
Date: 12 Jul 1984  07:41 MDT (Thu)
Message-ID: <KPETERSEN.12030724221.BABYL@SIMTEL20>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: MEX review - MEX-RVW.TXT

Relayed from RCPM Royal Oak...

 THIS FILE IS A BRIEF REVIEW OF MEX10, AND CONTAINS A FEW HINTS DERIVED
FROM TRIAL AND ERROR EXPERIMENTATION......

MEX10 is yet another modem program....and for those using MDM7, there arises
the question "What does MEX offer that MDM7 doesn't already have, or that you
don't need anyway?"  There is a great deal of truth there, but as a dedicated
MDM7 user, I offer the following comments after just a few days of using MEX.
First, I'm already convinced that MEX is the most powerful modem program I've
come across.  MDM7 is excellent, but doesn't begin to offer the power and
flexibility that MEX offers.  Probably the most exciting area is the dynamic
ability to change program paramaters  very easily in real time, and command
line processing with simple command files. As an example (very simple), the
following one line file (much like a submit file) will with a single command
entry (get FILE.QQQ), do the following:

MEX] A0>>GET FILE.QQQ            ;entered command
MEX] A0>>SENDOUT XMODEM S FILE.QQQ    ;MEX sends out request
(WAITS FOR REPLY)            ;remote system responds (XMODEM...etc)
MEX] A0>>R FILE.QQQ            ;MEX sets up receive
(TRANSFERS FILE)
B0>                    ;back to remote system!!!

Here is the one line file that does all this  (GET.MEX):

SENDOUT "XMODEM S {1}";R {1}

Those who have used submit files will appreciate the parameters {n}.

A file for transfering library member files is just slightly more complicated.

MEX] A0>>GETL NAME.LBR NAME.MBR        ;Single command (the name GETL is
                    ;arbitrary..and is filename that
                    ;contains the following text)
SENDOUT "XMODEM L {1} {2}";*R {2}    ;MEX command file

These command files can be used for many purposes, and can change operating
parameters for particular systems called (even such things as parity, stop
bits, etc for particular systems).

All this flexibility is not without its price, however!  As is always the
case, increased power and flexibility also leads to increased complexity.
Thats a polite way of saying that MEX is not for the beginner.  The array of
commands and variables under the control of the operator in real time is
more than a little overwhelming at first.  Also, there are many people who
will never need all the power and flexibility offered, and will find the
much simpler to use MDM7 satisfies all their needs.  MEX  is of most value
to those who need its greatly increased power for non-typical uses
(main-frame com., etc) or those who will enjoy  the use of a "sports car"
and the programming challenge it offers.

Just one man's opinion.....

                            Norman Beeler
                            Sunnyvale, Ca
12-Jul-84 08:41:43-MDT,8261;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 12 Jul 84 08:41:21-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  12 Jul 84 9:43 EDT
Date: 12 Jul 1984  07:44 MDT (Thu)
Message-ID: <KPETERSEN.12030724601.BABYL@SIMTEL20>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: MEX files - MEXFILES.INF

Relayed from RCPM Royal Oak...

SOME NOTES ON MEX FILES
by Irv Block

   Richard Holmes has suggested that a listing of my MEX files
with an explanation of how they work might be useful to others
picking their way through Ron Fowler's marvelously programmable
communications package, MEX.  So here goes...

   What is so extraordinary about MEX is its ability to edit
and tailor itself to the user's particular needs.  One of the
features that demonstrate this capacity is the way MEX uses
***.mex files.  MEX will read any FILENAME.MEX as a "SUBMIT"
file and execute the lines as commands; and it can do this
either at your manual direction or automatically.

   You can tell MEX to read a FILENAME.MEX file by typing on
the MEX command prompt A0>>READ FILENAME  (you can eliminate
the .ext, since the program assumes the .ext to be .MEX)

   Or, even better, you can eliminate the "READ" instruction
and have MEX assume that any name it doesn't recognize as a
built-in command is the name of a .MEX file and should be read
and performed.  Thus, simply typing A0>>FILENAME <cr, of
course> will dispatch MEX on its obedient course.    This makes
for very fast and fluid performance of a lot of tasks to make
communications easier and quicker.

   The way you program MEX to do its "automatic read" number is
with a STAT command:

    A0>>STAT EXTEND ON
    A0>>CLONE NEWMEX.COM (or any other name, even
                                     the same)

   The clone is now ready to do your bidding, and the following
description of my .MEX files (probably crude to some of you)
will give some idea of what this program can do.   They can all
be extended and improved.

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

INI.MEX

   INI.MEX is the .MEX file MEX automatically looks for on
starting up, whether you tell it to or not. You can disable
this feature with "STAT INITFILE OFF" but you'd be making a
mistake. Use it.   My INI.MEX, written with a text editor (I
keep the economical TED.COM on the same disk to facilitate
instant writing and editing of .MEX files) goes like this:

    LOAD KEYS.KEY
    LOAD PHONE.PHN
    B:^M
    TYPE A:T.NOT

        [NOTE: YOU CAN ALSO WRITE THESE
               COMMANDS ON A SINGLE LINE, SEPARATED BY
                SEMICOLONS.  BUT GIVING EACH COMMAND
                ITS OWN LINE, I THINK, MAKES IT EASIER
                   EDIT THE FILE LATER]

   On automatically reading this file, then, MEX will perform
the following tasks before getting itself ready to receive your
further commands:

    1) It will load KEYS.KEY, the file that contains my
        keystrings (First Name, Last Name, Passwords, Logoff,
        etc.)  These keystrings, of course, can be written into
        the file either with a text editor or with MEX itself.
        Type HELP KEY for full instructions.  By using MEX's
        "SAVE KEYS.KEY" command you can write your keystrings
        and updates to a file.   You can "CLONE" the
        keystrings, too, but that occupies space in MEX and
        makes it necessary for you to redo the process each
        time you make a new clone.   By having your strings in
        a KEYS.KEY file and having MEX automatically load it,
        you can maintain and edit your set of keystrings
        independently.

    2) Mex will then load your PHONE.PHN, your library of
        phone numbers that you 'SAVE'ed. (SEE HELP PHONE).  All
        the points made above with reference to keystrings
        apply equally to this file.

    3) On reading the third line, MEX will log you onto
        Drive B, where I assume your uploading disk will be.
        My A drive, containing the disk with MEX and assorted
        associated goodies for editing and managing uploaded
        and download material, is pretty full. Forgetting where
        I'm logged and trying to upload a long file on Drive A
        by error can be a disgusting experience.

    4) Finally, reading the last line, MEX will type out my
        file T.NOT.   That file reads like this:

           *****************************************
    IRV, REMEMBER TO SET UP A 'CAPTURE' FILE!
        *****************************************

    And that is what pops up on my screen (all in the space
        of a second or two -- MEX is fast) after bringing up
        MEX.  For me, it's a good reminder.  I have a habit of
        remembering to set up a capture file only after what I
        want to copy has already scrolled by on its way north.

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

GET.MEX

   GET.MEX reads like this:

    WRT
    SENDOUT "XMODEM S {1}
    RT {1}

   If I type "GET ANYFILE" <cr> on the MEX command line, MEX
will first WRT the capture file, if there is one, to the disk.
(If you don't WRT the capture file before R or S, you'll lose
it) It will then send "XMODEM S ANYFILE" to the host, wait for
a reply and then go into MEX's command mode to give the order
"RT ANYFILE"  When the transfer it completed I'll be left in
the Terminal mode, which in this case is where I want to be.

       ALL THIS UNATTENDED, WHILE YOU FILE YOUR NAILS
       OR GO FOR COFFEE.   MAIN ADVANTAGE IS ACCURACY, THOUGH,
       AND SPEED IN TRANSFERING.

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

GETBYE.MEX

   My GETBYE.MEX goes like this:

    WRT
    SENDOUT "XMODEM S {1}
    R {1}
    SENDOUT "BYE ^M"

   Invoked by "GETBYE ANYFILE.TYP" this will do the same as GET.MEX
but go to the command mode after the transfer in order to send
the "BYE" command (you can't send sendout commands in anything
but the command mode--it took me some frustrating hours to
realize this).   In other words, it automatically logs off.

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

GETLIB.MEX

   This one reads as follows:

    WRT
    SENDOUT "XMODEM L {1} {2}
    RT {2}


   Invoked by GETLIB ANYFILE THISFILE.DOC, it will download the
member THISFILE.DOC from ANYFILE.LBR.

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

SEND.MEX

   SEND.MEX is just like GET.MEX except that the R's and S's
are transposed, since the purpose of "SEND ANYFILE.TYP" is to
send a file to the host rather than receive one.

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

Q.MEX is invoked simply by typing "Q" <cr> at the command line.
It reads like this:

    STAT REPLY 0
    SENDOUT "ATM0^M"
    STAT REPLY 8

   The critical instruction is the second line, which instructs
the Smartmodem to shut down its speaker.  Nice when lines are
busy and you are going into continuous redialing.  The first
and third lines of this file shut off the echoing and waiting
in this process, making it virtually instantaneous and neat --
but restore the normal parameters at completion of the order.

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

Z.MEX is just like Q.MEX except that the second line reads

    SENDOUT "ATZ^M"

restoring the Smartmodem to its normal chatty mode.

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

ADDENDUM:

Two other STAT adjustments will make all the above operate more
smoothly.  CLONE these into your version of MEX -- or include
them in your INI.MEX file.

    STAT SEARCH 2
    ALT A0

The first of these, STAT SEARCH 2, sets up a search path that
orders MEX to look first on the default drive for .MEX files
you indicate and then, failing to find them there, to search
the "Alternate" drive.

The second command sets the alternate drive to be A0, which is
right for me, since I am usually logged on B.  Depending on
your system, ALT could be anything.  The combination thus
searches both drives, relieving you of the bother of
remembering which file is on which drive--a kind of internal
ZCPR.

I do hope this exercise will turn out to be useful, perhaps
instigate an exchange of more imaginative .MEX files.  Mex is
dynamically programmable and there may be as many different
ways of programming it as there are users.

                    - Irv Block
                      Sea Cliff, NY
                      June 7, 1984
12-Jul-84 18:00:49-MDT,1276;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 12 Jul 84 18:00:40-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  12 Jul 84 19:38 EDT
Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp;  12 Jul 84 19:30 EDT
Received: by UCB-VAX.ARPA (4.28/4.31)
    id AA16557; Thu, 12 Jul 84 16:26:52 pdt
From: ihnp4!lznv!lzpa![e-mail]
Date: 12 Jul 84 18:17:16 CDT (Thu)
Message-Id: <[e-mail]>
Received: by ihnp4.ATT.UUCP; id AA08510; 12 Jul 84 18:17:16 CDT (Thu)
Subject: Mailing list
Apparently-To: ucbvax!C70:info-cpm

Dear fa.info-cpm editor,

I am an employee of AT&T Information Systems in Lincroft N.J. and
would like to be added to the mailing list for this digest.  My
vital statistics are:

    Name:        Robert R. Barbato
    Company:    AT&T Information Systems
    USnail address:    307 Middletown-Lincroft Rd
            Lincroft, N.J.  07738
    E-mail address:    ihnp4!lznv!rbr

If I have sent this request to the wrong place could you please

    1) forward to the guilty, if possible
    2) failing that, send me some mail so I know my request
       has not been ignored.

I don't have access to Netnews, so this is my only hope to receive
the digest.  Thanks.
                    Bob Barbato

Cc: rbr



13-Jul-84 02:29:35-MDT,1013;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 13 Jul 84 02:29:29-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  13 Jul 84 3:59 EDT
Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp;  13 Jul 84 3:49 EDT
Date: 13 July 1984 03:48-EDT
From: Jerry E. Pournelle <[e-mail]>
Subject:  S1 & NCC
To: [e-mail], [e-mail]

There was a very large ad for t he "S1" Operating System in teh
Conventino Daily at NCC.  If S1 was anywhere at NCC or anyone
actually spoke about it, I did not see it.  The Ad was a two
page spread, that was cleverly designed to look as if it were a
smaller advertisement surrounded by serious review text
(interview with the promoter of S1).
    Has ANYONE seen S1 on ANY machine whatsoever?  I have
seen nothng but paper, leaving me with the impression that s1 OS
is vaporware; and here and there I get a whiff of something
else...

ANY EVIDENCE of existence of S1 would be appreciated.

13-Jul-84 07:24:44-MDT,1302;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 13 Jul 84 07:24:37-MDT
Received: From mitre.arpa.ARPA by AMSAA via smtp;  13 Jul 84 8:58 EDT
Date: 13 Jul 1984  8:41:37 EDT (Friday)
From: Jeffrey Edelheit <[e-mail]>
Subject: Re: S1 & NCC
In-Reply-to: Your message of 13 July 1984 03:48-EDT
To: Jerry E. Pournelle <[e-mail]>
Cc: [e-mail]

Jerry - I don't know if the S1 outfit you are referring to is Multi Solutions
Inc. of Lawrenceville, NJ.  If it is, I have noticed that they have advertised
in Computerworld for over 6 months, running adverts saying "UNIX is a
dinosaur, CP/M & MS-DOS are toys......" and "S1 is the only operating system
worthy of the title 'the next world standard'".  I don't know if S1 is
vaproware, but I am pretty sure that I would not want to deal with anyone who
would place such arrogant adverts.  I would have to wonder how they would
treat me as a customer.  Furthermore,  after watching the trials & tribulations
of Dick Pick, I personally have doubts about any OS that doesn't have the
support of either a large installed base (e.g., CP/M, MS-DOS) or a developer
who has some significant size behind it (e.g. AT&T and UNIX).

Jeff Edelheit
(edelheit at mitre)

14-Jul-84 03:04:25-MDT,1608;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 14 Jul 84 03:04:18-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  14 Jul 84 4:30 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  14 Jul 84 4:29 EDT
Date: 14 Jul 1984  02:27 MDT (Sat)
Message-ID: <RCONN.12031191236.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   Dick <[e-mail]>
Cc:   [e-mail]
Subject: ZCPR3's ZEX.COM
In-reply-to: Msg of 14 Jul 1984  00:36-MDT from Dick <MEAD at USC-ECLB.ARPA>

Dick,

    ZEX.COM is usable as distributed ONLY if you have the same
memory configuration I do -- particularly in terms of the location of
ZCPR3 command processor and the Environment Descriptor.  This is the
memory configuration which is on the distribution header files
(Z3BASE.LIB and Z3HDR.LIB).

    Yes, the documentation shows ZEX building a new ZEX.  If you
do not have ZEX, EX (by Ron Fowler) can be used instead.
Also, RELS.UTL is quite useful in creating ZEX, and that is in
MICRO:<CPM.SUBMIT> on SIMTEL20.

    I'll see if I can put together a LBR file for the Phase 2
distribution which contains a toolset for building ZEX without first
having ZEX.  In the meantime, if you are in a hurry, remember that ZEX
is just a command file processor, so the command sequence shown in ZEX
can be typed in manually - that is how I was thinking that users would
first bring it up, but I forgot to say that.

    I hope this clears up the matter.  The book will elaborate on
such items, of course, but that does not help for now.

    Rick
14-Jul-84 03:15:12-MDT,1353;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 14 Jul 84 03:15:06-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  14 Jul 84 4:40 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  14 Jul 84 4:32 EDT
Date: 14 Jul 1984  02:32 MDT (Sat)
Message-ID: <RCONN.12031192185.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Subject: [DKozinn: ZCPR3 distribution]

FYI -- Rick

Date: Friday, 13 July 1984  00:17-MDT
From: David Kozinn <DKozinn at HIS-PHOENIX-MULTICS.ARPA>
Reply-To: DKozinn%pco at CISL-SERVICE-MULTICS.ARPA
To:   RCONN at SIMTEL20.ARPA
cc:   CSTROM at BRL-BMD.ARPA
Re:   ZCPR3 distribution

Hi Rick.  I just thought that I'd let you know that we now have most, if
not all of the .COM files, the manuals, the .LIB files, and a large
number of the .ASM files for ZCPR3 in the CP/M Special Interest Group on
CompuServe, CP-MIG in XA 6 (database section 6) for people to download
as they please.  I thought you might like to mention this the next time
you send out one of your status reports.  In case you're not familiar,
Charlie Strom, Tom Jorgenson and I are the 3 Co-sysops of this special
interest group, and there are no fees for downloading any of our
software other than the normal CompuServe connect-time charges.

14-Jul-84 13:11:59-MDT,2271;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 14 Jul 84 13:11:51-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  14 Jul 84 14:54 EDT
Date: 14 Jul 1984  12:55 MDT (Sat)
Message-ID: <KPETERSEN.12031305654.BABYL@SIMTEL20>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: [brutlag: KERMIT ON TELENET]

This may help MODEM7 users who are accessing hosts via TELENET.
--Keith

Date: Sunday, 17 June 1984  21:53-MDT
From: Doug Brutlag <brutlag at USC-ECL.ARPA>
To:   Info-Kermit at MIT-MC, cc.fdc at COLUMBIA-20.ARPA,
Re:   KERMIT ON TELENET

Frank,

    Another way to get KERMIT to transfer files on TELENET is to
configure TELENET to transmit the eighth bit.  Most TELENET nodes are
set up for 7 bit communications only.  You can set up eight bit mode, by
connecting to your host, then escape back to TELENET (with cr @ cr) and
giving the command:

SET? 0:33,63:0

    The 0:33 parameter allows you to set certain ITI parameters
normally not used by TELENET users.  The ITI parameter 63 enables the
eighth bit when set to 0 (contrary to what is written in the TELENET
documentation by the way).  I have found this setting useful for both
KERMIT file transfers and for using a terminal with a META key for
setting the eighth bit for EMACS editing commands.  If this fails you
should call the TELENET 800 number to find out how to allow eight bit
communications for your node.  SOme nodes use old TELENET protocols
which require setting parameter 57:1 as well.  If you have many people
using KERMIT via TELENET you can have your TELENET representative change
your local node to make the default setting of parameter 63 be 0.

    By the way I do not encourage people to use KERMIT via TELENET
because of the delay in receiving the ACK/NAK.  Even with an unloaded
network and 1200 baud nodes at either end, the delay in receiving the
ACK/NAK effectively lowers the transmission speed from 1200 baud to less
than 300 baud.

Doug Brutlag

[Ed. Note - We will try to work out a "sliding window" option for the
Kermit protocol over the summer.  This should speed things up a bit,
assuming it can be widely implemented.]
14-Jul-84 19:57:00-MDT,640;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 14 Jul 84 19:56:56-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  14 Jul 84 21:30 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  14 Jul 84 21:28 EDT
Date: Sat 14 Jul 84 19:28:24-MDT
From: Jim Forrest <[e-mail]>
Subject: Can anyone help - info on LD80 ?
To: [e-mail]
cc: [e-mail]

I have a program just above the limit of my memory for L80 and
someone told me there is an LD80 that does a disk link. Can anyone tell
me where it can be obtained, if it exists?
Jim
-------
14-Jul-84 23:51:26-MDT,1173;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 14 Jul 84 23:51:20-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  15 Jul 84 1:30 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  15 Jul 84 1:29 EDT
Date: 14 Jul 1984  23:29 MDT (Sat)
Message-ID: <RCONN.12031421041.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Subject: Assembling ZEX

    Dick Mead brought up the problem of using ZEX to assemble ZEX
the other day.  If your memory configuration is not the same as mine,
the ZEX.COM distributed with ZCPR3 will not work.

    If this is the case, you have two options:  to manually enter
all of the command lines indicated in the installation manual or to
use EX to execute the ZEX.ZEX command file.  I just tried it, and EX
runs perfectly with it.  You have to rename ZEX.ZEX to ZEX.SUB to get
EX to use it, and it runs with the simple command:

        EX ZEX

Of course, you still need RELS.UTL to put everything together with SID
or ZSID.  Both EX.COM (and EX.HEX) and RELS.UTL (and RELS.HEX) are
available to the public in MICRO:<CPM.SUBMIT>.

        Rick
15-Jul-84 00:52:52-MDT,1397;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 00:52:47-MDT
Received: From ucb-vax.arpa.ARPA by AMSAA via smtp;  15 Jul 84 2:23 EDT
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.31)
    id AA26152; Sat, 14 Jul 84 23:24:50 pdt
Received:  from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
    by ucbjade.CC.Berkeley.ARPA (4.14/4.22)
    id AA19637; Sat, 14 Jul 84 23:25:00 pdt
Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.22)
    id AA21457; Sat, 14 Jul 84 23:24:42 pdt
Date: Sat, 14 Jul 84 23:24:42 pdt
From: William C. Wells <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: CP/M Plus (CP/M 3.0) Software

I am trying to identify commercial and public domain software that runs under
CP/M Plus.  Most lists of software only list programs for CP/M 8080/Z80 as
CP/M-80. However, not all CP/M software can handle CP/M Plus disk directories
(with time stamps turned on). If you are running CP/M 3.0 or later on a Z80
or Z80A I would like to hear about what software you have found to work.
I am also interested in software that takes advantage of the CP/M Plus
banked memory.

Bill Wells
[e-mail]
ucbvax!wcwells
[e-mail]

P.S. I am running a PMC Micromate with CP/M 3.0 and 128K banked memory.
15-Jul-84 01:12:01-MDT,1392;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 01:11:55-MDT
Received: From ucb-vax.arpa.ARPA by AMSAA via smtp;  15 Jul 84 2:46 EDT
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.31)
    id AA26318; Sat, 14 Jul 84 23:47:44 pdt
Received:  from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
    by ucbjade.CC.Berkeley.ARPA (4.14/4.22)
    id AA19701; Sat, 14 Jul 84 23:47:55 pdt
Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.22)
    id AA21646; Sat, 14 Jul 84 23:47:36 pdt
Date: Sat, 14 Jul 84 23:47:36 pdt
From: William C. Wells <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: PMC Micromate 101 / TRIOS Micro Systems, Inc.

The PMC Micromate 101 is now being sold and distributed by

    TRIOS Micro Systems, Inc.
    147 Beacon Street
    South San Francisco, CA 94080

TRIOS say they will provide user support for the Micromate. Among other
things they will have a annual service agreement for their Micromate
owners which includes swapping a bad Micromate for a good one.
They also plan to offer a RAM disk for the Micromate and to start
a newsletter for Micromate users.

For more information, contact Kathleen M. Czimber at [phone].


Bill Wells
[e-mail]
ucbvax!wcwells
[e-mail]
15-Jul-84 09:38:51-MDT,901;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 09:38:46-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  15 Jul 84 11:12 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  15 Jul 84 11:06 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 15 Jul 84 8:00-PDT
Date: 13 Jul 84 19:36:33-PDT (Fri)
To: [e-mail]
From: hplabs!sdcrdcf!sdcsvax!sdccs6![e-mail]
Subject: Need a copy of the MODEM7(30/40,etc.) overlay M7AQ-2.ASM
Article-I.D.: sdccs6.1618

HELP!  I need a copy of the modem7 overlay M7AQ-2.ASM.  I have a PCPI
card and the Micromodem ][.  I know other programs exist, but mine are
so old, I am beginning to hate them.   Any help would be appreciated.

                Thanks        John Antypas
                            UC San Diego

                UUCP: ...!sdcsvax!sdccs6!ir320
              arpanet: sdcsvax!sdccs6!ir320@Berkeley
15-Jul-84 10:46:58-MDT,1438;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 10:46:51-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  15 Jul 84 12:23 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  15 Jul 84 12:23 EDT
Date: 15 Jul 1984  10:23 MDT (Sun)
Message-ID: <RCONN.12031540102.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail], [e-mail]
Subject: GET20

    David Towson (towson@amsaa) has contributed an excellent tool
called "GET20" -- it is now in the MICRO:<UNIX.TOOLCHEST> directory on
SIMTEL20 in the files AUTOFTP.DOC (documentation), GET20. (Bourne
shell script), and BEHEAD.C (utility source).  For those UNIX systems
on the DDN, GET20 provides a very convenient way to transfer masses of
files from SIMTEL20 with ease.  For instance, the command

    get20 -a unix unix.crclst

transfers (as ASCII) the file UNIX.CRCLST from the MICRO:<UNIX>
directory on SIMTEL20 to a file of the same name in your current
directory.  Likewise, the command

    get20 -8 cpm.zcpr3 *.com

transfers (as 8-bit binary, automatically reformatting all ITS-binary
files to their normal format) all *.COM files in MICRO:<CPM.ZCPR3>.
David reports that he transferred all 185 files in MICRO:<CPM.ZCPR3>
in one command as a batch job when he was not logged in.

    I've tried it, and I really feel it is an excellent tool.

        Rick
15-Jul-84 18:18:09-MDT,779;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 18:18:05-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  15 Jul 84 19:47 EDT
Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp;  15 Jul 84 19:41 EDT
Date:     Sun, 15 Jul 84 19:44:00 EDT
From:     Dave Farber <[e-mail]>
To:       Jerry E. Pournelle <[e-mail]>
cc:       [e-mail], [e-mail]
Subject:  Re:  S1 & NCC

I asked the S1 people why there was no system at NCC and they mumbled something
about not having a machine they could spare from their development schedule.
Sounded weak. I am driving up there soon and will report.

Hope they are not as invisible as is Venix and Coherent are on support.

15-Jul-84 20:14:34-MDT,843;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 20:14:28-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  15 Jul 84 21:51 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  15 Jul 84 21:51 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 15 Jul 84 18:42-PDT
Date: 6 Jul 84 10:03:40-PDT (Fri)
To: [e-mail]
From:  hplabs!tektronix!uw-beaver!cornell!vax135!ukc!west44![e-mail]
Subject: Red editor posting in net.sources (at last!!)
Article-I.D.: west44.256

The dobbs screen editor that I offered a while ago has been posted
to net.sources. Have fun,
        Keith B.

--

"Specialist subject, the bleedin' obvious!!"

             Keith Brown  ....!ukc!west44!kbrown
                          ( And other leading Usenet paths )
15-Jul-84 20:17:50-MDT,1094;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 20:17:36-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  15 Jul 84 21:51 EDT
Received: From rand-unix.arpa.ARPA by BRL-AOS via smtp;  15 Jul 84 21:46 EDT
Received: from vortex.UUCP by rand-unix.ARPA; Sun, 15 Jul 84 18:26:39 pdt
Date: Sun, 15-Jul-84 18:05:47 PDT
From: Lauren Weinstein <vortex![e-mail]>
Subject: Coherent, etc.
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]

I don't know who you've been talking to (I can't vouch for random OEM's
and such) but I've been dealing with Mark Williams Co. (who make
Coherent) in Chicago for a long time regarding Coherent, and I've
seen no evidence of any support problems.  In fact, I get frequent
reports from people who are impressed at how willing they are to
deal with strange situations and non-standard sorts of problems.
You can even reach them over the UUCP net; contact me if you want
some addresses.

--Lauren--

15-Jul-84 21:32:18-MDT,650;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 21:32:12-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  15 Jul 84 23:11 EDT
Date: 15 Jul 1984  21:12 MDT (Sun)
Message-ID: <WANCHO.12031658162.BABYL@SIMTEL20>
From: "Frank J. Wancho" <[e-mail]>
To:   [e-mail]
Subject: Damaged ZCPR3 file replaced

MICRO:<CPM.ZCPR3>HELP.MAC was discovered to be damaged, and replaced
this afternoon at about 13:45 MDT.  If you grabbed the file prior to
that time, please get it again.  All ZCPR3 files have been reverified.

Sorry for any inconvenience.

--Frank
15-Jul-84 22:32:04-MDT,658;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 22:31:59-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  15 Jul 84 23:57 EDT
Date: 15 Jul 1984  21:58 MDT (Sun)
Message-ID: <WANCHO.12031666658.BABYL@SIMTEL20>
From: "Frank J. Wancho" <[e-mail]>
To:   [e-mail]
Subject: More SIG/M Volumes Available

MICRO:<SIGM.VOL000> has been replaced with a new version.  SIG/M
Volumes 173 to 176 are now available in their respectively named
directories here.

MICRO:<SIGM>SIGM.CRCLST is now being regenerated and should be ready
by the time you read this.

--Frank
15-Jul-84 22:56:34-MDT,1395;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 15 Jul 84 22:56:27-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  16 Jul 84 0:33 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  16 Jul 84 0:26 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 15 Jul 84 21:17-PDT
Date: 6 Jul 84 5:40:54-PDT (Fri)
To: [e-mail]
From:  hplabs!sdcrdcf!sdcsvax!akgua!mcnc!ncsu!uvacs!edison![e-mail]
Subject: Re: MODEM730 & KAYPRO: can't print to Epson
Article-I.D.: edison.290
In-Reply-To: Article <[e-mail]>

Steve, the trouble you're having is due to a bug in the Kaypro BIOS and ROM.
According to the DRI manuals, BIOS call 14 (LISTST) should return a zero in A
if the printer is ready, and an FF if it is not. Kaypro sets the zero FLAG,
but does not return a zero. Their LIST call checks the flag, so it works fine
for them. But MODEM7 et al checks for the contents of A, not the zero flag.
    There are two fixes:
1) Patch MDM7xx to get rid of the ANA A which sets the flag after the call to
the BIOS.
or
2) Patch the BIOS. This is about a six-byte patch, replacing the BIOS jump
vector with a jump to a free area, which contains:
            CALL LISTST
        RNZ
        XRA A
        RET.
If you have access to Compuserve, there's a complete patch in CP-MIG XA1.
I understand it is also on the Detroit TRCM.
16-Jul-84 05:10:20-MDT,1115;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 16 Jul 84 05:10:16-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  16 Jul 84 6:37 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  16 Jul 84 6:28 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 16 Jul 84 2:57-PDT
Date: 11 Jul 84 12:34:00-PDT (Wed)
To: [e-mail]
From: pur-ee!uiucdcs!ea![e-mail]
Subject: Re: XLISP on SIMTEL20? (REQUEST) - (nf)
Article-I.D.: ea.7800007
In-Reply-To: Article <[e-mail]>

#R:sri-arpa:-163600:ea:7800007:000:467
ea!mwm    Jul 11 14:34:00 1984

Speaking of XLISP:

I would like to have a copy to try porting to CP/M-68K (no flames on
CP/M-68K, unless you want to donate an HD & a Unix license). My letter &
check to SIG/M seems to have fallen into a hole. So, could some kind person
who can FTP the thing off of SIMTEL-20 please get in contact with me about
helping me get a copy? I use CP/M 8" disks, or the ubiquitous xmodem
protocol. I can be reached from ARPA as mtxinu!ea![e-mail].

    Thanx,
    <mike
16-Jul-84 06:18:43-MDT,1004;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 16 Jul 84 06:18:37-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  16 Jul 84 7:53 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  16 Jul 84 7:50 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 16 Jul 84 4:38-PDT
Date: 14 Jul 84 9:01:10-PDT (Sat)
To: [e-mail]
From:  hplabs!hao!seismo!rlgvax!cvl!umcp-cs!aplvax!cp1![e-mail]
Subject: Re: Xerox 820-I clearinghouse/mailing list/bulletin board
Article-I.D.: cp1.721
In-Reply-To: Article <[e-mail]>

Count me in, especially for packet radio applications.

--


======================================================================
signed: Rod Hart (wa3mez)
        Chesapeake & Potomac Tel. Co.
        Bell Atlantic Inc.
        Silver Spring, Md.
        gamma!cp1!hart - umcp-cs!cp1!hart - aplvax!cp1!hart
======================================================================
16-Jul-84 08:10:51-MDT,1753;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 16 Jul 84 08:10:44-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  16 Jul 84 9:38 EDT
Date: 16 Jul 1984  07:33 MDT (Mon)
Message-ID: <KPETERSEN.12031771212.BABYL@SIMTEL20>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: CP/M 2.2 BIOS support on CP/M+

BIOS2RSX for CP/M+ users is now available on SIMTEL20.
Here is an excerpt from the source code which explains what
this RSX does:

BIOS2RSX 18Jan84 By Mike Griswold

       This RSX will provide CP/M 2.2 compatible BIOS support
       for CP/M 3.x.  Primarily it performs logical sector
       blocking and deblocking needed for some programs.
       All actual I/O is done by the CP/M 3.0 BIOS.

Typed in from the Dr. Dobb's Journal article in the July 84
issue.                                       mabry

Modified 9 July 1984 to run on an 8085 rather than just a Z80 !
Also added trap for BDOS call 12 (version number) and returns
the indication that the calling program is running under
version 2.2 of CP/M.  This is necessary for programs that
are written to trap a CP/M Plus environment but not able to
handle the physical sector I/O of a CP/M Plus BIOS.
                                               mabry

       This equate is the only hardware dependent value.
       It should be set to the largest sector size that
       will be used.

max$sector$size:        equ     256

The files on SIMTEL20 are:
Filename            Type     Bytes     Sectors     CRC

Directory MICRO:<CPM.CPM3>
BIOS2RSX.ASM.1            ASCII     11748   92 =  5CH  D10BH
BIOS2RSX.RSX.1            COM      1536   12 =   CH  7218H

--Keith
16-Jul-84 11:40:53-MDT,641;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 16 Jul 84 11:40:48-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  16 Jul 84 13:02 EDT
Received: From jpl-vlsi.arpa.ARPA by BRL-AOS via smtp;  16 Jul 84 12:59 EDT
Date: 15 Jul 1984 1122 PDT
From: Peter Lyman <[e-mail]>
Subject: ITS BINNARYCONVERSION VAX/VMS
To: [e-mail]
Reply-To: [e-mail]

Can sonme one send me pointers to how I handle ITS conversions on
a VAX/VMS....

                                          tnx
                                            peter lyman
------
16-Jul-84 12:51:03-MDT,4333;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 16 Jul 84 12:50:31-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  16 Jul 84 14:07 EDT
Received: From amsaa.arpa.ARPA by BRL-AOS via smtp;  16 Jul 84 14:00 EDT
Date:     Mon, 16 Jul 84 13:54:10 EDT
From:     David Towson (CSD) <[e-mail]>
To:       Richard Conn <[e-mail]>
cc:       [e-mail], [e-mail]
Subject:  Re: GET20 (~3750 chars)

Giving credit where credit is due, I must emphatically state that I was only
a clerk (and occasional needler) in the development of the automatic FTP
programs for UNIX systems.  The mastermind was Ferd Brundick <fsbrn@brl-voc>
of the Army Ballistic Research Labs.  HE wrote the programs that automatically
run FTP.  All I did was write some shell scripts that use Ferd's programs, and
I also wrote the documentation file, part of which is appended below.  So since
it was Ferd who wrote the programs, I can safely agree wholeheartedly with
Rick Conn:  These programs are REALLY NEAT!


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

                    AUTOMATIC FTP PROGRAMS FOR UNIX SYSTEMS



     These automatic FTP programs for UNIX systems provide a nearly effortless
way to transfer files from the public-domain archives on SIMTEL20 using the
InterNet File Transfer Protocol, FTP.  The principal "worker" in this
collection is the program GET20, a Bourne shell script written by Ferd Brundick
of the U.S. Army Ballistic Research Laboratory.  GET20 accepts inputs from the
keyboard, or more conveniently from another shell script, and then calls the
FTP program on the user's system and provides all needed inputs.  Three file
transfer modes are supported, ASCII, binary image, and binary in 8-bit bytes.
SIMTEL20 is a 36-bit word-size PDP-20 running the TOPS-20 operating system.
Therefore, only the ASCII and 8-bit-byte transfer modes will be useful for
obtaining files from the public domain archives, as the data in these files
must be unpacked from the 36-bit SIMTEL20 words and repacked for storage in
16 or 32-bit UNIX words.  The binary image transfer mode is provided only for
special applications.  GET20 can be (and has been) easily edited to allow
automatic retrieval of files from other machines that honor an anonymous FTP
login.  Once GET20 has been set in action, all aspects of the FTP process
happen automatically.

     There are currently five archives on SIMTEL20:

        MICRO:<CPM>
        MICRO:<SIGM>
        MICRO:<CPMUG>
        MICRO:<UNIX>
        MICRO:<PC-BLUE>

All files in <UNIX> are in ASCII.  Some files in <CPM>, <SIGM>, <CPMUG> and
<PC-BLUE> are in ASCII, while others are in ITS binary.  The general file-name
format for all archive files is:

        MICRO:<ARCHIVE_NAME.DIRECTORY_NAME>PROGRAM_NAME

GET20 has the device-name MICRO: built-in, but the other three parts of the
path-name must be supplied by the user.  Thus, a typical command-line for GET20
looks like this:

        get20 -a sigm.vol007 james.bond

or alternately,

        get20 -a sigm.vol007 james.bond new_name

The first form will transfer the file keeping the same name (in this case,
james.bond), and the second form will give the transferred file a new name on
the local system.  If you give the command "get20" (with no arguments), GET20
will display a usage statement.

     The REAL convenience of GET20 comes from driving it with one-liner shell
scripts that accept user input in VERY abbreviated form.  For example, the
one-liner "siga" , which obtains ASCII files from the <SIGM> archive, contains:

        get20 -a sigm.vol$*

To obtain the file of the previous example, a user need only type:

        siga 007 james.bond

If a user wants to do frequent ASCII transfers from the <CPM.MODEM7>
directory, the one-liner "m7a" (or some such name) having the form:

        get20 -a cpm.modem7 $*

can be used.  The user will then type only:

        m7a mdm730.asm

The possibilities are endless.


     NOTE:  The above is just a piece of the documentation file.  For the full
story, FTP the file MICRO:<UNIX.TOOLCHEST>AUTOFTP.DOC from SIMTEL20.


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


Dave
[e-mail]

16-Jul-84 13:51:31-MDT,1006;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 16 Jul 84 13:51:21-MDT
Date:     Mon, 16 Jul 84 15:18:40 EDT
From:     Dave Towson (info-cpm) <[e-mail]>
To:       [e-mail]
Subject:  [Douglas Good:  BIOS]

Would somebody please answer this; I'm kind of tied-up right now.  Thanks.


Dave


----- Forwarded message # 1:

Received: From utexas-20.arpa.ARPA by AMSAA via smtp;  15 Jul 84 20:43 EDT
Date: Sun 15 Jul 84 19:45:02-CDT
From: Douglas Good <[e-mail]>
Subject: BIOS
To: [e-mail]

I'm trying to implement Pascal on my system and I got together everything
I need except for one thing, my BIOS. I know it's relatively easy to
extract but I've never done anything like that before. How can I extract
my BIOS from CP/M in HEX format? I've already looked for a file called
CBIOS.ASM or BIOS.ASM on disk but it's not there.

        --Doug
-------

----- End of forwarded messages
17-Jul-84 18:46:48-MDT,1404;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 17 Jul 84 18:46:39-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  16 Jul 84 19:36 EDT
Received: From udel-ee.arpa.ARPA by BRL-AOS via smtp;  16 Jul 84 19:29 EDT
Date:     Mon, 16 Jul 84 19:28:32 EDT
From:     Dave Farber <[e-mail]>
To:       Lauren Weinstein <vortex![e-mail]>
cc:       [e-mail], [e-mail], [e-mail]
Subject:  Re:  Coherent, etc.

Lauren,

I purchased my Coherent from Mark Williams direct. I paid the normal
fee (no educational or anything). I got ONE release with a hell of
a lot of bugs. When I called them for help I got a run arround.
After several months I sent them a MCI letter asking them why I never
got updates or anything. I got a phone call that said they would
send me something undefined. That was about 5 months ago and still
NOTHING.

I am persoanlly sick of companies that try to give the look of
a real business but act like garage attic hackers. My experiences with
SCO on Xenix are exactly the opposite. They are a professional
operation that understands that people need to use their systems NOt just
pay for them. I wanted Unix on the PC for real honest work and expected
real support!!!.

I will be happy to expand on this if anyone likes.

Sick and tired

Dave
17-Jul-84 18:47:22-MDT,2479;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 17 Jul 84 18:47:04-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  16 Jul 84 22:57 EDT
Received: From rand-unix.arpa.ARPA by BRL-AOS via smtp;  16 Jul 84 21:30 EDT
Received: from vortex.UUCP by rand-unix.ARPA; Mon, 16 Jul 84 18:30:34 pdt
Date: Mon, 16-Jul-84 18:02:05 PDT
From: Lauren Weinstein <vortex![e-mail]>
Subject: your Coherent problems
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]

Dave,

I'm somewhat at a loss to understand the situation you describe, since
it runs completely counter to my own experiences and to those of many
people I talk to frequently about Coherent and Mark Williams Co.
If there was a lag of 5 months I feel safe in assuming that something
got lost -- most people I know have commented that they got the
requested updates virtually immediately after requesting them.

From what you describe, it sounds like you had one of the very early
XT versions that had a particular problem due to an undocumented
change in the disk drives/controllers that IBM began installing
in the PC's.  However, this problem was fixed LONG ago -- there have
been numerous intermediate releases of Coherent sent out to
people on request on a continuous basis.  I personally have been
encouraging MWC to hold off the next *major* release of the system
so that a pile of useful new utilities can be included, such as
an EMACS-compatible editor (it uses termcap and the standard
Coherent H19/Z19 screen emulation, complete with meta key) ... it's
primarily a matter of testing the new version and getting the rather
voluminous documentation in order.

In any case, intermediate versions of the system have been going out to
people who requested them all along, and yours is the first report
I've had of "support problems."  Since I talk to MWC frequently, I
invite you to give me a call and explain your situation, and I'll
be happy to make sure that it's cleared up.

--Lauren--

P.S.  You mentioned MCI mail -- which triggered off one of my pet
      angers -- I've had reports of about 30% of MCI mail
      messages never being delivered.  I can't prove this directly
      since I don't use it, but I've had lots of people try to
      send *me* MCI mail and it almost never arrives!

      Talk to you later.

--LW--

17-Jul-84 18:47:12-MDT,863;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 17 Jul 84 18:47:06-MDT
Date:     Tue, 17 Jul 84 13:14:40 EDT
From:     Dave Towson (info-cpm) <[e-mail]>
To:       [e-mail], [e-mail]
Subject:  [Frank Wancho:  SIMTEL20 is down]

I'm afraid those wishing to obtain public domain files from SIMTEL20 will
have to wait for a while - see below.


Dave


----- Forwarded message # 1:

Received: From stl-host1.arpa.ARPA by AMSAA via smtp;  17 Jul 84 12:23 EDT
Date: Tue 17 Jul 84 11:24:07-CDT
From: Frank Wancho <[e-mail]>
Subject: SIMTEL20 is down
To: [e-mail]
cc: [e-mail]

The SIMTEL20 is down with hardware problems.  We have no estimate
of uptime at the moment...

--Frank
-------

----- End of forwarded messages
18-Jul-84 02:12:48-MDT,1385;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 18 Jul 84 02:12:43-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  18 Jul 84 3:44 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  18 Jul 84 3:38 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 0:33-PDT
Date: 15 Jul 84 10:30:45-PDT (Sun)
To: [e-mail]
From: hplabs!sdcrdcf!sdcsvax!sdccs6![e-mail]
Subject: NEED HELP WITH MDM7!
Article-I.D.: sdccs6.1620

HELP! I finally have the needed overlays (m7aq@2/3) to allow my
Applicard and micromodem II to work together only to discover the
program appears SPECIFICALLY written for MDM729.  I had tried MDM740
but it acted very weird.  I have to find (please) a copy of
MDM730/729 which is already asm.  (I don't feel like download what
the local boards say is 850 sectors at 300 baud.)

Any help or copies would be greatly appeciated.

                    John Antypas
                    UC San Diego
    UUCP: ...!sdcsvax!sdccs6!ir320
    arpanet: sdcsvax!sdccs6!ir320@Berkeley

PS: We don't have the capability to ftp files from other machines so
don't try sending .com files to this account, unless you have the
wonderful utility UNLOAD.com which creates those hex files.
I can be reached at [phone] evenings.  Leave mail so I'll know
to expect your call and I'll avoid the BBS's.
18-Jul-84 03:24:34-MDT,1115;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 18 Jul 84 03:24:30-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  18 Jul 84 4:58 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  18 Jul 84 4:50 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 1:30-PDT
Date: 11 Jul 84 12:34:00-PDT (Wed)
To: [e-mail]
From: pur-ee!uiucdcs!ea![e-mail]
Subject: Re: XLISP on SIMTEL20? (REQUEST) - (nf)
Article-I.D.: ea.7800007
In-Reply-To: Article <[e-mail]>

#R:sri-arpa:-163600:ea:7800007:000:467
ea!mwm    Jul 11 14:34:00 1984

Speaking of XLISP:

I would like to have a copy to try porting to CP/M-68K (no flames on
CP/M-68K, unless you want to donate an HD & a Unix license). My letter &
check to SIG/M seems to have fallen into a hole. So, could some kind person
who can FTP the thing off of SIMTEL-20 please get in contact with me about
helping me get a copy? I use CP/M 8" disks, or the ubiquitous xmodem
protocol. I can be reached from ARPA as mtxinu!ea![e-mail].

    Thanx,
    <mike
18-Jul-84 07:03:30-MDT,1669;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 18 Jul 84 07:03:20-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  18 Jul 84 8:24 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  18 Jul 84 8:20 EDT
Date: 18 Jul 1984  06:20 MDT (Wed)
Message-ID: <RCONN.12032282181.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Cc:   [e-mail]
Subject: [CSTROM: ZCPR3]
In-reply-to: Msg of 18 Jul 1984  05:48-MDT from CSTROM

Hi, Charlie,

    Thanks for the comments.  Re CMDSET, I'll look at it and
modify the book to include something about it if it was omitted ... if
not, I'll be sure the index references it.  Re the path, I haven't
encountered any problem with it.  Usually the BDOS error comes if the
path is not properly terminated (by a binary 0).  You might want to
check that.

    I have been receiving several good comments on ZCPR3
personally ... perhaps they are not going out publically.  Also, the
magazines are picking up on it ... User's Guide has already commented
on it in their review of the Ampro, and I know that others
are planning feature articles.  I
guess you will see more in the months to come .. by then the book will
be out, and people can really attack it.

    The phase 2 stuff is coming along very nicely.  I think you
will be very pleased with it.  Most of it consists of screen-oriented
utilities like VFILER, VMENU, DU3, MU3, and I am working on an
RCP-resident version of MU3 so that an RCP-resident shell which can be
used to debug programs as they reside in the TPA will be available.

        Enjoy!

        Rick
18-Jul-84 08:29:03-MDT,636;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 18 Jul 84 08:28:57-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  18 Jul 84 9:45 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  18 Jul 84 9:36 EDT
Date: Wed 18 Jul 84 07:36:04-MDT
From: Jim Forrest <[e-mail]>
Subject: BYE & RBBS35 Info Needed
To: [e-mail]
cc: [e-mail]

When running BYE (MBYE-33) and RBBS35, how can you protect the file
with user passwords. Running ZCPR2 in secure mode but users can still
access password file. Any help appreciated.

Jim
-------
18-Jul-84 11:13:17-MDT,760;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 18 Jul 84 11:13:09-MDT
Date:     Wed, 18 Jul 84 12:23:13 EDT
From:     Dave Towson (info-cpm) <[e-mail]>
To:       [e-mail]
Subject:  [Frank Wancho:  SIMTEL20 returns]

SIMTEL20 is back - YAY!!!


----- Forwarded message # 1:

Received: From stl-host1.arpa.ARPA by AMSAA via smtp;  17 Jul 84 15:55 EDT
Date: Tue 17 Jul 84 14:56:54-CDT
From: Frank Wancho <[e-mail]>
Subject: SIMTEL20 returns
To: [e-mail]
cc: [e-mail]

The file system on the SIMTEL20 is about to be reloaded and
the machine should be up sometime this evening.

--Frank
-------

----- End of forwarded messages
18-Jul-84 11:30:24-MDT,904;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 18 Jul 84 11:30:19-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  18 Jul 84 12:49 EDT
Received: From office-2.arpa.ARPA by BRL-AOS via smtp;  18 Jul 84 12:44 EDT
Date: 18-Jul-84 09:40 PDT
From: [e-mail]
Subject: ZCPR3 and Ampro
To: [e-mail]
Message-ID: <[OFFICE-2.ARPA]TYM-ACB-5287C>

As a new owner of the Little board, I must comment about ZCPR3.  What is
distributed by AMPRO should not be called ZCPR3 because none of the utilities
are there.  What is there looks like ZCPR with the addition of multicommands per
line.   I have the ZCPR3 documentation (10 messages on the net) and was excited
to try ZCPR3 only to find out that it wasn't there.  The BIOS is modified and
there is even a MOVCPM with ZCPR3 in it! but there ain't none of the other
stuff.

19-Jul-84 01:54:59-MDT,1130;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 01:54:53-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 3:25 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  18 Jul 84 21:31 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 18:26-PDT
Date: 16 Jul 84 12:42:32-PDT (Mon)
To: [e-mail]
From: hplabs!sdcrdcf!sdcsvax!sdccs6![e-mail]
Subject: Need a working copy of mdmfnk.com
Article-I.D.: sdccs6.1624

Hi.  I need a working copy of MDMFNK.COM (though hex or asm is also
OK).  I just finished installing MDM730 with my PCPI system and
everything works great, except I cant seem to set the functions keys
with my copy for MDMFNK.COM.  It allows me to set one or two and then
the other keys either can't be set, or they have garbage.  I tried
this on another system so I know its not my apple.  Any idea?

PS: I saved the files with the right length too.

                    John Antypas
                         UC San Diego

            UUCP:  ...!sdcsvax!sdccs6!ir320
            arpanet: sdcsvax!sdccs6!ir320@Berkeley
19-Jul-84 01:58:01-MDT,970;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 01:57:56-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 3:26 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  18 Jul 84 21:42 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 18:28-PDT
Date: 16 Jul 84 22:52:54-PDT (Mon)
To: [e-mail]
From: hplabs!sdcrdcf!sdcsvax!sdccs6![e-mail]
Subject: Need Morrow MD2 Help
Article-I.D.: sdccs6.1629

Help! We have a Morrow MD2 with a USR Password 1200 on it and a Silver
Reed printer.  We have the modem on the printer/modem port and the
Silver Reed on what appears to be an accesorry par. port.  We can't
seem to print from the modem program (MDM730 w. M7MD-1.OVL) nor can we
dial the modem after using Wordstar.  Any help, suggestions?

            John Antypas
            UC San Diego

    UUCP: ...!sdcsvax!sdccs6!ir320
    arpa: sdcsvax!sdccs6!ir320@Berkeley
19-Jul-84 02:02:58-MDT,1062;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 02:02:52-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 3:26 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  18 Jul 84 22:03 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 18:56-PDT
Date: 29 Jul 84 21:40:00-EDT (Sun)
To: [e-mail]
From: pur-ee!uiucdcs![e-mail]
Subject: Do You Know Kermit??!? - (nf)
Article-I.D.: uiucdcs.36300001

#N:uiucdcs:36300001:000:459
uiucdcs!hohensee    Jul 15 23:40:00 1984


     Would anyone have information regarding a
file transfer program called "Kermit"?  From what I
understand, it is used with DEC O/S running also under
CP/M and MSDOS on the DEC Rainbow.  Again, from what
I understand, it is used to in file transfer within
DEC's (?) public domain software BBS called the MARKET
System.

                          Rainbow owner,
                          Bill Hohensee
                          uiucdcs!hohensee
19-Jul-84 02:31:49-MDT,866;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 02:31:44-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 3:26 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  18 Jul 84 22:04 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 18:57-PDT
Date: 29 Jul 84 21:44:00-EDT (Sun)
To: [e-mail]
From: pur-ee!uiucdcs![e-mail]
Subject: Access to Simtel20??!? - (nf)
Article-I.D.: uiucdcs.36300002

#N:uiucdcs:36300002:000:267
uiucdcs!hohensee    Jul 15 23:44:00 1984

      Could I ask a dumb question ...

      Can anybody tell me what is the "simtel20" BBS, and
how does one can access to it??

                                thanks,
                                Bill Hohensee
                                uiucdcs!hohensee
19-Jul-84 02:49:14-MDT,1801;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 02:49:07-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 3:26 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  18 Jul 84 23:32 EDT
Date: 18 Jul 1984  21:25 MDT (Wed)
Message-ID: <RCONN.12032447018.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   Jim Forrest <[e-mail]>
Cc:   [e-mail]
Subject: BYE & RBBS35 Info Needed
In-reply-to: Msg of 18 Jul 1984  07:36-MDT from Jim Forrest <JFORREST at SIMTEL20.ARPA>

    Not meaning to sound like a broken record (squeek, squeek),
but ...

    ZCPR3 solves that problem cleanly.  A system can be made
secure under ZCPR3 by disabling the DU form and enabling only the DIR
form.  Passwords are then assigned to each key directory, and all
commands along the path are either "safe" or wheel-byte protected
(PATH itself will only run if the wheel byte is set).  Then, a user
cannot: (1) see a protected disk dir or (2) TYPE a file, PRINT a file,
or do anything with any file in a protected disk dir without giving
the password for that dir!  See the section on secure systems in
the User's Perspective.  I am excited about this concept and am fairly
sure it can't be broken without internal knowledge of the target
system.

    If anyone can find a way to break this, let me know.

    In the way of example, note that the DU form is disabled.
This means that you cannot issue the command TYPE A7: or anything like
that.  You MUST use the DIR: form, so if you say TYPE SYSROOT:, ZCPR3
will see the PW entry for SYSROOT and prompt the user for a PW.  If no
match, SYSROOT is expanded as his current dir instead, and the command
runs there!

    Hope this helps.

        Rick
19-Jul-84 02:51:31-MDT,1641;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 02:51:25-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 3:26 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  18 Jul 84 22:36 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 19:29-PDT
Date: 16 Jul 84 5:04:14-PDT (Mon)
To: [e-mail]
From: ihnp4!ihuxk![e-mail]
Subject: C Compiler for CP/M-80?
Article-I.D.: ihuxk.680

I am considering the possibility of purchasing a C compiler for use
on my home computer which has a cpm based operating system.  I have
read the articles in the August 83 issue of BYTE - The Unix C complier
in a CP/M Environment, and Five C Compilers for CP/M-80, and have
reached a conclusion similar to Kern's about the five compilers he
reviewed, namely that the compiler should adhere to the Kernighan &
Ritchie standard, perform compilations rapidly and have clean
implementation, and be reasonably priced.  Of the compilers mentioned
in the article, the Aztec, BDS and C/80 seem to fill the bill.

I would like to hear from anyone who has experience with these
compilers preferably with more than one and can make a valid
comparison.  I would also like to hear from anyone who might know
of a compiler that was not mentioned in the article, but meets the
criteria.  The upper price limit for this is about $250.

Mail replies to ihuxk!db21.  If there is sufficient response and/or
information not mentioned in the articles, I will try to summarize
for the net.  Thanks in advance for your help.
                    Dave Beyerl
19-Jul-84 03:00:10-MDT,4662;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 02:59:56-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 3:26 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  19 Jul 84 0:06 EDT
Date: 18 Jul 1984  22:05 MDT (Wed)
Message-ID: <RCONN.12032454321.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Cc:   [e-mail]
Subject: ZCPR3 and Ampro
In-reply-to: Msg of 18 Jul 1984  10:40-MDT from ACB.TYM at OFFICE-2.ARPA


    You are partly right and partly wrong.  You are wrong in that
the CP is really the ZCPR3 CP.  Yes, that is absolutely true.  All
ZCPR3 features are supportable with it.  You are right in that they
(Ampro) are not [yet] sending out the ZCPR3 SYSTEM, with all of the
utilities.  I recommend that you contact Ampro directly and complain.
One disk with the 58 COM files will give you what you want, and Echelon
has already sent me all 14 distribution disks in Ampro format.  Ampro
is eager to please its customers and get a good rep (note that you can
buy their BIOS and sources to ALL their system-specific utilities for
$49!).  What they have had trouble with (and I can't blame them
because full doc isn't out yet) is grasping the scope of ZCPR3.

    EONs ago (EON = more than 2 months) when we first established
relations, Ampro had known of me thru ZCPR2 and was explicitly after
FRIENDLY.  We contracted for FRIENDLY, and, at that time, ZCPR2+ was
in use by me.  No one will ever see ZCPR2+ because it lived for only a
few months until I completed the first ZCPR3.  Anyway, ZCPR2+ had
shells which made FRIENDLY work.  As ZCPR3 developed, I did not want
to have to support ZCPR2+, so we agreed that Ampro would go to ZCPR3,
but, again, their mind set was on getting FRIENDLY, NOT ZCPR3.
Anyway, to make a long story short, as the ZCPR3 CP finalized, I sent
them four versions of ZCPR3 for the Ampro Little Board.  They ranged
from the minimum system thru a full-featured system with everything
turned on.  A secure system was even included.  Still thinking of
FRIENDLY, they elected to provide the minimum system.  It gave the
users the max TPA possible and supported the major ZCPR3 features sans
RCPs, FCPs, etc.  The external command line, shells, (I think) named
dirs, messages, and registers were in there.  This is probably what
you have.

    Now that more doc is coming out, Ampro is finding out more
about what ZCPR3 is.  Evidently they still have not changed their
original approach (again, I don't blame them since they had thousands
of disks preconfigured and it would cost lots to change), but if you
call them (and other Ampro users like you call them) and tell them
that you want a full-featured ZCPR3, I have a hunch that they will
comply.  They already have it ... it is just a matter of setting up
the disks.  If enough people ask, they may start sending out full
systems as standard.  Some will want the full system, others will be
very applications oriented and want the min system.


    Another note:  early versions of the Ampro had an error in the
BIOS.  If a file was opened, a long delay occurred (long enough to let
the drives stop), and then a write occurred, the disk was trashed.
This shows itself when PIP runs to concatenate two large files
usually.  This has definitely been fixed, but test it and see if yours
does it.  If it does, you need the new BIOS also.

    Ampro is an excellent company.  I really like dealing with
them.  Remember that they are learning about ZCPR3 like the rest of us
(myself included, since I just discovered something really wonderful
about it this morning ... more on this later), and, since they already
have the rights to include ZCPR3 and they want to please their
customers, if enough of you bother them with requests for the rest of
the software, they may start including it naturally.  Their only
additional overhead is the extra disk and copying for it.  I can't
speak for them, and they may have a different perspective on this than
I, but it would be worth your time to call them and ask.

    Finally, note also that the release of ZCPR3 is not complete.
Phase 2 is coming, and, if you liked Phase 1 ... Phase 2 will open so
many doors you won't know where to start.  I am starting to boggle
here at all of the possiblities and HAVE to decide when to stop with
Phase 2 soon.  Completeness is the key ... and I don't want to leave
anything out.  The book will be current thru the entire release,
including phase 2.  It is only two utilities behind right now.

    Enjoy!

        Rick
19-Jul-84 03:24:50-MDT,1920;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 03:24:40-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 3:26 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  19 Jul 84 0:11 EDT
Date: 18 Jul 1984  22:10 MDT (Wed)
Message-ID: <RCONN.12032455258.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Subject: [SSalzman.ES: booting in different user areas]

FYI -- I thought you might me interested in general on what Isaac has
to say.  You see, while the ZCPR3 doc is a lot so far, the book (which
is already 380+ pages in draft form) tells everything, including the
hidden capabilities of ZCPR3.  For instance, you may be familiar with
the shell concept and the RCP concept, but what happens if you COMBINE
them???  Wonderful, wonderful ... golly, gee whiz, Batman!  I can't
stand it ... more later.

    Rick


Date: Wednesday, 18 July 1984  09:11-MDT
From: SSalzman.ES at XEROX.ARPA
To:   Richard Conn <RCONN at SIMTEL20.ARPA>
cc:   ssalzman.ES at XEROX.ARPA
Re:   booting in different user areas

Rick,

Hi. Thanks a lot! I made a little 3 byte patch to my BIOS and low and
behold, I boot into A15:. The shell idea sounds good too, for other
things, but this does
solve my problem at the moment. I'm looking forward to the books and the
phase 2 stuff. I'd like to know how to go about writing a shell and
using the
shell stack and the message buffer. I actually started working on one
for
ZCPR2 a while back (in C) but with the shell stack, I'll postpone that
'till I
know more about it. You I'm having fun with it! I think the aliases are
the
most usefull things of all (in conjunction with the FCP). I've got tons
of things
I'd like to do with it, but no time. It's made my work a lot easier too.
Well,
thanks again, as usual! Take it easy....
                        Isaac.
19-Jul-84 03:39:14-MDT,878;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 03:39:08-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 3:26 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  19 Jul 84 0:14 EDT
Date: 18 Jul 1984  22:14 MDT (Wed)
Message-ID: <RCONN.12032455850.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Cc:   [e-mail]
Subject: booting in different user areas
In-reply-to: Msg of 18 Jul 1984  09:11-MDT from SSalzman.ES at XEROX.ARPA

Isaac,

    The book will include all of those internal details.  There is
a package devoted to shells (how they work, how to write one, etc) and
a new Phase 2 utility  can make ANY COMMAND SEQUENCE [which is short]
into a shell!  Like, DDT can be a shell ... your favorite editor ...
etc, etc.

        Rick
19-Jul-84 03:50:56-MDT,3929;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 03:50:40-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 3:27 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  19 Jul 84 0:21 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 18 Jul 84 20:44-PDT
Date: 16 Jul 84 18:12:43-PDT (Mon)
To: [e-mail]
From:  hplabs!tektronix!uw-beaver!uw-june!entropy!dataio![e-mail]
Subject: MOVCPM: The final solution!!!!!
Article-I.D.: dataio.157

< nonononono please... >
< leave a line for me.. >

OK everyone, I'll talk. I have enjoyed all the discussions on the net
about how to avoid the SYNCHRONIZATION error. Digital Research sure has
you bozos pegged :-). D-R figured you'd try something like this, and
anticipated most of your moves. To patch the package to work the way we
would all like is definitely not worth the effort (I know, I have a fully
disassembled listing stuck on a backup disk somewhere). KEEP READING>>>>>
I will divulge the solution after I indulge myself :-).

What they did was check the serial number, nothing new to all of you by
now, of the running operating system and compare with an internally stored
serial number within MOVCPM. You folks have all been taken for a ride,
BECAUSE THEY DO IT TWICE!!! So even after the clever individual has come
to the point of finding the first check, and fixes it, said problem does
not go away. ha-ha. Like I said, they got you pegged (me too). Most
of us go looking somewhere else once we find this first check.

I have seen some other solutions, like one guy (not on the net) that
had an incredibly involved patch to cause MOVCPM to look at it's OWN
serial number. Not worth the effort. I have done so many configurations
for people that I plumb run out of toes and fingers to count with. In each
instance it was the same thing, MY system (actually running CDOS) trying
to assemble and incorporate some CBIOS into the OTHER GUYS CPM. While I
can appreciate D-R's desired to protect their software, they left the user
with a classic chicken and egg problem - can't run the software till it's
configured, can't configure the software till it runs.

So, I now keep two versions of MOVCPM around: MOVCPM, and MOVXCPM. One runs
under an operating system with the correct serial number, one runs under any
other serial number. If you run the wrong one, you still get the SYNCH. ERR.
What I did is so simple it will make you laugh. I've been chuckling for
years over it. Naturally if you do a test, there is a conditional branch
after it. I simply reversed the sense of the conditional!!! Now the MOVXCPM
program checks to see if the operating system DOES NOT have the correct
serial number (jokes on you, D-R).

I don't have a copy of my listing handy, but I remember the task VERY well.
So, take this patch, and apply to your MOVCPM with a grain of salt:
meaning I may be off a byte or three (no more than that, I promise), and
the sense of the conditional may be wrong. Just remember that the idea is
to use the opposite conditional.

Get out your debugger and look at the location 234h. I am positive of this
location to the extent that it has been at this location in every MOVCPM
that I have seen.

    JP    NZ,025A

Change this instruction to the opposite:

    JP    Z,025A        ; (or vice-versa, whichever is appropriate).

Now look around 2CBh. You will find an identical instruction! Now you take
and do the same hack to this guy and call your new program something
unique (how about HAHA$DR.COM? :-) Just remember that after you have your
new CPM up and running, use the unmodified version of MOVCPM, or you get
halted, same as before.

Please send mail, I want to hear about your success and gratitude. :-)

Erik Lindberg    AKA   del       @ dataio  Redmond, WA

( I used to call myself a hacker.... )
19-Jul-84 04:02:49-MDT,1367;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 04:02:43-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 3:27 EDT
Received: From usc-isid.arpa.ARPA by BRL-AOS via smtp;  19 Jul 84 1:38 EDT
Date: 19 Jul 1984 01:36-EDT
Sender: [e-mail]
Subject: Re: BYE & RBBS35 Info Needed
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Message-ID: <[USC-ISID.ARPA]19-Jul-84 01:36:31.ABN.ISCAMS>
In-Reply-To: The message of Wed 18 Jul 84 07:36:04-MDT from Jim Forrest <[e-mail]>

Jim

I expect some experienced RBBS/BYE Sysops to answer you with more sophisticated
responses, but a PD program I was just looking at kind of tickled my fancy.
You say your users can access the password file, so no luck with passwords.
Well, a little utility program called MAKEFCB (think I got it from SIMTEL20,
maybe the SIG/M archives) changes the file name on disk and directory from
upper case to lower case.  CANNOT be listed, typed, transferred, erased --
NUTTIN!  But it CAN be called from within other programs!  So BYE or whatever
could reach it and use it, but those curious ones cannot!

Just a suggestion that might be fruitful.  (An unusual potential fix anyway!)

Regards,
David Kirschbaum
Toad Hall
ABN.ISCAMS@USC-ISID
19-Jul-84 04:06:06-MDT,1215;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 04:06:00-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 3:48 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  19 Jul 84 3:39 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 19 Jul 84 0:26-PDT
Date: 17 Jul 84 11:17:31-PDT (Tue)
To: [e-mail]
From: hplabs!sdcrdcf!sdcsvax!sdccs6![e-mail]
Subject: Need Morrow Drivers || Morrow System Diskette
Article-I.D.: sdccs6.1630

Attention Morrow User Community!

I have a friend who has a Morrow MD2.  It appears that the person who
did her system integration only allowed her to use EITHER the serial
port OR the parallel port.  (As you can see, this make printing
material coming off the modem very difficult.)  I need some kind
person out there to either mail me the source for a parallel && serial
drivers so I can integrate them into her CP/M or I need some person
local to San Diego, to allow me to have a copy of their system
diskette already preconfigured.

Thanks again.
                John Antypas
                UC San Diego

        UUCP: ...!sdcsvax!sdccs6!ir320
        arpa: sdcsvax!sdccs6!ir320@Berkeley
19-Jul-84 04:57:06-MDT,2293;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 04:56:58-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 5:57 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  19 Jul 84 5:53 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 19 Jul 84 2:33-PDT
Date: 17 Jul 84 6:19:09-PDT (Tue)
To: [e-mail]
From: ihnp4!zehntel!dual!decwrl!dec-rhea!dec-cache![e-mail]
Subject: Announcement: The HOME COMPUTER Newsletter
Article-I.D.: decwrl.2632

I've begun as a home business the publishing of a monthly newsletter
for people who have an interest in home computers but know little or
nothing about them.  You are probably too sophisticated for this
newsletter, but you have friends who would enjoy reading it.

The newsletter is called The HOME COMPUTER Newsletter.  Without a
lot of technical jargon and buzz words, it will bring the following:

  o price information
  o quality information
  o new product announcements
  o trends from the computer industry
  o information for new users to help them feel comfortable with their
    new systems and to learn how to use the systems more effectively.
  o my opinions and recommendations about home computer matters.
  o answers to questions, etc.

The first issue, which is a pre-subscription issue (subscriptions begin
in October), discusses the following topics:

  o Welcome to the Newsletter
  o What the Newsletter will contain
  o The home computer market
  o News flashes
  o Protection from lightning
  o What are home computers?
  o Some good reading
  o Price trends
  o In the next issue (news flashes, what to do with a home computer, how
    to select a home computer, should you buy mail order or from a store,
    and should you buy a "complete package" or individual components.)

If you feel your friends would be interested in looking at the paper,
please pass this information on.  The yearly subscription is $7.00 in
the USA and Canada.  A sample issue can be obtained by sending 25 cents
and a stamped self addressed envelope.  The address is:

The HOME COMPUTER Newsletter
P.O. Box K126
E. Pepperell, MA 01437

Thanks!

Allen Leigh     ...decvax!decwrl!rhea!cache!leigh
19-Jul-84 05:40:37-MDT,773;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 05:40:31-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 7:01 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  19 Jul 84 6:57 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 19 Jul 84 3:41-PDT
Date: 24 Jul 84 10:04:38-EDT (Tue)
To: [e-mail]
From:  hplabs!tektronix!uw-beaver!cornell!vax135!ukc!west44!westcsr![e-mail]
Subject: .PRL File Format Wanted
Article-I.D.: westcsr.166

<>
    Could anybody let me have the precise format of the .PRL files used by
Digital Research's Link-80 program?

--
        Thank you,
            Phil Thompson.
                    {ENGLAND}..!ukc!west44!westcsr!phil
                         ..!ukc!west44!phil
19-Jul-84 05:42:05-MDT,863;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 05:42:00-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 7:02 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  19 Jul 84 6:59 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 19 Jul 84 3:39-PDT
Date: 24 Jul 84 9:52:05-EDT (Tue)
To: [e-mail]
From:  hplabs!tektronix!uw-beaver!cornell!vax135!ukc!west44!westcsr![e-mail]
Subject: .PRL File Format Wanted
Article-I.D.: westcsr.165

<>
    Could anybody supply me with the precise format of .PRL files used by
Digital Research's Link-80 program?

        Thank you,
            Phil Thompson.
                    {ENGLAND}..!ukc!west44!westcsr!phil
                         ..!ukc!west44!phil

--

            Phil Thompson.
                    {ENGLAND}..!ukc!west44!westcsr!phil
                         ..!ukc!west44!phil
19-Jul-84 06:37:13-MDT,900;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 06:37:08-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 7:59 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  19 Jul 84 7:50 EDT
Date: 19 Jul 1984  05:50 MDT (Thu)
Message-ID: <CSTROM.12032538910.BABYL@SIMTEL20>
From: [e-mail]
To:   hplabs!sdcrdcf!sdcsvax!sdccs6![e-mail]
Cc:   [e-mail], [e-mail]
Subject: Need Morrow Drivers || Morrow System Diskette
In-reply-to: Msg of 17 Jul 1984  12:17-MDT from hplabs!sdcrdcf!sdcsvax!sdccs6!ir320 at Ucb-Vax.arpa

Morrow supplies the source to the BIOS, so why not just work from
there? I do understand that in the earliest systems, the BIOS source
was not included. If your friend has such an old software version, I
suggest that she obtain an update in any event.
19-Jul-84 07:37:35-MDT,1172;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 07:37:27-MDT
Received: From mitre.arpa.ARPA by AMSAA via smtp;  19 Jul 84 8:55 EDT
Date: 19 Jul 1984  7:57:26 EDT (Thursday)
From: Jeffrey Edelheit <[e-mail]>
Subject: Re: Do You Know Kermit??!? - (nf)
In-Reply-to: Your message of 29 Jul 84 21:40:00-EDT (Sun)
To: pur-ee!uiucdcs![e-mail]
Cc: [e-mail]

Bill - Kermit is a file transfer protocol developed by Columbia University.
It is a protocol that runs on a large number of "mainframes" (often super-
minis) and also a large number of micros.  The June and July issues of
Byte had a two part article on Kermit.  As you don't have FTP capabilities
with Columbia-20, you can send a net msg to Frank da Cruz (cc.fdc at
columbia-20.arpa) to get further specifics on how a usenetter can get
Kermit.

For what its worth, we are currently looking at Kermit as a candidate as
the "official" file transfer protocol of MITRE.  Also, it is the official
protocol used by the National Institutes of Health's DEC-20 computer
system.

Jeff Edelheit
(edelheit@mitre)

19-Jul-84 08:00:38-MDT,992;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 08:00:31-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  19 Jul 84 9:21 EDT
Date: 19 Jul 1984  07:22 MDT (Thu)
Message-ID: <KPETERSEN.12032555728.BABYL@SIMTEL20>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   Jim Forrest <[e-mail]>
Cc:   [e-mail]
Subject: BYE & RBBS35 Info Needed
In-reply-to: Msg of 18 Jul 1984  07:36-MDT from Jim Forrest <JFORREST at SIMTEL20.ARPA>

Look at SECURTY2.ASM in MICRO:<CPM.RCPM>.  This is assembled and
renamed to RBBS.COM and placed in user zero.  The "real" RBBS and all
its files are placed in a user area that is inaccessable to callers.
SECURTY2 is a small loader program which switches user numbers and
then loads RBBS and jumps to it.  When the user exits RBBS they return
to the original drive/user because the user number change was only
temporary.
--Keith
19-Jul-84 10:52:49-MDT,1255;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 10:52:34-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 12:22 EDT
Received: From usc-isid.arpa.ARPA by BRL-AOS via smtp;  19 Jul 84 12:21 EDT
Date: 19 Jul 1984 12:20-EDT
Sender: [e-mail]
Subject: Re: Do You Know Kermit??!? - (nf)
From: [e-mail]
To: pur-ee!uiucdcs![e-mail]
Cc: [e-mail]
Message-ID: <[USC-ISID.ARPA]19-Jul-84 12:20:22.ABN.ISCAMS>
In-Reply-To: The message of 29 Jul 84 21:40:00-EDT (Sun) from pur-ee!uiucdcs![e-mail]

Rainbow owner (Bill to his friends),

Re Kermit - see last month's BYTE Magazine for all the details (actually,
the month before too - a 2-month production).

Know LOTS about Kermit - but full documentation is available on most
hosts in <DOCUMENTATION>, and for sure at COLUMBIA-20, the home of the
whole program.  Look out there (via anonymous FTP) in KERMIT: for various
documents, READMEs, etc.

I'm forwarding separately the latest Info-Kermit Digest, which reviews how
to get Kermit (and you can subscribe too!).

Regards  (Ain't it fun being green?)

David Kirschbaum
Toad Hall
ABN.ISCAMS@USC-ISID
19-Jul-84 10:53:13-MDT,756;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 10:53:06-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 12:21 EDT
Received: From amsaa.arpa.ARPA by BRL-AOS via smtp;  19 Jul 84 12:18 EDT
Date:     Thu, 19 Jul 84 12:08:10 EDT
From:     David Towson (CSD) <[e-mail]>
To:       pur-ee!uiucdcs![e-mail]
cc:       [e-mail]
Subject:  Re:  Do You Know Kermit??!? - (nf)

Bill - Since Jeff Edelheit has already answered your question, "what is
KERMIT?", I will address your other point - a computer called MARKET.
MARKET is one of several aliases for a DEC2060T known formally on the
Arpanet as DEC-MARLBORO.ARPA.


Dave
[e-mail]

19-Jul-84 11:10:45-MDT,695;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 11:10:39-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 12:32 EDT
Received: From usc-isid.arpa.ARPA by BRL-AOS via smtp;  19 Jul 84 12:33 EDT
Date: 19 Jul 1984 12:30-EDT
Sender: [e-mail]
Subject: Re: Access to Simtel20??!? - (nf)
From: [e-mail]
To: pur-ee!uiucdcs![e-mail]
Cc: [e-mail]
Message-ID: <[USC-ISID.ARPA]19-Jul-84 12:30:51.ABN.ISCAMS>
In-Reply-To: The message of 29 Jul 84 21:44:00-EDT (Sun) from pur-ee!uiucdcs![e-mail]

Info-CPM+

I got him, guys.

David Kirschbaum
Toad Hall
19-Jul-84 12:21:11-MDT,1239;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 12:21:03-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 12:54 EDT
Received: From usc-isid.arpa.ARPA by BRL-AOS via smtp;  19 Jul 84 12:49 EDT
Date: 19 Jul 1984 12:47-EDT
Sender: [e-mail]
Subject: Re: MOVCPM: The final solution!!!!!
From: [e-mail]
To: hplabs!tektronix!uw-beaver!uw-june!entropy!dataio![e-mail]
Cc: [e-mail]
Message-ID: <[USC-ISID.ARPA]19-Jul-84 12:47:37.ABN.ISCAMS>
In-Reply-To: The message of 16 Jul 84 18:12:43-PDT (Mon) from  hplabs!tektronix!uw-beaver!uw-june!entropy!dataio![e-mail]

Erick,

You can call yourself a hacker anytime you want!  Nice fix...elegant even.
Simplest is always bestest.

(My initial fix prior to some elaborate poking around with DDT (yep, and
I DID find both places)) was to let the sucker crash with that "SYNCH..."
and then SAVE 48 CRASHCPM.COM.

Go about my business, patch, etc.  Seemed to be a real relocated CP/M
there!  (As I remember...)

Thanks, mate - kudos to you.

"Golum LOVES Eriks"  (<== requested gratitude)

Regards,
David Kirschbaum
Toad Hall
ABN.ISCAMS@USC-ISID
19-Jul-84 13:07:37-MDT,3138;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 13:07:20-MDT
Received: From ucb-vax.arpa.ARPA by AMSAA via smtp;  19 Jul 84 14:18 EDT
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.31)
    id AA26109; Thu, 19 Jul 84 11:18:04 pdt
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
    by ucbjade.CC.Berkeley.ARPA (4.14/4.22)
    id AA05922; Thu, 19 Jul 84 11:18:49 pdt
Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.23.1)
    id AA19832; Thu, 19 Jul 84 11:18:51 pdt
Date: Thu, 19 Jul 84 11:18:51 pdt
From: William C. Wells <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: CP/M Plus (CP/M 3.0) Software

CP/M Plus Software Digest # 84-1
================================

Date: Sat, 14 Jul 84 23:24:42 pdt
From: William C. Wells <wcwells@ucbopal>
To: [e-mail]
Subject: CP/M Plus (CP/M 3.0) Software

I am trying to identify commercial and public domain software that runs under
CP/M Plus.  Most lists of software only list programs for CP/M 8080/Z80 as
CP/M-80. However, not all CP/M software can handle CP/M Plus disk directories
(with time stamps turned on). If you are running CP/M 3.0 or later on a Z80
or Z80A I would like to hear about what software you have found to work.
I am also interested in software that takes advantage of the CP/M Plus
banked memory.

Bill Wells
[e-mail]
ucbvax!wcwells
[e-mail]

P.S. I am running a PMC Micromate with CP/M 3.0 and 128K banked memory.

-------

Date: Mon 16 Jul 84 15:08:18-PDT
From: Sam Hahn <[e-mail]>

I'd also be curious to find similar software.  Last time I called
New Generation systems, they were planning on a 3.0 versin of MicroShell,
but that was at least half a year ago...

                -- sam hahn [shahn@sumex, samuel@score]
-------

Date: Mon 16 Jul 84 20:59:19-PDT
From: Bruce Tanner <[e-mail]>

Two products I have used that support CP/M 3.0 are Kermit from Columbia
and DU (ver 8.7 I think) from simtel-20.

To support Kermit binary transfers, I've modified the modem input
routine to not strip off the parity bit.  PMC said that this functionality
was in the newer BIOS's under a feature test switch, but I don't know
if it is or not.

[non-related text deleted; In the last paragraph Bruce is referring
to implementing Kermit binary transfers on a PMC Micromate running
CP/M Plus - WCW]

-Bruce

-------

Date: Tue 17 Jul 84 17:28:57-EDT
From: J. Eliot B. Moss <[e-mail]>

I have used the following on CP/M 3.0 with success: The FinalWord, CardBox,
SuperCalc, BDS-C, JRT Pascal, Turbo Pascal, MODEM7, and a variety of SIG/M
type public domain things.  I do not use directory time stamping (my clock
is not integrated into the BIOS yet, etc.).  This may change if I ever get
my own BIOS done ....
                Eliot

[In separate correspondance, Eliot says he is using a SD System
SBC-200 (S-100 board) - WCW]
-------
End of forwarded messages -- CP/M Plus Software Digest # 84-1
19-Jul-84 14:46:12-MDT,637;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 19 Jul 84 14:46:05-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  19 Jul 84 16:15 EDT
Received: From xerox.arpa.ARPA by BRL-AOS via smtp;  19 Jul 84 16:13 EDT
Received: from Chardonnay.ms by ArpaGateway.ms ; 19 JUL 84 13:13:14 PDT
Date: Thu, 19 Jul 84 13:13 PDT
From: [e-mail]
Subject: Re: Xerox 820-I clearinghouse/mailing list/bulletin board
In-reply-to:
 "hplabs!hao!seismo!rlgvax!cvl!umcp-cs!aplvax!cp1![e-mail]'s
 message of 14 Jul 84 9:01:10 PDT (Sat)"
To:[e-mail]
cc: [e-mail]



20-Jul-84 09:47:10-MDT,719;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 20 Jul 84 09:46:58-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  20 Jul 84 11:07 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  20 Jul 84 8:08 EDT
Date: 20 Jul 1984  06:08 MDT (Fri)
Message-ID: <RCONN.12032804287.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Subject: Ampro

    I noted in this month's Microsystems that the ad on page 31
(or so) explicitly states that they are including the ZCPR3 CCP and
says nothing else.  This is absolutely true.  Remember, however, that
the CCP can be configured in a lot of ways (billyuns and billyuns).

    Rick
20-Jul-84 10:06:44-MDT,674;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 20 Jul 84 10:06:32-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  20 Jul 84 11:07 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  20 Jul 84 8:10 EDT
Date: 20 Jul 1984  06:09 MDT (Fri)
Message-ID: <RCONN.12032804598.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Cc:   [e-mail]
Subject: booting in different user areas
In-reply-to: Msg of 19 Jul 1984  10:36-MDT from ABN.ISCAMS at USC-ISID.ARPA

I DO sleep in my spare time ... usually from 3-4 AM every day, whether
I need it or not!

    Rick
20-Jul-84 10:13:45-MDT,1239;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 20 Jul 84 10:13:36-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  20 Jul 84 11:19 EDT
Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp;  20 Jul 84 11:12 EDT
Received: From gmr.csnet by csnet-relay;  20 Jul 84 10:41 EDT
Date:     Fri, 20 Jul 84 09:51 EST
From:      [e-mail]
MMDF-Warning:  Parse error in preceeding line at csnet-relay.arpa
To:       [e-mail]
Subject:  modem programs


Does anyone ahve a public domain program for doing modem control,
communications, and file transfer that is compatible with MODEM7 protocol
and is written in a high level language ( C, PASCAL, or FORTRAN preferred)?

I need to communicate with several different host systems and want compatible
file transfer with all of them. The systems include VAX/VMS, VAX/UNIX,
PDP-11/RT-11, Motorola VMC-68/Versados.

I am on CSNET, not ARPANET, so I cannot FTP files. If there is a suitable
program archived somewhere on the net, I will have to access it
indirectly.

Thanks for any help you can give.

        Robert Haar
        General Motors Research Labs
        [phone]

        HAAR.GMR@CSNET-RELAY


20-Jul-84 10:14:39-MDT,5074;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 20 Jul 84 10:14:14-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  20 Jul 84 11:08 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  20 Jul 84 8:49 EDT
Date: 20 Jul 1984  06:48 MDT (Fri)
Message-ID: <RCONN.12032811726.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Subject: SHSET

    Well, the new feature (actually, utility pair) is in place,
and it works quite nicely.  I thought I'd describe the concept to you
and see what people think about it.

    ZCPR3 supports a concept (taken from AT&T's UNIX) which I call
shells.  The UNIX shell accepts a command line, interprets it,
suspends itself and allows the command line to execute, and then
resumes.  The ZCPR3 shell, since we have a single-process (simple) OS,
simply accepts a command line, interprets it, terminates (leaving
messages about as to how ZCPR3 CP should reinvoke it) and allows the
command line to execute, and then is resumed by the ZCPR3 CP.  The
bottom line is that, once a shell is running, whenever the ZCPR3 CP
would print its prompt (DU:DIR>, like the CP/M D> prompt), the shell
runs instead (no prompt appears from the ZCPR3 CP), and whatever the
shell does becomes the user's interface to his system.  Shells can be
nested up to N levels deep (I recommend 4), so one shell can run
another can run another ... .  Examples of supplied ZCPR3 shells are
MENU (which prints a menu and allows the user to select a menu item
with a single keystroke), VFILER (which shows a file directory, allows
the user to move the cursor around and manipulate files [copy, delete,
rename, etc]), VMENU (which is a cross between VFILER [with the
directory display and arrow] and MENU [with the menu display and
selection]), and SH (which allows named variable sets and substitution
in various forms).

    The new SHSET command (which is ONLY 1K in size) now exists
and it allows ANYTHING to become a shell, whether is knows about ZCPR3
or not.  The syntax is:

        SHSET cmd1;cmd2;...

and, like a shell, when the ZCPR3 CP is going to print its prompt,
it realizes that a shell has been defined, but instead of running just
one program as a shell, it runs a command sequence.  Along with SHSET
is CMD, another 1K utility, which prompts the user for a command line
and builds the new command line into the command line buffer in place
of itself, allowing execution to resume with the command line the user
just typed followed by any commands which originally followed CMD.
Now commands like the following can be created:

    SHSET WS;CMD

Each time the ZCPR3 CP is going to print a prompt, Word Star is run
instead.  The users does what he wishes inside of Word Star, and, when
he exits, CMD is run.  CMD will prompt him for a line:

    CMD DU:DIR> user input goes here

The user's input is entered, it is executed, and then the shell is
reinvoked, running Word Star again.  To get out of the loop, the handy
ZCPR3 Phase 1 command SHCTRL can be run.  The command SHCTRL POP will
pop the shell stack one level, terminating the WS;CMD sequence, and
invoking the next lower shell, whether it is VFILER, VMENU, or the
ZCPR3 CP itself.

    One feature I plan to zip into CMD this evening is sending
output to a register to indicate whether an input line was entered.
If this is done, ZEX could be run on top of the new SHSET shell:

        SHSET CMD;IF 9 0;WS;FI

would establish the new shell to be:

        CMD - input a command line from the user and run it in
            place of CMD in the above script
            (if the command line was empty, set reg 9 to
            0, else set reg 9 to 1)
        IF 9 0;WS;FI - if reg 9 = 0, run WS (no command was
            input, so run WS)
        go back and run CMD again after WS exits or the
            command line is finished

    If ZEX was running, ZEX would see the prompt and provide
input.  The line would be non-empty, so reg 9 = 1, we run the line,
and then run CMD again.  If ZEX was not running, the user could either
input his own line (to be run immediately) or strike return (to enter
WS).

    Of course, in the above example, WS could be anything, such as
DBASE II, if the user desired [this capability has no limitation that
I can see].

    Note that all of this was done without any modification to the
ZCPR3 CP (as would have to have been done with ZCPR2).  All that was
needed were two little 1K COM files.  The concept of CMD is still
firming up, but this is the idea (altho I may use the ERROR message
instead of Reg 9 - have not decided yet).  SHSET and CMD are basically
running now.  Also note that standard ZCPR3 shells, such as VFILER,
already allow ZEX to run on top of them and the user can issue any
command line he wishes from within the shell (VFILER has a Z command
which prompts for command line, stores it, and exits, allowing the
command to run and VFILER be reinvoked when the ZCPR3 CP decides to
run the shell at the top of the shell stack).

    Comments?

        Rick
20-Jul-84 10:48:10-MDT,909;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 20 Jul 84 10:47:57-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  20 Jul 84 11:08 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  20 Jul 84 9:59 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 20 Jul 84 6:42-PDT
Date: 19 Jul 84 14:54:14-PDT (Thu)
To: [e-mail]
From: hplabs!sdcrdcf!sdcsvax!sdccs6![e-mail]
Subject: How much is the M80/LN80/LIB80 system?
Article-I.D.: sdccs6.1634

How much can one pick up the M80 system for?  I can't seem to find
any ads still selling it.  I have heard it is THE 8080/Z80 assembly
language tool.  If you know of a place that sells it at a reasonable
or better price, I'd appreciate knowing about it too.

             John Antypas
            UC San Diego

        UUCP- ...!sdcsvax!sdccs6!ir320
        arpa: sdcsvax!sdccs6!ir320@Berkeley
20-Jul-84 11:17:16-MDT,954;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 20 Jul 84 11:17:08-MDT
Date:     Fri, 20 Jul 84 12:12:49 EDT
From:     Dave Towson (info-cpm) <[e-mail]>
To:       [e-mail]
Subject:  Info request: Radio Shack Model 100

Can anyone help with this request?



----- Forwarded message # 1:

Received: From usc-isi.arpa.ARPA by AMSAA via smtp;  19 Jul 84 10:30 EDT
Date: 19 Jul 1984 10:30:57 EDT
Subject: Radio Shack Model 100
From: Paul W. Sparks <[e-mail]>
To: [e-mail]
cc: [e-mail]

I am in great need of the ROM Map for Radio Shack's Model 100 "Lapper".
My task is to install (if possible) MEX,MDM or KERMIT in the thing.  My
wildest hope is for the whole ROM Map, but I really need only the4 I/O
addresses.
                                TNX Paul W. Sparks (PSPARKS@ISIA)
-------

----- End of forwarded messages
20-Jul-84 11:46:18-MDT,2011;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 20 Jul 84 11:46:09-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  20 Jul 84 12:52 EDT
Received: From xerox.arpa.ARPA by BRL-AOS via smtp;  20 Jul 84 12:44 EDT
Received: from Muscat.ms by ArpaGateway.ms ; 20 JUL 84 09:43:25 PDT
Date: Fri, 20 Jul 84 12:41 EDT
From: [e-mail]
Subject: Re: C Compiler for CP/M-80?
In-reply-to: "ihnp4!ihuxk![e-mail]'s message of 16 Jul 84
 5:04:14 PDT (Mon)"
To: ihnp4!ihuxk![e-mail]
cc: [e-mail]

Dave,

I've used BDS C and Aztec C on a Xerox 820 (I've also used Whitesmith's
C and Small C).  BDS C is lightening fast to compile, seems to produce
reasonably efficient code but I don't trust it (I once developed a
program on another C compiler and ported it over to CP/M and BDS made me
crazy).  I'd recommend it for doing developed on the compiler but don't
trust it for portable code.  Friends of mine have told me it misses some
obvious errors.  It also is a limited implementation (i.e.  cannot
define static arrays with data at allocation time).

Aztec seems to be the best of all worlds -- reasonably fast compiles,
reasonably efficient code, Unix compatibility.  The only complaint I
have with Aztec is their library source is generally uncommented
(especially the assembly language written stuff).

Whitesmiths is a product I cannot say a good word about.  It's
expensive, it takes forever to compile, it takes up enormous amounts of
space (I think printf("Hello world" is 18 k of 8080 object code), the
older versions I/O is not Unix compatible and the documentation is
unreadable.  Stay away from it by all means unless newer versions are
different than the one I'm using.

All in all, Aztec is very recommended as being Unix compatible.  BDS is
recommended with a grain of salt, but it is great for hacking out one
day programs since it compiles so fast.

Hope I've helped.

Marty.

22-Jul-84 17:23:07-MDT,920;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 22 Jul 84 17:23:02-MDT
Received: From xerox.arpa.ARPA by AMSAA via smtp;  22 Jul 84 18:58 EDT
Received: from Gamay.ms by ArpaGateway.ms ; 22 JUL 84 15:59:29 PDT
From: [e-mail]
Date: 22 Jul 84 15:59:29 PDT
Subject: ZCPR3 BBS
To: [e-mail]

There is aa ZCPR3 BBS system now running in El Segundo Calif., on
a Xerox 820-II. This is a FULL ZCPR3 implementation. All files are on
line for downloading. There is also an LBR file with installation notes
for the Xerox 820-II called Z3XEROX.LBR. The number is : [phone].
*** Hours: 1700-0730 PDT On Weekdays, 24 hours on weekends. Please
don't call at any other time! The system runs at 300/1200 baud, also
with a 10mb rigid. The RBBS4 bulletin board is available for
messages.
            -Isaac Salzman
            (SYSOP of Xerox Customer Ed. RBBS)
22-Jul-84 23:43:53-MDT,854;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 22 Jul 84 23:43:49-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  23 Jul 84 1:16 EDT
Received: From sumex-aim.arpa.ARPA by BRL-AOS via smtp;  23 Jul 84 1:09 EDT
Date: Sun 22 Jul 84 22:08:37-PDT
From: Leslie Zatz <[e-mail]>
Subject: MDM PROBLEM
To: [e-mail]

I am using MDM711 with a 2 MHz machine. Works fine at
300 baud but at 1200 baud I lose the first ffew letters of
each line. Probably due to the slowness of my machine in
scrolling. In a communication program I wrote for 1200 baud
I had to use xoff at end of each line while I wrapped
around and then xon to restart. (Problem not only due to
slowness in scrolling but also in wraparound at end of
each line).

Is there a way to get around  this?
-------
23-Jul-84 21:35:44-MDT,572;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 23 Jul 84 21:35:40-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  23 Jul 84 23:07 EDT
Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp;  23 Jul 84 22:59 EDT
Date: Mon, 23 Jul 84 22:54:11 EDT
From: Manny Crivello <[e-mail]>
Subject: help cpm .com to .hex
To: [e-mail]

What I need is a program that will run under unix and that will convert
cpm .com files to .hex files.

thank you for any help that you can give.
M.D.Crivello


24-Jul-84 05:07:39-MDT,2518;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 24 Jul 84 05:07:30-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  24 Jul 84 6:36 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  24 Jul 84 6:35 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 24 Jul 84 3:28-PDT
Date: 18 Jul 84 2:53:47-PDT (Wed)
To: [e-mail]
From: decvax!decwrl!amd!fortune!foros1![e-mail]
Subject: Re: C Compiler for CP/M-80?
Article-I.D.: foros1.242
In-Reply-To: Article <[e-mail]>

Hi.  I've been using C/80 (version 3.1, under CP/M) for a while, so
I guess I'll toss out a few comments.

Language:
    more or less full K&R, with some documented restrictions:
    no typedefs, no longs or floats (unless you get MATHPAK),
    no bit fields, no parameterized macros, no #line, no declarations
    within nested blocks.

    Big complaint number one: no parameterized macros.  This
    turns out to be more useful than I thought it would be.

    It also has an undocumented restriction: structures can't
    contain pointers to structures which haven't been declared
    yet.

Library:
    Incomplete.  It doesn't even have <stdio.h>!!!!!!  If you want
    to use "stdin", you have to declare it yourself.  No open() or
    close(), read() and write() can only do multiples of 128 bytes,
    no lseek() unless you buy MATHPAK (not sure if you get it then,
    but it would be easy to write).

    Big complaint number two: because of the order which
    subroutine arguments are pushed onto the stack (leftmost
    first), routines which get passed multiple parameters
    are implemented with a "kluge" (their word) which involves
    #defines to call TWO routines, one of which saves information
    about the top of the stack, for the other.  This affects
    every routine which calls printf, for instance.

Quality of compiler and code produced:
    No complaints.  I haven't run anything big enough to get
    a feel for how fast or how large the generated code is.

Overall impression:
    Still a bargain for $50.  What this compiler really needs
    are (1) a full preprocessor (which there are a couple of
    public domain implementations in the works), and (2) and
    complete runtime library (which is also in the works,
    although it looks like it won't be public domain).

I hope this helps.  If you have any questions or whatever, just drop
me a line.

                See ya!
--
                JR (John Rogers)
                ...ihnp4!fortune!foros1!jr
                also fortune!jr and proper!jr
24-Jul-84 06:18:31-MDT,1257;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 24 Jul 84 06:18:24-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  24 Jul 84 7:51 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  24 Jul 84 7:46 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 24 Jul 84 4:45-PDT
Date: 22 Jul 84 5:59:47-PDT (Sun)
To: [e-mail]
From:  hplabs!hao!seismo!harvard!wjh12!genrad!grkermit!masscomp!bonnie!clyde!watmath!utzoo!utcsrgv!utai![e-mail]
Subject: MP/M-86
Article-I.D.: utai.191

I would like to communicate (speak) to anyone out there who has done
any system programming with the MP/M-86 operating system.
I am trying to customize an existing system (add a new Tmp, etc.) and
am having a lot of trouble with DRI's documentation (?).

Thanks in advance.


 Martin Stanley
 Department of Computer Science
 University of Toronto
 Toronto, ON
 M5S 1A4

 {cornell,decvax,ihnp4,linus,utzoo,uw-beaver}!utcsrgv!utai!mts

 Phone:
    [phone] (home)
    [phone] (daytime, sometimes)
--

 Martin Stanley
 Department of Computer Science
 University of Toronto
 Toronto, ON
 M5S 1A4

 {cornell,decvax,ihnp4,linus,utzoo,uw-beaver}!utcsrgv!utai!mts
24-Jul-84 06:49:39-MDT,823;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 24 Jul 84 06:49:35-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  24 Jul 84 8:19 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  24 Jul 84 8:16 EDT
Date: 24 Jul 1984  06:16 MDT (Tue)
Message-ID: <RCONN.12033854315.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   Manny Crivello <[e-mail]>
Cc:   [e-mail]
Subject: help cpm .com to .hex
In-reply-to: Msg of 23 Jul 1984  20:54-MDT from Manny Crivello <crivello at BBNCCC.ARPA>


    MICRO:<UNIX.CPM> contains what you are looking for.  COMHEX.C
and COMHEX.MAN.  COMHEX accepts a COM file as input and generates an
Intel HEX file as output.  It can be used as a filter.

    The archive is on SIMTEL20.

        Rick
24-Jul-84 14:27:46-MDT,567;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 24 Jul 84 14:27:42-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  24 Jul 84 15:33 EDT
Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp;  24 Jul 84 15:27 EDT
Date: Tue 24 Jul 84 14:43:15-EDT
From: [e-mail]
Subject: Custon OpSys
To: [e-mail]


Is it possible to write a "custom operating system" in BASIC?
(could I put it on the system tracks like ZCPR?)

                    Andrew Moore

                    MLY.G.DRU@MIT-OZ

-------

24-Jul-84 20:22:25-MDT,806;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 24 Jul 84 20:22:21-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  24 Jul 84 21:55 EDT
Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp;  24 Jul 84 21:51 EDT
Date: 24 Jul 1984 20:52:33 EDT (Tuesday)
From: Marshall Abrams <[e-mail]>
Subject: Retirement planning programs
To: [e-mail], [e-mail],
    [e-mail], [e-mail], [e-mail]
Cc: [e-mail]

Has anyone heard of retirement planning programs? I would be especially
interested in those in the public domain in BASIC, but would like to
learn about any products on the market. My brief survey hasn't turned up
any.

Thanks,
Marshall Abrams


24-Jul-84 23:14:02-MDT,579;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 24 Jul 84 23:13:58-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  25 Jul 84 0:50 EDT
Received: From usc-eclb.arpa.ARPA by BRL-AOS via smtp;  25 Jul 84 0:48 EDT
Date: Tue 24 Jul 84 21:48:38-PDT
From: Dick <[e-mail]>
Subject: NSWP207 bug?
To: [e-mail]

I recently received NSWP207 on my system from a user. I have found
that the SQ/USQ function no longer works on any of my systems, while
it worked fine with version 205 of NSWP.
..Dick..
-------
25-Jul-84 00:34:08-MDT,1639;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 00:34:00-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  25 Jul 84 2:04 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  25 Jul 84 1:55 EDT
Date: 24 Jul 1984  23:55 MDT (Tue)
Message-ID: <RCONN.12034047184.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Cc:   [e-mail]
Subject: SHSET
In-reply-to: Msg of 24 Jul 1984  12:08-MDT from Chapman.ES at XEROX.ARPA

Cheryl,

    Yes, what they are describing can be done under ZCPR3 quite
easily.  In a sense, it has already been done.  ZCPR3 has a facility
which I call Error Handlers.  These programs are invoked when an error
in the command line occurs.  The ZCPR3 CP leaves a message to its
Error Handler which points to the command in error.  The Error Handler
can then do whatever it wishes.

    There are currently five different Error Handlers with ZCPR3.
Two of them display the command line which was in error and the rest
of the commands on the multiple command line buffer.  They then give
the user the option of reentering the erroneous command, advancing to
the next command, entering a whole new command string, or flushing the
entire command string.  This does what the UNIX people were talking
about, but, rather than advancing to the next command being automatic,
the user has to manually choose to do so.  It would not hurt to create
another Error Handler which just skips to the next command.  I will
log your message and do so if I have the time.  Thanks for the input.

    Rick
25-Jul-84 00:36:47-MDT,1445;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 00:36:42-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  25 Jul 84 2:04 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  25 Jul 84 2:03 EDT
Date: 25 Jul 1984  00:03 MDT (Wed)
Message-ID: <RCONN.12034048547.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Cc:   [e-mail]
Subject: Custon OpSys
In-reply-to: Msg of 24 Jul 1984  12:43-MDT from MLY.G.DRU%MIT-OZ at MIT-MC.ARPA

    In a word, nothing is impossible given the time.  I see two
immediate problems with writing an opsys in BASIC:  (1) you would have
to org the absolute binary to the CCP location or modify the cold boot
routine to load the binary at its execution address and (2) you would
have to restrict the use of the run-time library as much as possible
if you want to store the opsys on the system tracks.

    In the ZCPR3 environ, if you want to have a BASIC application
act as your front-end (shell), then it can be done quite easily with
SHSET.  Just give the command "SHSET MBASIC MYSHELL" and MBASIC
MYSHELL will always be running.  You may be able to use POKE to store
a command for ZCPR3 to run in the command line buffer and then exit
the MBASIC, at which time the command in the buffer wll run and MBASIC
MYSHELL will be reexecuted.  If this is what you want ...

        Rick
25-Jul-84 00:58:14-MDT,730;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 00:58:10-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  25 Jul 84 2:25 EDT
Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp;  25 Jul 84 2:26 EDT
Date: 25 July 1984 02:23-EDT
From: Stephen C. Hill <[e-mail]>
Subject:  Wordstar 3.3 patching?
To: [e-mail]
cc: [e-mail]
In-reply-to: Msg of 21 Jul 1984  19:17 MDT (Sat) from CSTROM at Simtel20.ARPA

Our system uses a spooler as an intermediary, but WordStar still seems to take
the same time as if it actually printed on a 1200 bps printer.  Do you know
of any way to speed things up?  We have W* 3.3 running on a Z-80.

25-Jul-84 02:47:50-MDT,752;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 02:47:46-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  25 Jul 84 4:23 EDT
Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp;  25 Jul 84 4:15 EDT
Date: 25 July 1984 04:04-EDT
From: Jerry E. Pournelle <[e-mail]>
Subject:  Wordstar 3.3 patching?
To: [e-mail]
cc: [e-mail], [e-mail]
In-reply-to: Msg of 25 Jul 1984 02:23-EDT from Stephen C. Hill <STEVEH at Mit-Mc.ARPA>

WordStar takes so long, and uses such inefficient algorithms,
for formatting text that adding a large print buffer does almost
no good at all.  The problems is not in your philosophy but in
your [Word]Stars...

25-Jul-84 05:34:35-MDT,1530;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 05:34:27-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  25 Jul 84 7:02 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  25 Jul 84 6:59 EDT
Date: 25 Jul 1984  04:59 MDT (Wed)
Message-ID: <CSTROM.12034102517.BABYL@SIMTEL20>
From: [e-mail]
To:   "Stephen C. Hill" <[e-mail]>
Cc:   [e-mail], [e-mail]
Subject: Wordstar 3.3 patching?
In-reply-to: Msg of 25 Jul 1984  00:23-MDT from Stephen C. Hill <STEVEH at MIT-MC>


I assume that you are outputting the data to the spooler quite a bit
faster than 1200 baud, correct? Unfortunately, WS has a nasty habit of
sending the character stream out the printer port at a very slow rate.
I assume that at least part of the delay is due to processing for the
target printer, but I would not be a bit surprised if there was some
delay built in as well, allowing effective simultaneous editing while
printing without hogging the resources of the CPU.

I think you would find that the actual effective output is faster than
1200 baud; on systems with buffers and 1200 baud printers, the buffer
does indeed fill, but certainly the effective baud rate is probably
more on the order of 2400 baud or thereabouts (a seat of the pants
guess). I will try to get some info on this out of my friends at
MicroPro, but things seem to get more screwed up there every day, so
don't expect much from that quarter.
25-Jul-84 05:58:09-MDT,830;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 05:58:05-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  25 Jul 84 7:35 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  25 Jul 84 7:26 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 25 Jul 84 4:18-PDT
Date: 24 Jul 84 9:52:07-PDT (Tue)
To: [e-mail]
From: hplabs!tektronix!orca!iddic![e-mail]
Subject: C features
Article-I.D.: iddic.1766

I appreciated the opinions from Marty about the different C's he has used -

how about features?  I have heard that BDS has floating point numbers,

but they are implemented as strings.  Does not sound good.  Does Aztec

support float (and double)?



                        Thanks,

                        Rick Coates
                        tektronix!iddic!rickc
25-Jul-84 06:59:29-MDT,2054;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 06:59:17-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  25 Jul 84 8:31 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  25 Jul 84 8:25 EDT
Date: 25 Jul 1984  06:16 MDT (Wed)
Message-ID: <RCONN.12034116464.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Subject: [Penny.Anderson: LRUN as CMDRUN question]

FYI -- I thought you might like to know about this. -- Rick


Date: Wednesday, 25 July 1984  03:56-MDT
From: Penny Anderson <Penny.Anderson at CMU-CS-C.ARPA>
To:   RCONN at SIMTEL20.ARPA
cc:   APA at CMU-CS-C.ARPA
Re:   LRUN as CMDRUN question

Rick,
    First, kudos: Z3 came right up just like your doc said it would!
We ran Z2 for about 8 months and it was wonderful.  This is as much of an
improvement over Z2 as Z2 was over 8080 cp/m.  Thank you (if this was speech
instead of typing, that would be in the sincerest tone I could muster)!!

    Second, a question: is there going to be an LRUNZ for Z3?  I
re-GENINSed my Z2 LRUNZ to use as my CMDRUN, however if LRUNZ doesn't
find the .COM file, Z3 doesn't know, so my ERRORn is avoided even though
it's a perfect job for it.

    A LRUN that can set the Message Buffer error flag (isn't that how
it works?) would allow the Error handler to catch it.

    Did I miss something?

    Another suggestion: I was surprised there was no SAK option in the
SYSRCP.LIB.  Even a stripped down version with no bells and such would
be nice.  I hate sacrificing the disk and directory space for such a simple
function.

    For your statistics:  We run a N* Horizon with 2 5in floppies and
LifeBoat CP/M, TeleVideo 950 (lucky for me when using your stuff), Centronics
739 printer on parallel, and USR Password with MEX and YAM.

    Congratulations on another wonderful (and large) piece of work and
thanks again for giving it away.  Looking forward to the books.

        Don Shields
    c/o Penny Anderson
    [e-mail]
25-Jul-84 07:11:32-MDT,1309;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 07:11:25-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  25 Jul 84 8:31 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  25 Jul 84 8:25 EDT
Date: 25 Jul 1984  06:14 MDT (Wed)
Message-ID: <RCONN.12034116176.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   Penny Anderson <[e-mail]>
Cc:   [e-mail]
Subject: LRUN as CMDRUN question
In-reply-to: Msg of 25 Jul 1984  03:56-MDT from Penny Anderson <Penny.Anderson at CMU-CS-C.ARPA>

Thank you for your message, Penny.  Phase 2 of ZCPR3 is yet to come
out, and I have a number of things planned.  One is LRUNZ.  Phase 2 is
still forming (altho not for very long now because my book deadline is
coming up and I want the book to include everything), so any
last-minute suggestions that anyone has are welcome, but I can't
guarantee that they will make it in.

Also, FYI, I got a report on beta-test efforts for a part of the Phase
2 software.  The only problem reported so far is that VFILER and VMENU
(the VFILER/MENU shell) interact strangely from time to time when
VFILER runs under VMENU.  VFILER tends to cancel VMENU.  Will have to
fix this one before release.

    Rick
25-Jul-84 07:34:59-MDT,1060;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 07:34:52-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  25 Jul 84 8:56 EDT
Date: 25 Jul 1984  06:58 MDT (Wed)
Message-ID: <KPETERSEN.12034124189.BABYL@SIMTEL20>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: UNERA20 unerase utility now available

The popular utility UNERA has been updated to version 2.0.  Users with
deblocking CBIOSs will want to get this new version, which corrects a
problem with not restoring files whose names were in the last sector
used in the directory.  The files are now available on SIMTEL20.
Here's a list:

Filename            Type     Bytes     Sectors     CRC

Directory MICRO:<CPM.DIRUTL>
UNERA20.ASM.1            ASCII     17261  135 =  87H  54C6H
UNERA20.COM.1            COM      1408   11 =   BH  29E4H
UNERA20.DOC.1            ASCII      4760   38 =  26H  0E8CH
UNERA20.HEX.1            ASCII      3440   27 =  1BH  D801H
UNERA20.HLP.1            ASCII      4796   38 =  26H  EFD0H

--Keith
25-Jul-84 13:11:08-MDT,992;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 13:10:58-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  25 Jul 84 14:28 EDT
Received: From mit-mc.arpa.ARPA by BRL-AOS via smtp;  25 Jul 84 14:29 EDT
Received: from MIT-MC by MIT-OZ via Chaosnet; 25 Jul 84 14:28-EDT
Received: from Concord.ms by ArpaGateway.ms ; 25 JUL 84 11:27:09 PDT
Date: 25 Jul 84 10:17:53 PDT (Wednesday)
From: [e-mail]
Subject: Re: Custon OpSys
In-reply-to: MLY.G.DRU%MIT-OZ's message of Tue, 24 Jul 84 14:43:15 EDT
To: [e-mail]
cc: [e-mail]

I presume that it is possible to write a "custom operating system" in BASIC,
but WHY BASIC? Do you like pain?

    Jack Bicer

P.S: It'll probably be easier to boot CP/M first and (maybe automatically) load
your operating system. If you really need it, you could write your cold start
sequence and load anything you want from anywhere you want.

25-Jul-84 20:59:40-MDT,1280;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 25 Jul 84 20:59:35-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  25 Jul 84 22:39 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  25 Jul 84 22:39 EDT
Date: 25 Jul 1984  20:37 MDT (Wed)
Message-ID: <RCONN.12034273269.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   William C. Wells <[e-mail]>
Cc:   [e-mail]
Subject: ZCPR3 and CP/M 3.0
In-reply-to: Msg of 25 Jul 1984  12:03-MDT from wcwells%ucbopal.CC at Berkeley (William C. Wells)

Yes, ZCPR3, SYSLIB3, Z3LIB, and VLIB all run under CP/M 2.2.  Due to
their direct BIOS calls, they will not run under CP/M 3.0.  Some
degree of modification to the low-level device drivers is required in
order to get the libraries to be useful under CP/M 3.0.

ZCPR3, however, is another problem, since, as a command processor, it
directly loads the COM files it selects, a knowledge of your
bank-switched environment is required.  I suspect that the degree of
modification to get ZCPR3 to run under CP/M 3.0 would be extensive.

Re the files on SIMTEL20 that you referenced, I am not familiar with
them.  I am not moving toward the CP/M 3.0 world.

    Rick
26-Jul-84 07:50:56-MDT,1172;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 26 Jul 84 07:50:50-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  26 Jul 84 9:13 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  26 Jul 84 9:09 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 26 Jul 84 6:00-PDT
Date: 25 Jul 84 8:25:41-PDT (Wed)
To: [e-mail]
From: hplabs!sdcrdcf!sdcsvax!sdccs6!loral![e-mail]
Subject: Epson QX-10 serial port question
Article-I.D.: loral.297

[Do not write in this space]

I am seeking to implement MODEM7 on an Epson QX-10.  So far I have
not seen any reference to the serial port in the documentation other
than an acknowledgement of its existence.  I'd like to know the following:

1: What physical device(s) is the serial port in the CP/M environment?
2: Is the port configured as DTE or DCE?
3: What modem control lines are needed to use it, if any?
4: Port addresses, UART/ACIA/whatever type, and I/O or memory mapped?

Any of this info would be appreciated.
--
Ray Simard
Loral Instrumentation, San Diego
{ucbvax, ittvax!dcdwest}!sdcsvax!sdccsu3!loral!simard
26-Jul-84 08:28:21-MDT,860;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 26 Jul 84 08:28:16-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  26 Jul 84 9:45 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  26 Jul 84 9:46 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 26 Jul 84 6:41-PDT
Date: 24 Jul 84 5:28:13-PDT (Tue)
To: [e-mail]
From: hplabs!sdcrdcf!sdcsvax!akgua!mcnc!ecsvax![e-mail]
Subject: mdm7xx overlay for Toshiba T100 wanted
Article-I.D.: ecsvax.2984

Does anyone have an overlay for a Toshiba T100 CP/M system to go
with the Modem 7xx series programs. I would appreciate it greatly if
anyone could give me a lead or better yet mail me a copy of the
overlay if it exists.

Thanks,
               Mike Gingell, Raleigh NC

             ...decvax!mcnc!ecsvax!mjg
26-Jul-84 21:19:08-MDT,3251;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 26 Jul 84 21:18:58-MDT
Received: From ucb-vax.arpa.ARPA by AMSAA via smtp;  26 Jul 84 22:11 EDT
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.33)
    id AA02089; Thu, 26 Jul 84 19:11:08 pdt
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
    by ucbjade.CC.Berkeley.ARPA (4.14/4.23.1)
    id AA05143; Thu, 26 Jul 84 19:12:24 pdt
Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.23.1)
    id AA01732; Thu, 26 Jul 84 19:12:23 pdt
Date: Thu, 26 Jul 84 19:12:23 pdt
From: William C. Wells <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: ZCPR3 and CP/M 3.0
Cc: [e-mail]

Richard,

In reply to:

    Date: 25 Jul 1984  20:37 MDT (Wed)
    Message-Id: <RCONN.12034273269.BABYL@SIMTEL20>
    From: Richard Conn <RCONN@SIMTEL20>
    To: wcwells@ucbopal (William C. Wells)
    Cc: info-cpm@brl
    Subject: ZCPR3 and CP/M 3.0
    In-Reply-To: Msg of 25 Jul 1984  12:03-MDT
        from wcwells%ucbopal.CC at Berkeley (William C. Wells)

    Yes, ZCPR3, SYSLIB3, Z3LIB, and VLIB all run under CP/M 2.2.
    Due to their direct BIOS calls, they will not run under CP/M
    3.0.  Some degree of modification to the low-level device
    drivers is required in order to get the libraries to be useful
    under CP/M 3.0.

    ZCPR3, however, is another problem, since, as a command
    processor, it directly loads the COM files it selects, a
    knowledge of your bank-switched environment is required.  I
    suspect that the degree of modification to get ZCPR3 to run
    under CP/M 3.0 would be extensive.

    Re the files on SIMTEL20 that you referenced, I am not familiar
    with them.  I am not moving toward the CP/M 3.0 world.

        Rick

The files, I referred to on SIMTEL20 are:

Filename            Type     Bytes     Sectors     CRC

Directory MICRO:<CPM.CPM3>
BIOS2RSX.ASM.1            ASCII     11748   92 =  5CH  D10BH
BIOS2RSX.RSX.1            COM      1536   12 =   CH  7218H

The BIOS2RSX.ASM is the source for BIOS2RSX.RSX and is a copy
of the CP/M Exchange Listing in Dr. Dobb's Journal, July 1984,
starting at page 23.

BIOS2RSX.ASM, to quote the author, Mike Griswold of Fort Worth,
Texas:

       ... will provide CP/M 2.2 compatible BIOS support
       for CP/M 3.x.  Primarily it performs logical sector
       blocking and deblocking needed for some programs.
       All actual I/O is done by the CP/M 3.0 BIOS.

How Resident System Extensions (RSX) may be used is discussed in
an article by Garry M. Silvey in the same issue of Dr. Dobb's Journal
starting at page 36.

Robert Blum, on page 22, stated that he attached the RSX to a CP/M
2.2 version of DU, and that it worked perfectly. Thus it appears
that BIOS2RSX.RSX when attached to a COM file using GENCOM, will
intercept the 2.2 I/O calls and convert them to 3.0 I/O calls.
If this is true for all I/O calls, then it should be possible
to assemble CP/M 2.2 programs that use members of  SYSLIB3, Z3LIB,
and VLIB, attach BIOS2RSX.RSX and have a program that works under
CP/M 3.0.

I suspect you are right about ZCPR3.

Bill Wells
[e-mail]
ucbvax!wcwells
[e-mail]
27-Jul-84 09:02:43-MDT,821;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 27 Jul 84 09:02:39-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  27 Jul 84 10:03 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  27 Jul 84 9:56 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 27 Jul 84 6:48-PDT
Date: 26 Jul 84 9:50:16-PDT (Thu)
To: [e-mail]
From: hplabs!sdcrdcf!sdcsvax!sdccs6!loral![e-mail]
Subject: How to you access SIMEL20?
Article-I.D.: loral.317

[Do not write in this space]

I've seen many references to CP/M programs residing in something
called SIMTEL20 (or SIMEL20).  How do users access this library?

Thanks for any help.
--
Ray Simard
Loral Instrumentation, San Diego
{ucbvax, ittvax!dcdwest}!sdcsvax!sdccsu3!loral!simard
27-Jul-84 10:20:37-MDT,910;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 27 Jul 84 10:20:30-MDT
Received: From brl-vgr.arpa.ARPA by AMSAA via smtp;  27 Jul 84 11:18 EDT
Received: from hi-multics.arpa by BRL-VGR.ARPA id a005902; 27 Jul 84 11:13 EDT
Date:  Fri, 27 Jul 84 10:10 CDT
From:  "David S. Cargo" <[e-mail]>
Subject:  ? ASM S error flag
To:  [e-mail]
Message-ID:  <[e-mail]>

While trying to bring up KERMIT v3.9A I discovered two things.  ASM does
NOT object to an ASEG declaration after the ORG 100H.  I expected that
it would, but it didn't.  On some code it generated an S error flag for
the line, but none of the DRI documentation for ASM indicates what the S
error flag means.  Are there other undocumented features in ASM?  What
does S mean in this context?

....  David S.  Cargo (Cargo at HI-Multics)
27-Jul-84 13:23:57-MDT,1984;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 27 Jul 84 13:23:44-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  27 Jul 84 13:00 EDT
Received: From xerox.arpa.ARPA by BRL-AOS via smtp;  27 Jul 84 13:01 EDT
Received: from Concord.ms by ArpaGateway.ms ; 27 JUL 84 09:57:38 PDT
Date: 27 Jul 84 09:48:41 PDT (Friday)
From: [e-mail]
Subject: Re: C features
In-reply-to: hplabs!tektronix!orca!iddic!rickc's message of 24 Jul 84
 9:52:07 PDT (Tue)
To: hplabs!tektronix!orca!iddic![e-mail]
cc: [e-mail]


Here is a quick chart of CP/M C compilers:

Version        Small    Smallc+    Q/C    C80    Super-    BDS C    AZTEC
        C v1                soft

------------------------------------------------------------------------------
Operators    most    most    all    all    all    all    all
Arrays        oned    oned    oned    nd    nd    nd    nd
Datatypes
  char        y    y    y    y    y    y    y
  int        y    y    y    y    y    y    y
  short        n    n    y    n    n    n    ?
  unsigned    n    n    n    y    y    y    y
  pointer    y    y    y    y    y    y    y
  long        n    n    n    n    n    n    y
  float,double    n    n    n    n    n    n    y
  extern    n    n    y    y    y    y    y
  static    n    n    y    y    n    n    y
  register    n    n    n    static    static    static    y***
structure    n    n    n    y    y    y    y
union        n    n    n    n    n    y    y
intialize    n    n    y    y    n    n    y
casts        n    n    n    n    ?    n    y
program
  control    most    all    all    all    all    all    all
#define        y    y    y    y    y    y    y
#define f(x)    n    n    n    n    ?    y    y
#include    y*    y*    y    y    y    y    y
#ifdef/ifndef    n    n    y    y    y    y    y
#if/else/endif    n    n    y    y    y    y    y
#asm/endasm    y    y    y    y    y    n    ?
Output
   asm/mac    y    n    y    y    y    n    asm**
   m80/l80    n    y    y    y    y    n    y
   object    n    n    n    n    n    y    n
Source?        y    y    y    n    n    n    n
Price:        (free)  $24    $95    $50    $200    $150    $199

* Includes can not nest (and in some versions have funny syntax.)
** Assembler/linker supplied.
*** Even on an 8080, Aztec C puts the first "register" declaration in
register pair BC.  On a Z80, the first three go to BC, IX, and IY.
However, when the function is not recursive you win by *not* using
IX and IY registers instead of explicit "static"s. (tekecs!andrew)

27-Jul-84 15:47:11-MDT,1457;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 27 Jul 84 15:47:01-MDT
Received: From brl-vgr.arpa.ARPA by AMSAA via smtp;  27 Jul 84 17:09 EDT
Received: from usc-isid.arpa by BRL-VGR.ARPA id a014091; 27 Jul 84 17:01 EDT
Date: 27 Jul 1984 16:59-EDT
Sender: [e-mail]
Subject: Re:  ? ASM S error flag
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Message-ID: <[USC-ISID.ARPA]27-Jul-84 16:59:41.ABN.ISCAMS>
In-Reply-To:  <[e-mail]>

David,

Appears the S error flag in ASM is harmless - I use it all the time to
put little messages to the user within code so it will say things while
assembling.  Never appears in the final assembled code at all.

I make it a habit to comment out ASEGs and other stuff unique to other
assemblers (juuuust in case...), but you're right - sometimes ASM yelps
and sometimes it doesn't.  Weird.

I suggest you look at the Public Domain linking assembler LASM.COM (available
via Anonymous FTP from SIMTEL20 micro:<CPM.ASMUTL>LASM2.ASM (I believe).
Faster than ASM, same rules apply, PLUS you can link segments together in the
simplest fashion!  I'm using it right now to link together a bunch of
segments for KERMIT 4.0 (test), and works just fine and fast.  You can also
get a symbol file out of the thing too.

Regards,
David Kirschbaum
Toad Hall (ABN.ISCAMS@USC-ISID)
27-Jul-84 19:24:47-MDT,1905;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 27 Jul 84 19:24:37-MDT
Received: From ucb-vax.arpa.ARPA by AMSAA via smtp;  27 Jul 84 20:32 EDT
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.33)
    id AA02124; Fri, 27 Jul 84 17:32:30 pdt
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
    by ucbjade.CC.Berkeley.ARPA (4.14/4.23.2)
    id AA04542; Fri, 27 Jul 84 17:34:17 pdt
Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.23.2)
    id AA13910; Fri, 27 Jul 84 17:33:04 pdt
Date: Fri, 27 Jul 84 17:33:04 pdt
From: William C. Wells <[e-mail]>
Message-Id: <[e-mail]>
To: sdcsvax!sdccs6!loral![e-mail]
Subject: Re:  How to you access SIMEL20?
Cc: [e-mail]

In reply to:

    To: [e-mail]
    From: hplabs!sdcrdcf!sdcsvax!sdccs6!loral!simard@BERKELEY
    Subject: How to you access SIMEL20?
    Article-I.D.: loral.317

    [Do not write in this space]

    I've seen many references to CP/M programs residing in something
    called SIMTEL20 (or SIMEL20).  How do users access this library?

    Thanks for any help.
    --
    Ray Simard
    Loral Instrumentation, San Diego
    {ucbvax, ittvax!dcdwest}!sdcsvax!sdccsu3!loral!simard

Only users on the DOD Internet can access files on SIMTEL20, they
are not accessable from UUCP.  Some are posted to the USENET news
group "net.sources". Most of the files placed in the CP/M Library
are distributed to RCPM systems around the country. Some of the
files are copies of volumes distributed by SIG/M. Because SIMTEL20
is at the top of the RCPM distribution tree, you will often see
programs and other files announced on SIMTEL20 a month or so before
the files find there way out to local CP/M user group libraries.

Bill Wells
[e-mail]
[e-mail]
ucbvax!wcwells
27-Jul-84 22:42:08-MDT,1117;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 27 Jul 84 22:42:02-MDT
Date:     Fri, 27 Jul 84 22:52:02 EDT
From:     Dave Towson (info-cpm) <[e-mail]>
To:       [e-mail]
Subject:  [Bicer.ES:  Accounting Software - HELP!]

Can anyone help with this?  If so, please respond to Jack Bicer, not to me.


Dave


----- Forwarded message # 1:

Received: From xerox.arpa.ARPA by AMSAA via smtp;  25 Jul 84 20:07 EDT
Received: from Concord.ms by ArpaGateway.ms ; 25 JUL 84 17:00:08 PDT
Date: 25 Jul 84 10:41:49 PDT (Wednesday)
From: [e-mail]
Subject: Accounting Software - HELP!
To: XeroxInfo-CPM^[e-mail]
cc: [e-mail]
Reply-To: [e-mail]


Help!

I need some information about accounting software for CP/M. Currently
hoping that Accounting Partner form Star Software will fill the need.
Also, the Champion looked pretty good but expensive.

Every bit (or byte) of information will be greatly appreciated.

    Thanks in advance
    Jack Bicer

----- End of forwarded messages
28-Jul-84 02:22:17-MDT,2516;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 28 Jul 84 02:22:08-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  28 Jul 84 1:27 EDT
Date: 27 Jul 1984  23:29 MDT (Fri)
Message-ID: <WANCHO.12034828797.BABYL@SIMTEL20>
From: "Frank J. Wancho" <[e-mail]>
To:   "William C. Wells" <[e-mail]>
Cc:   [e-mail]
Subject: SIG/M distribution
In-reply-to: Msg of 27 Jul 1984  18:33-MDT from William C. Wells <wcwells%ucbopal.CC at Ucb-Vax.ARPA>

Bill,

I'm actually on the tail end of one of the three regional distribution
chains of SIG/M because I asked to be in that position.  I have been
travelling alot in recent months and thus cannot guarantee quick
turnaround to the next point if someone is behind me.

SIG/M is getting considerably better organized of late.  Almost every
month their Regional Coordinator sends out the three sets of updates
about a month before they are "officially" announced.  Thus, by the
time I get them, convert the disks, and have them uploaded, the
announcement is made, giving the appearance of being timely.

BTW, for those interested in such things, I had found an 8" disk
controller that behaves properly in my N*, called the MCP/FDC, from
MCP Computer Products.  It's only drawback is that it doesn't pass
through the two-sided disk signal from the 50-pin connector.
Otherwise, it's a clean, simple, and relatively inexpensive ($199)
board that doesn't require any mods.  Unfortunately, it was only on
loan, and is now sitting in another N* running TurboDOS...

I still have a semi sick DJDMA awaiting the new PROM set.  If that
doesn't fix the double-density-only problem, it goes back for repair.
There are two CCS2422 FDCs which still cause memory parity errors on
write, even after replacing my ancient 350ns RAM with 150ns RAM...
(that change seemed to cure the mpe's on read), and a CompuPro Disk 1
that hangs the system (and the factory could care less about their
boards in foreign machines as they are a System House now... so much
for the leader of IEEE-696 cards...)

A possible cure for my troubles is in the works: we are applying the
IEEE-696 upgrade mods to the N* CPU card (as published in the April
issue of Microsystems).  I'll let you all know the results of that.
(I may even end up believing the rumor that the N* motherboard is
noisy and splurge on an active termination card.)

Sorry for the core dump.

--Frank
28-Jul-84 02:47:21-MDT,1197;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 28 Jul 84 02:47:15-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  28 Jul 84 1:37 EDT
Date: 27 Jul 1984  23:39 MDT (Fri)
Message-ID: <WANCHO.12034830646.BABYL@SIMTEL20>
From: "Frank J. Wancho" <[e-mail]>
To:   "David S. Cargo" <[e-mail]>
Cc:   [e-mail]
Subject: ? ASM S error flag
In-reply-to: Msg of 27 Jul 1984  09:10-MDT from David S. Cargo <Cargo at HI-MULTICS.ARPA>

Dave,

The error code is documented in the MAC manual:

S - Syntax error: the fields of this statement are ill-formed and
cannot be processed properly; may be due to invalid characters or
delimiters which are out of place.

Both ASM and MAC share common roots, and, for some reason, this
description was left out of the ASM manual.

It usually means there is some invisible character in the line, such
as a NULL, and the fix is to delete the line and retype it.  Note that
it is possible for the line either before or after the flagged line to
actually have the offending character.  So, it may save some time to
simply retype all three lines...

--Frank
28-Jul-84 12:08:48-MDT,728;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 28 Jul 84 12:08:43-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  28 Jul 84 10:07 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  28 Jul 84 10:00 EDT
Date: 28 Jul 1984  07:57 MDT (Sat)
Message-ID: <RCONN.12034921427.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   William C. Wells <[e-mail]>
Cc:   [e-mail]
Subject: ZCPR3 and CP/M 3.0
In-reply-to: Msg of 26 Jul 1984  20:12-MDT from wcwells%ucbopal.CC at Berkeley (William C. Wells)

Good point ... I wasn't aware of it.  Thanks for the note.  Have you
tried doing this or do you intend to?

    Rick
29-Jul-84 06:08:54-MDT,642;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 29 Jul 84 06:08:51-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  29 Jul 84 7:41 EDT
Received: From sri-unix.arpa.ARPA by BRL-AOS via smtp;  29 Jul 84 7:36 EDT
Received: from Usenet.uucp by Sri-Unix.uucp with rs232; 29 Jul 84 4:28-PDT
Date: 27 Jul 84 18:39:06-PDT (Fri)
To: [e-mail]
From: decvax!ittvax!dcdwest!sdcsvax!sdccs6!loral![e-mail]
Subject: cmsg cancel <[e-mail]>
Article-I.D.: loral.324

--
Ray Simard
Loral Instrumentation, San Diego
{ucbvax, ittvax!dcdwest}!sdcsvax!sdccsu3!loral!simard
30-Jul-84 07:47:04-MDT,4546;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 30 Jul 84 07:46:50-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  30 Jul 84 8:46 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  30 Jul 84 8:44 EDT
Date: 30 Jul 1984  06:44 MDT (Mon)
Message-ID: <RCONN.12035432319.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Cc:   [e-mail]
Subject: ZCPR3 Phase 2 ...

... is coming along quite nicely.  It now includes DPROG, which stands
for Device PROGrammer.  Under ZCPR2, we had CONFIG and TINIT which
were nice for programming a TVI950.  Under ZCPR3, BOTH OF THESE are
replaced by one 3K interpreter called DPROG, and DPROG can program any
terminal or printer.

DPROG is a complete programming language in its own right.  You can
define words to it (a word is a symbol up to 16 characters long) which
contain any combination of output format control instructions and text
strings and references to other words (words can be nested up to 128
levels deep).  Once a word is defined, it can be named in an output
line, and its definition (including format controls) will be
translated and output to either your console, printer, or punch
device.  For example:

;
; Sample DPROG programming file
;

; Define Basic Words
-esc    (%c)    "\E"    ; the escape character
-ctrly        "^Y"    ; the character control-Y
-test    (Char: %c %x %d\n)    ; character test format
-normal_form    (%c)    ; normal single-character output format

;
; Use Words
;
"This is a test\n" test "ABC" normal_form "\nEnd of Test"


    The output from the execution of the output line will be:

This is a test
Char: A 41 65
Char: B 42 66
Char: C 43 67
End of Test


    Used in conjunction with both format definitions (where they
are output literally) and quoted strings (where they are output
according to the current format definition), the following escape
sequences apply:

        ^c    Define control character (2-char sequence)
        \b    Backspace char
        \d    Delete char (DEL)
        \e    Escape char (ESC)
        \l    Line Feed Char (LF)
        \n    New Line char (CRLF pair)
        \r    Carriage Return char (CR)
        \t    Tab char (TAB)
        \#    Numeric value (forms are \d for decimal, \dH
                for hex, \dq for octal, \dB for
                binary: \1, \245, \33h, \0feH, \111b,
                \77q, etc)

    Additionally, the format expression is of the form

        (<format text>)

where <format text> can contain any character sequence as well as
recognize the following output directives:

        %c    Output chars as ASCII characters
        %d    Output chars as floating decimal ASCII chars
        %x    Output chars as 2 hex ASCII chars
        %2    Output chars as 2 decimal ASCII chars
        %3    Output chars as 3 decimal ASCII chars

    Any text can surround these output directives, and each
directive can be used as many times as desired in a format expression.
Once a format expression is given, it is used until a new expression
is defined.  For example:

    (%x %d ) "\12\10hA" (%c) "\12\10hA"

will output:

    0C 12 10 16 41 65 ^L^PA

where ^L and ^P are the ASCII control-L and control-P characters.

    Finally, to make all of this complete, you can direct output
to the console, printer, or punch at any time (for programming
whatever device you want to program), there are debugging commands
(pause to examine output, dump word definition table, dump format
expression), and you can set up as many *.DPG files that you want to
program a variety of functions.  DPROG is a true ZCPR3 utility, and it
searches the path for the *.DPG files, so you can store all of your
useful programs in the ROOT directory and DPROG will find them.

    DPROG is used by issuing a command of the form:

        DPROG filename.typ    <-- program from filename.typ
        DPROG filename        <-- program from filename.DPG
        DPROG            <-- program from STD.DPG

    I currently have 6 different files to program my TVI950 for
working with assemblers, C, Pascal, dBASE II and Multiplan, Word Star
and Starindex, and standard definitions, and a 7th program file for a
TVI 970 (still being tested).

    DPROG, of course, can be used within an alias, ZEX command
file, or any other ZCPR3 environment.  For instance, the following
Word Star alias is reasonable:

    IF NEC=$2
        DEV L NEC        <-- assign printer
        WSN $1            <-- run NEC version of WS
    ELSE
        DEV L TTY        <-- assign printer
        DPROG CORRESP        <-- program printer for
                        correspondence
        WS $1            <-- run proper version of WS
    FI

    And so on ... comments?

        Rick
30-Jul-84 11:10:15-MDT,1169;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 30 Jul 84 11:10:04-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  30 Jul 84 11:25 EDT
Received: From xerox.arpa.ARPA by BRL-AOS via smtp;  30 Jul 84 11:24 EDT
Received: from Muscat.ms by ArpaGateway.ms ; 30 JUL 84 08:22:36 PDT
Date: Mon, 30 Jul 84 11:20 EDT
From: [e-mail]
Subject: Re: C features
In-reply-to: "hplabs!tektronix!orca!iddic![e-mail]'s message
 of 24 Jul 84 9:52:07 PDT (Tue)"
To: hplabs!tektronix!orca!iddic![e-mail]
cc: [e-mail]

Rick,

I never used the floating point support on BDS but it looked cludged
(not part of the base system, it looked like an addon.  Aztec provides
true floating point support, along with a slew of scientific routines
(trig functions, log functions, etc.).

If you have any questions in particular, feel free to ask.  Like I said,
Aztec looks like ( and is advertised as) a full Unix compatible C
without bit fields, BDS is a wonderfully fast compiler with limited
capability for large scale software projects.  It is fine for small
projects.

Marty

30-Jul-84 11:56:33-MDT,855;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 30 Jul 84 11:56:26-MDT
Received: From brl-vgr.arpa.ARPA by AMSAA via smtp;  30 Jul 84 13:15 EDT
Received: from usc-isid.arpa by BRL-VGR.ARPA id a027291; 30 Jul 84 13:14 EDT
Date: 30 Jul 1984 13:12-EDT
Sender: [e-mail]
Subject: Re: ? ASM S error flag
From: [e-mail]
To: [e-mail]
Cc: [e-mail], [e-mail]
Message-ID: <[USC-ISID.ARPA]30-Jul-84 13:12:07.ABN.ISCAMS>
In-Reply-To: The message of 30 Jul 84 17:56:36+0100 (Monday) from [e-mail]

Ken (et al),

Yes, I believe LASM is the same as LINKASM by Christensen.  It has, as I
recall from the .ASM notes, been upgraded somewhat.  Sure do work good, yep.

Regards,
David Kirschbaum
Toad Hall (ABN.ISCAMS@USC-ISID)
30-Jul-84 11:57:00-MDT,651;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 30 Jul 84 11:56:56-MDT
Received: From brl-vgr.arpa.ARPA by AMSAA via smtp;  30 Jul 84 13:06 EDT
Received: from xerox.arpa by BRL-VGR.ARPA id a027213; 30 Jul 84 13:07 EDT
Received: from GreeneKing.ms by ArpaGateway.ms ; 30 JUL 84 10:05:57 PDT
Date: 30 Jul 84 17:56:36+0100 (Monday)
From: [e-mail]
Subject: Re: ? ASM S error flag
In-reply-to: <[USC-ISID.ARPA]27-Jul-84 16:59:41.ABN.ISCAMS>
To: [e-mail]
cc: [e-mail], [e-mail]

David,

Is LASM the same as LINKASM by Ward Christensen

Ken
30-Jul-84 14:19:12-MDT,1418;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 30 Jul 84 14:19:05-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  30 Jul 84 15:00 EDT
Received: From lll-mfe.arpa.ARPA by BRL-AOS via smtp;  30 Jul 84 14:58 EDT
Date: Mon, 30 Jul 84 11:50 PDT
From: [e-mail]
Subject: C features: BDS-C supporter
To: [e-mail]

I tend to disagree that BDS-C is useful for only small projects. I'm not
sure what we want to define small as but I have written a large specialized
database program in BDS-C just fine. I did not need full floating point, in
fact what I did need I wrote directly in C because the full floating-point
hack that BDS-C does have was too much for me. The program was so big (tell
me how big is big, etc. joke) that I run it as two co-routine which cross
chain each other. There is the main routine with lots of routines and fairly
small in memory data and the sort (co)routine which is small but requires
(for efficiency) lots of in memory data. Whereas BDS-C is not a good as
other C's I've used (such as Lattice-C on the IBM-PC) I think it is great
for CP/M-80 for (1) price, (2) speed (3) features.

I have written a cross assembler (6502) in BDS-C, a terminal concentrator
interface, and various other utilities-all just fine. There are just a
few features I wish I could inspire Leor to put in but...
--Neil Maron
30-Jul-84 15:26:28-MDT,1646;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 30 Jul 84 15:26:20-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  30 Jul 84 16:43 EDT
Received: From ucb-vax.arpa.ARPA by BRL-AOS via smtp;  30 Jul 84 16:45 EDT
Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.28/4.33)
    id AA18512; Mon, 30 Jul 84 13:43:10 pdt
Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA)
    by ucbjade.CC.Berkeley.ARPA (4.14/4.23.2)
    id AA08977; Mon, 30 Jul 84 13:45:06 pdt
Received: by ucbopal.CC.Berkeley.ARPA (4.14/4.23.2)
    id AA11166; Mon, 30 Jul 84 13:20:38 pdt
Date: Mon, 30 Jul 84 13:20:38 pdt
From: William C. Wells <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: ZCPR3 and CP/M 3.0
Cc: [e-mail]

In reply to:

    Date: 28 Jul 1984  07:57 MDT (Sat)
    Message-Id: <RCONN.12034921427.BABYL@SIMTEL20>
    From: Richard Conn <RCONN@SIMTEL20>
    To: wcwells@ucbopal (William C. Wells)
    Cc: info-cpm@brl
    Subject: ZCPR3 and CP/M 3.0
    In-Reply-To: Msg of 26 Jul 1984  20:12-MDT
        from wcwells%ucbopal.CC at Berkeley (William C. Wells)

    Good point ... I wasn't aware of it.  Thanks for the note.
    Have you tried doing this or do you intend to?

        Rick

I have not tried applying the RSX to a CP/M 2.2 program yet.  I am more
of an applications person than I am a ASM hacker.

Anybody want to try attaching the RSX to some of the ZCPR3 programs to
see if they will work under CP/M 3.0 without ZCPR3 ?

Bill

[e-mail], [e-mail], ucbvax!wcwells
31-Jul-84 04:36:48-MDT,819;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 31 Jul 84 04:36:44-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  31 Jul 84 6:12 EDT
Received: From ucb-vax.arpa.ARPA by BRL-AOS via smtp;  31 Jul 84 6:04 EDT
Received: by UCB-VAX.ARPA (4.28/4.33)
    id AA01150; Tue, 31 Jul 84 03:03:21 pdt
Received: by HP-VENUS id AA19921; Mon, 30 Jul 84 19:34:58 pdt
Message-Id: <8407310234.AA19921@HP-VENUS>
From: hplabs!iddic![e-mail]
To: [e-mail]
Received: from iddic.uucp by tektronix ; 30 Jul 84 08:43:33 PDT
Subject: cpm info
Date: Mon Jul 30 08:38:44 1984

Persons:

Does any method exist for people on USENET to gain access to the cp/m archives
at SIMTEL20?

                            Thanks,

                            Rick Coates
                           . . .tektronix!iddic!rickc


31-Jul-84 04:37:56-MDT,1872;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 31 Jul 84 04:37:47-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  31 Jul 84 6:12 EDT
Received: From xerox.arpa.ARPA by BRL-AOS via smtp;  31 Jul 84 6:07 EDT
Received: from CheninBlanc.ms by ArpaGateway.ms ; 31 JUL 84 02:37:20 PDT
Date: 30 Jul 84 07:44:03 PDT (Monday)
From: [e-mail]
Subject: Problem with Creating a file
To: [e-mail]
cc: [e-mail]

Last weekend, I needed to do a quick and dirty test of transfering data
from one computer to another over an RS232 direct hookup.

So I entered DDT and started hand assembling a short job to create a
file, read the appropriate port, and store the data in the file. Since I
wasn't sure the data would come over (hardware parameters needed to be
futzed with), I used the debugger breakpoint facilities to watch what
was happening. I found that the FCB at 5? (Hex) (I'm at work with no
documentation, so I don't remember the number off the top of my head,
but it's the default FCB) would be set up properly according to the
documentation by the appropriate BDOS Create file call, but after the
first sector of data had been stored, the "number of sectors used in
current extent" byte was garbage. Manually reseting it to 1 and
proceeding allowed me to capture the rest of my data. The byte was
properly incremented thereafter.

Any ideas what's going on? Is it an artifact of using the Debugger? (If
that were so, I might expect the byte to keep getting clobbered.) I have
used my system (an Imsai 8080, running CP/M 2.2) with many standard
programs with no problems. I don't usually bother to write my own, but I
do when I have to. I followed the documentation in the CP/M manuals for
making BDOS calls correctly, to the best of my knowledge.

Cheryl
31-Jul-84 05:06:30-MDT,936;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 31 Jul 84 05:06:25-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  31 Jul 84 6:12 EDT
Received: From xerox.arpa.ARPA by BRL-AOS via smtp;  31 Jul 84 6:08 EDT
Received: from CheninBlanc.ms by ArpaGateway.ms ; 31 JUL 84 02:37:28 PDT
Date: 30 Jul 84 07:54:54 PDT (Monday)
From: [e-mail]
Subject: Re: SHSET
In-reply-to: <RCONN.12034047184.BABYL@SIMTEL20>
To: Richard Conn <[e-mail]>
cc: [e-mail], [e-mail]

Rick

As I understood the description, the choice of what to do with the next
command depended on the previous command being CORRECT, executed, and
the PROGRAM returning a completion code. This is quite different from
deciding what to do if the COMMAND LINE itself is in error. In most
cases you would want to abort, fix up the command line and restart.

Cheryl
31-Jul-84 07:01:14-MDT,1624;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 31 Jul 84 07:01:07-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  31 Jul 84 8:19 EDT
Received: From simtel20.arpa.ARPA by BRL-AOS via smtp;  31 Jul 84 8:15 EDT
Date: 31 Jul 1984  06:14 MDT (Tue)
Message-ID: <RCONN.12035689106.BABYL@SIMTEL20>
From: Richard Conn <[e-mail]>
To:   [e-mail]
Cc:   Richard Conn <[e-mail]>, [e-mail]
Subject: SHSET
In-reply-to: Msg of 30 Jul 1984  08:54-MDT from Chapman.ES at XEROX.ARPA

Yes, SHSET assumes that the command line is correct.  Once ZCPR3
decides to invoke a shell, the shell is processed like any other
command line, so your concern would be addressed by an Error Handler
should the command line loaded by SHSET be incorrect.  Current Error
Handlers do not have a provision for aborting a shell, so your point
is well-taken.  A new error handler, say ERROR5, should be created
which can abort a shell as well as redirect execution of the command
line (like current error handlers do).  Of course, if the SHSET
command line includes CMD, then when the conventional error handler is
invoked, the user could instruct execution to proceed to CMD, at which
point the user could issue a SHCTRL POP command to clear the shell
stack.  For that matter, a convnetional error handler will simply
allow the user to issue the SHCTRL POP command anyway.

    Hence, your problem is solved by using a conventional error
handler.  I think I will still add ERROR5, which will be able to deal
with the shell stack.

    Rick
31-Jul-84 13:01:03-MDT,739;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 31 Jul 84 13:00:58-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  31 Jul 84 14:25 EDT
Date: 31 Jul 1984  10:50 MDT (Tue)
Message-ID: <KPETERSEN.12035739329.BABYL@SIMTEL20>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   "Paul L. Kelley" <[e-mail]>
Cc:   [e-mail]
Subject: Setup program for Gemini-10 Printer
In-reply-to: Msg of 29 Jul 1984  21:47-MDT from Paul L. Kelley <PLK at MIT-MC>

Thanks for contributing GEMSET10 for the Gemini-10 printer, Paul.
Sorry I neglected to give credit to you when I announced the files to
Info-Cpm.  Keep up the good work!
--Keith
31-Jul-84 13:04:14-MDT,1607;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 31 Jul 84 13:04:01-MDT
Received: From brl.arpa.ARPA by AMSAA via smtp;  31 Jul 84 14:08 EDT
Received: From utexas-20.arpa.ARPA by BRL-AOS via smtp;  31 Jul 84 13:21 EDT
Date: Tue 31 Jul 84 11:06:55-CDT
From: John Otken <[e-mail]>
Subject: Re: Problem with Creating a file & ASM "S" error
To: [e-mail], [e-mail]
In-Reply-To: Message from "[e-mail]" of Mon 30 Jul 84 07:44:03-CDT

What you probably needed to do was to clear the CR field of the
FCB after the MAKE BDOS function call.  This is documented under
the OPEN FILE function.  Becareful with statements such as "according
to the documentation".  My CP/M book sez the following for the
MAKE FILE function: "The FDOS creates the file and initializes both the
directory and the main memory value to an empty file. [...] The make
file function has the side effect of activating the FCB and thus a
subsequent open is not necessary."  Well, I dont know about you but
*initializes ... the main memory value* doesn't mean anything to me.
And *activating the FCB* probably means what it meant for the OPEN
function which is that you still need to clear the CR field.

One thing is for sure, DDT is NOT responsible for messing with the
FCB unless, of course, you told him to do it.

While on the subject of DR docs...  Another way to get the "S" error
from ASM is to use an instruction mnemonic as a label.

ALL INFORMATION PRESENTED HERE IS PROPRIETARY TO JOHN OTKEN [sic]
-------
31-Jul-84 13:43:56-MDT,1983;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 31 Jul 84 13:43:48-MDT
Received: From simtel20.arpa.ARPA by AMSAA via smtp;  31 Jul 84 14:24 EDT
Date: 31 Jul 1984  10:45 MDT (Tue)
Message-ID: <KPETERSEN.12035738288.BABYL@SIMTEL20>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: GEMSET10 setup program for Gemini-10 printer

GEMSET10 is a version of MXSET by Simon J. Ewins set up for a
Gemini-10 printer.

The following has been done -

     1. Home printhead command removed.
     2. Carriage return and linefeed not sent to printer after commands.
     3. Proportional spacing command added.
     4. 12 cpi command added.
     5. Start column command added.
     6. Lines per inch command added.
     7. Formfeed command added.
     8. Optional printer status checking added.
     9. Header line position command added.
    10. Eliminated stack imbalance and improper use of PRINT##.

Here is a short review of MXSET:

MXSET Rev. 1.2 by Simon J. Ewins, Toronto, Ontario, Canada.

This program will set/reset all of the major functions of the Epson MX-80
printer. The program uses Z80 Zilog mnemonics and calls are made to Richard
Conn's excellent SYSLIB.REL file. Microsoft's M80 macro assembler is needed
for assembly of this file as well as the SYSLIB file.

The GEMSET files are available on SIMTEL20 as:

Filename            Type     Bytes     Sectors     CRC

Directory MICRO:<CPM.LIST>
GEMSET10.COM.1            COM      2816   22 =  16H  CE53H
GEMSET10.HEX.1            ASCII      7933   62 =  3EH  497EH
GEMSET10.MAC.1            ASCII      7127   56 =  38H  0B96H
GEMSET10.MSG.3            ASCII       549    5 =   5H  B324H

The original MXSET12 files are also available for Epson owners:

Filename            Type     Bytes     Sectors     CRC

Directory MICRO:<CPM.EPSON>
MXSET12.COM.1            COM      2176   17 =  11H  EED5H
MXSET12.HEX.1            ASCII      6133   48 =  30H  2923H
MXSET12.MAC.1            ASCII      4068   32 =  20H  DB1DH