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

Text File | 1993-02-12 | 267KB | 6,166 lines

 1-Sep-86 13:09:55-MDT,2017;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 1 Sep 86 13:09:44-MDT
Received: from uci-icsc.arpa by AMSAA.ARPA id a009720; 1 Sep 86 14:43 EDT
Received: from localhost by ICSC.UCI.EDU id a020179; 1 Sep 86 11:43 PDT
To: Dave <[e-mail]>
cc: [e-mail]
cc: [e-mail]
Subject: Re: kaypro 10 schematics
In-reply-to: Your message of 29 Aug 86 20:49:58 GMT.
             <[e-mail]>
Date: Mon, 01 Sep 86 11:42:45 -0800
From: Michal Young <[e-mail]>

Micro Cornucopia sells three varieties of Kaypro schematics, for $20 each,
with a theory-of-operation keyed to schematic.
    -  Kaypro II & 4 (pre-84)
    -  Kaypro 10 (without modem)
    -  Kaypro 2, 4, 10 (84 series)
Schematics are on a single 24" by 36" sheet.  They include serial and
parallel port details and programming examples, and other nitty-gritty
details that is hard to find elsewhere (e.g., how the Kaypro II bios
switches between video and main ram banks). I have both the Micro-C
schematic for Kaypro II, and a bootleg copy of the dealer's manual and
schematic.  The Micro-C version is a lot better than what Kaypro provides
dealers.

Address:    Micro Cornucopia
        P.O. Box 223
        Bend, Oregon  97709

Phone:        [phone]  (9am to 5pm, PST)

They take Visa and Mastercard, and prices include postage.
I've ordered from them by phone, and got good fast service.  They also have
a technical help hot-line, the number of which I don't want to broadcast to
the net, but you'll find out about it if you decide to buy a schematic from
them.  I've called the technical hotline and gotten good help on tracking
down a hardware problem. In summary, this organization is a good resource to
people with Kaypros (also Big Board homebrew systems, and Xerox 820 series.)

I have no connection with Micro C, other than as a satisfied subscriber and
customer.

--Michal Young
  University of California, Irvine
  [e-mail]
 1-Sep-86 14:37:20-MDT,46496;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 1 Sep 86 14:35:48-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a009931; 1 Sep 86 15:15 EDT
Date: Mon, 1 Sep 1986  13:16 MDT
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: List of best public domain CP/M programs

Norm Gregory, SysOp of Seattle's "Downspout" Z-Node, provides this
list of best public domain software for the CP/M user.  This list is
updated monthly.  It is presented here for your information and does
NOT in any way indicate that ALL these files are available from
SIMTEL20, my RCP/M, or GEnie's CP/M RoundTable.  However, many are
available from these sources.

PD:<CPM>CPM.CRCLST on SIMTEL20 (the file listing all the filenames,
sizes and CRCs of the PD:<CPM.xx> directories) has been updated as
of today.

--Keith

--cut here--SEPBEST2.LST--cut here--
SEPBEST2.LST is a revised version of SEPTBEST.LST to correct for duplicate
entries, bad alphabetical sort, and incorrect end-of-file.  No entries have
been altered.  -- Keith Petersen, W8SDZ -- 9/1/86 0938 edt.

            -[ Seattle's `downspout' ]-
                206-325-1325

                 300/1200/2400 baud

DATE:  09/01/86
  TO:  All CP/M users
FROM:  Norm Gregory (SYSOP)

This is an alphabetized list of public domain files and programs considered
"best" by the users of Seattle's `downspout.'

----
ACMDU11.LBR - ZCPR3
   Allows you to add, delete and view aliases in an ALIAS.CMD file without a
   word processor.  ACMDUTIL was written for those of us who write aliases on
   the fly.  V1.1 now searches BASE: rather than ROOT: for the ALIAS.CMD file
   and takes an optional DU: on the command line to find any copy of ALIAS.CMD.

-----
ACREATE3.LBR
   ACREATE now searches A0: and A15: and DCREATE extracts the command
   line from an alias file and puts it in a text file for editing.
   That's right,  ACREATE3.COM creates a ZCPR3 ALIAS file from a standard
   text file.  And DCREATE.COM will create a text file from an ALIAS file.
   The system works well and is fast.        (01:52:31 AM  Jul 14, 1985)

----
ADIS.LBR - CP/M
  Matt Wing's Z80 and 8080 disasembler.

----
ALIAS#1.LBR - Z3
   The Echelon ZCPR3 newsletters frequently contain sample Alias scripts....
   this library contains almost all those which have been published to date,
   plus a few to come in future newsletters.

----
ARCDIR.LBR - CP/M
   A utlity to allow CP/M80 users to do a directory of PC/DOS ARC files.
   A must for BBS systems.        [ 06:45:01 AM  Nov 21, 1985 ]

----
ARUNZ09.LBR - ZCPR3
   ARUNZ now has MENU/VMENU-style user prompts (but better!) and parameters
   that read Z3 registers and memory locations.  If you run a Z3 system and
   do not use ARUNZ you are missing what is perhaps the best of all Z3
   utilities.  Store all your alias scripts in one little ASCII text file.

----
ASCII.LBR - CP/M
   ASCII.COM is for folks with poor memories. Just type in ASCII<CR> and
   press any key.  The key and it's HEX code is displayed.  ^C to end the
   program and warm boot the system.        [ 12:21:13 AM  Dec 07, 1985 ]

----
AUTOZINS.CCP
   Notes on modifing your copy of ZCPR3 ccp to "autoinstall" all ZCPR3
   utilities.  Erase ZINS - you won't need it any more.  No more hassles
   with downloading ZCPR3 programs and forgetting to install them.

----
B-COMPIL.LBR - CP/M
  This is BCBC, CP/M VERSION 1.1, written by Bruce Tonkin.  It's a BASIC
  compiler written using the pbasic pre-processor for Microsoft BASIC 5.2
  or higher.   BCBC generates assembler source code for ASM or MAC.  Intel
  8080 opcodes are used.

----
B5C8-2.IQS - RCPM/BBS
   Finally a BYE5 insert for the Commodore C128 to be used with BYE510 or
   newer.  Thanks to George Peace.

----
BBCAT10.LBR
   BBCAT is a catalog program integrated with the archive/dater/backup
   utility BBACK (v6.0) to provide a convenient way of keeping track of
   backed-up files and of eliminating duplicates.  Unlike NCAT, UCAT et
   al, which are meant chiefly for the floppy-disk user, BBCAT is de-
   signed primarily for those with hard disks who only use floppies for
   back-up and storage.

----
BD03.LBR - CP/M
   Irv Hoff's update to his fine bad sector lockout program.  This one
   reports the file names that have bad sectors, which is what you
   really want to know.

----
BISHOW32.LBR - CP/M
   BISHOW32 reads just about any text file, whether or not it is squeezed
   or enclosed in a library. It allows you to move forward and back in
   the file by a page or a line at a time. You can scroll horizontally
   in a file wider than the screen. You can jump back to the top of the
   file. It uses Wordstar cursor keys, as well as alternates. Fits in 2k

----
BRADFORD.LBR - CP/M
   Aaron Contorer's Near Letter Quality printer program for Epson and Gemini
   printers.  A commercial package that Aaron is now distributing as Freeware.
   If you use it, send Aaron $15 and he will send you his manual, which tells
   you about advanced features.

----
BU14.LBR - CP/M
   Hard disk back-up, special printer versions in .LBR

----
BWFMT.LBR - CP/M
   This is for BONDWELL computers, 12 and 12A for sure (maybe 14 &16).
   These allow formatting disks for Osborne and Kaypro computers.

----
BYE510.LBR - RCPM/BBS
   BYE5 is the program most RCP/M systems use (for CP/M 2 and CP/M 3) to
   interface their computer and modem to their local BBS system.  This
   version adds the SYSLOG option which captures all input from the remote
   user.  Other improvements...read BYE5.HQS in the .LBR.

----
CHEFREC.5Q - CP/M
   More recipes for Chef.com.

----
CHOP.LBR - CP/M
   CHOP is a little CP/M program written in Turbo Pascal to copy a large
   text file into a number of consecutive smaller ones which are easier
   to handle and edit.    The new files have numbered extensions (file
   types).  The file will be divided into pieces, each having 128 lines.
   These can be edited and then re-combined with PIP.  Program is very
   slow and files are quite small, typically 5-8k each (depends on the
   average line length).

----
CRUNCH12.LBR - CP/M
   File compression utilities for "squeezing" files using the same
   algorithms as the MSDOS ARC program. Source code included.

----
DASM16.LBR - CP/M
   This is Rick Conn's DASM15 now including an include file for
   Hitachi HD64180 mnemonics.       [ 03:10:00 PM  Oct 26, 1985 ]

----
DBL4.LBR - CP/M
   Update of the DBL program for printing two pages on one page with an Epson
   printer in compressed mode.            [ 04:20:52 AM  Nov 19, 1985 ]

----
DBUG10.LBR - CP/M
   An internal debugger for Turbo Pascal programs; sort of a DDT tool. It adds
   about 600 lines of code in an include file.    [ 02:55:24 AM  Dec 28, 1985 ]

----
DEARC2.LBR - CP/M
   Allows a CP/M user to access those 16 bit .ARC files that you see
   everywhere.    The program uses two different decompression algorithyms,
   the Greenlaw and LZW, depending on the method used to compress initially.

----
DEBUGRCP.AQM - ZCPR3
   ZCPR3 Debug facility (same as MU31) in a Resident Command Package.

----
DEMOHLP.LBR - ZCPR3
   A demonstration and tutorial on ZCPR3 *.HLP files.

----
DDTZ.LBR - CP/M
   Replacement for Digital Research DDT.COM, adds search features, etc.

----
DIR1ST31.LBR - CP/M
  DIRFIRST:  Z-80 sorted directory showing first line(s) of files.
  Latest in the DIRFIRST series (v 3.1).

----
DIRR7.LBR - CP/M
   Directory file, alphabetizes vertically in an unique manner generally
   considered to be superior to that of "SD".  Type '?' for a help guide
   to see the various options available.  In extended mode, shows system
   files, R/O and archived files with special characters, making use of
   reverse video, lower case, etc. superfluous.  Can also make hard-copy
   or a disk file including those attributes.  Has several unusual fea-
   tures you will immediately like.  Fixed the 'A' option this version.
               [ 11:36:24 PM  Dec 11, 1985 ]

----
DIRSIZE.LBR - CP/M
   Utility program for disk directory file count. [ 02:33:31 AM  Apr 24, 1986 ]

----
DU312.LBR - Z3
     Newest version of DiskUtility from Z-NODE Central.

----
DZ-APR86.LBR - CP/M
   John Washington's latest update to his DazzleStar.  It does NOT
   replace DZ-FEB86.LBR.  It is a supplement, principally advising
   of a few fixes.

----
DZ-FEB86.LBR - CP/M
   This is latest version of DAZLSTAR, an interactive Z80 disassembler
   New version has comprehensive install program, "side-line" comments,
   active cursor indicator in both ascii and hex fields, and greatly
   improved menus.  Extremely flexible.  If you do any disassembly, you
   need this one.            [ 04:54:14 AM  Apr 06, 1986 ]

----
EPRO.LBR - CP/M
   E-Prolog is a public domain prolog interpreter for Z-80 computers.
   The .LBR file contains the interpreter, a library of logical predi-
   cates (AND, OR, etc.), some sample databases, assembly language
   source modules, documentation, and some other things.  E-Prolog is
   a minimal prolog, but it works for constructing databases and
   inference rules within them.  Its main lack is that it won't do
   even integer arithmetic.  It will do disk I/O.

----
EXPRESS1.LBR - CP/M
   A very fast full screen text editor. EXPRESS v1.0: 1) includes a
   built in macro key translator and editor; 2) can be installed on any
   CP/M 2.2 system with at least 48k of memory and a terminal with direct
   cursor addressing; 3) is not a word processor; 4) is a preliminary and
   limited implementation, distributed without charge, to introduce users
   to the potential of the EXPRESS full screen editor from Cecil and Laine
   Stump of Woodinville, Washington.         [ 02:51:25 AM  Sep 28, 1985 ]

----
FANFOLD5.LBR - CP/M
   "Universal" version of Ron Rock's (Chicago) FANFOLD. For those with Turbo-
   Pascal a small RUN.PAS file chains to FANFOLD.CHN with printer codes
   supplied by user. START address 2100; END address CB10.

----
FASTMX80.MOD - CP/M
   Speedup for Epson MX-80 Printers!!           [ 06:16:51 AM  May 29, 1986 ]

----
FATCAT24.CHG - FATCAT
   Locations in FATCAT24 to change the "|" delimiter to something your
   printer can print i.e. a ":".

----
FATCAT24.LBR - CP/M
   Steve Cohen's (Chicago) update of his marvelous catalog program stamps out
   bugs in version 2.3 and adds some goodies such as a print to file routine.
   If you came to the party late FATCAT is the super-duper-disk cataloguer
   featuring rapid-fire disk insertion, with tedious catalog updating taking
   place after all disks entered; also library file support and a
   screen-oriented "Cleanup" mode in which files can be erased or renamed
   before being catalogued, and also disk-name files can be added in
   this mode.

----
FBAD60.LBR - CP/M
   Finds and locks out bad sectors on a CP/M-80 disk.  Finally it will
   now run under CP/M Plus as well using included RSX.    Instructions
   on how to implement version for CPM Plus are included.

----
FILT7A.LBR - CP/M
   A multi-purpose filter program for text files, WordStar files or as-
   sembly level source code files.  Menu-selection.  Removes all tabs or
   optionally puts tabs at all optimum locations.  This version checks
   for space breaks and soft-hyphens before looking for unwanted control
   characters.    Very fast, when done shows a summary of what it found.
   7k, 54 records.

----
FINREP22.LBR - CP/M
   Eric Gans' (French Department, UCLA, Los Angeles, CA) FINd and REPlace
   V2.2 which adds "V" flag to allow user verification ("Replace  (y/n)?")
   before replacement in text files. FINREP is a search/replace program that
   remedies most of the deficiencies of Wordstar's ^QA and other similar
   commands.  Aside from being faster, it has important additional features:
     - allows wildcards in search string (v2.0)
     - allows wildcard filename (find/replace in groups of files)
     - command-line entry allows batch processing by SUBMIT, etc.
     - allows entry of control or hex characters (0-FF)
     - can be used with object files (e.g., COM files)
     - sets  capitalization (first letter or whole word) and high
       bit of the last character according to the old string
   This last feature means that,  for example,    if you are writing a
   scenario where the characters' names appear sometimes in CAPS and
   sometimes just Capitalized, you don't need two search/replaces to
   replace one name with another: JOE will be replaced by HARRY, Joe
   by Harry, and even joe by harry.

----
FRONT50.LBR - CP/M
   Latest update of FRONT, a program that replaces the usual CPM A>
   prompt with a menu.

----
FT.LBR - CP/M
   A quick, dirty, and tiny text file creator.    Type FT FILENAME.EXT and start
   typing.  Two <CR>'s closes and saves file.  [ 03:50:10 AM  Oct 25, 1985 ]

----
FU-12.LBR - CP/M
  File Utility is a full screen binary file editor.  Cursor functions pretty
  much follow WS commands.  Also includes a windowed full function calculator
  for binary, hex, and decimal interger.   And takes up less memory than
  PATCH, which is great for use small TPAers.    Great hacking tool!!!

----
FUNKY12.LBR - CP/M
  Allows you to program your terminal's function keys, either interactively
  or from a disk file.    This version includes the ability to embed control
  characters and escape sequences.

----
GKEY2.LBR - CP/M
   Gans' key enhancer generalized for all CP/M machines (2.2 at least).
   Smaller than SMARTKEY, allows redefinition of ESCAPE sequences.
   use a little beta-testing on machines other than the Kaypro.

----
GTXT11.LBR
   Makes a text file into a .COM file. V1.1 update:
    - exit via ^C.
    - zeroes high bit to read (say) WS doc mode files
    - allows printing of control characters using "^" (thus ^Z entered in
      the text will blank the screen when the COM file is run.)
    - page breaks can be forced with "~"  However, a "[More]" is issued
      every 23 lines without you having to add "~" to the text;  when you
      type a character the [More] is blanked out and doesn't waste a line
      on the screen.            (12:40:38 AM  Jun 25, 1985)

----
HELP53.OBJ
   HELP is version 5.3 of HELP for ZCPR3.  The version adds automatic
   unsqueeze, so when you issue a command like "HELP topic", HELP
   will search for topic.HLP or topic.HQP along the path and in the
   HELP: directory, and, when found, will load and unsqueeze as
   necessary.  The tradeoff is space vs speed - squeezed files take
   less space but more time to unsqueeze during the load.  Once loaded,
   there is no difference in processing HLP/HQP until next load.

----
HIPPO11C.LBR - CP/M
   Vastly improved release of Happy Investor's (tm) Personal Portfolio
   Organizer.  Bugs fixed, more convenience, and capacity expanded to
   5 securities and 10 purchases in this free version of HIPPO (tm).

----
HSH15.LBR - ZCPR3
   History SHell.  Allows recall and editing of previous command lines.
   Version 1.5 corrects a serious bug in handling entry of long command
   lines and allows installation of the prompt string.

----
IMP244.LBR - CP/M
   Modem program that has 1k protocol, automatic step-down for 2400 bps
   modems and KMD-batch mode as well as MODEM7 batch.  This version
   changes the batch header block to work with KMD - stores the file
   length as two hex bytes at the end of the block.  Can now handle
   files up to 8.2 megabytes, while showing additional information.
   Also supports the Anchor Mark XII for autodial and is easier to use
   in terminal mode with Osborne OS-1 computers.  Other changes.

----
IMP-OVL.LBR - CP/M
   Overlays for the IMP modem program, dated 27 Oct 85.  See IMP-OVL.LST
   for a list of those avaiable in this library. [ 02:49:05 AM    Oct 30, 1985 ]

----
IMPATCH.LBR - CP/M
   IMPATCH is a menu-driven program for patching of IMP244 default
   parameters.    Options include either directly patching your version
   of IMP or writing a new version of IMP containing the changes.  The
   LBR file contains a DOC file with patch points explained.

----
INDEX85.LBR
   INDEX85 reworking by David Cortesi (Dr. Dobbs, "Inside CP/M," etc.)
   of his earlier indexing program.  This version (no new features,
   but also no bugs) is now in Turbo-pascal, and is quite elegant.  Also
   very useful for indexing any sort of published or just printed document.
   It's provided in compiled form for CP/M 80 systems (including a 48k
   version for us Z-system users), but may be recompiled for MS/DOS,
   probably without code changes.

----
INDOTCOM.ZQX - ZCPR3
   This .zex file will install your default RCP, FCP, NDR, PATH, and
   WHEEL specifications right into Z3DOTCOM so you don't have to
   load them each time you boot up unless you change them on the fly.

----
K83ZCPR3.LBR
   Full implementation of ZCPR3 for older Kaypro II's and IV's (pre-1984
   machines without video/graphics enhancements).  Fully compatible with
   the "standard" John Smith implementations for the Kaypro 10 and 484.
   Gives the user full utility interchangeability without reinstallation
   with ZCPR3 files (except SYS.ENV) used on Kaypro 10's and 484's. Uses
   all the Smith implementation addresses.

----
K83Z3UPD.LBR
   This is a library file which updates the K83ZCPR3.LBR.  It contains
   an updated bios image, the ASM file used to modify bios images, both
   of which focus on fixing the LISTST bug in the KAYPRO rom.  It also
   contains an alias program which alters one byte in any other alias
   program so that it can be used as a STARTUP.COM on a 58k TPA Kaypro
   ZCPR3 system and a .DOC file.       [ 04:05:03 AM  Jan 23, 1986 ]

----
KISOR.ART - Other
   Henry Kisor computer column no longer appears in The Seattle Times.
   This is copy of his last piece.

----
KMD.HQP - CP/M
   Help file telling how to transfer files with KMD.  Beneficial for new
   CP/M users who are unfamiliar with file transfer protocols.    Will
   hopefully save SYSOPs a lot of time trying to answer individual
   questions.  Even the experienced CP/M user might find the information
   of interest/value.  There are perhaps functions available some users
   are not aware exist and might find useful to their normal operation.

----
KMD22.LBR - GENERAL CP/M
   KMD is used by most RCPM systems for handling file transfers to/from
   the remote user.  This version uses Bob Freed's routines which allow
   downloading member files from an .ARC archive library.  It also uses
   a concept similar to that used for IMP, MDM7 and MEX permitting easy
   and rapid installation, via a master overlay merged with the object
   code file.  This permits a modest sized library.  33k, 259 records.

----
LABELG10.LBR
   LABELG10.LBR is a Turbo Pascal file that can be used to create
   Multiple Labels, store label information to disk, write to list
   Disk Labels, and finally act as a MailMerge-type creator of a form
   letter and the appropriate address label file.  A COM file is
   included that will run on any CP/M-type system.  All source files
   are also included.

------
LASM3.LBR
  This is an enhanced version of Pete Mack's LASM assembler which was it-
  self an improved version of Ward Christenson's LINKASM assembler.  All
  of the Z80 op codes have been added in the style of the 8080.  Also
  the symbol cross reference (requested by the XREF directive) will now
  be printed on the console if the normal listing has been directed there
  (the previous version only generated the XREF listing if the normal
  listing was directed to a .PRN file).

----
LRUN23.LBR
   Slight improvement over the already-good LRUN22.  Program now shows
   the bad command, with an LRUNZ-style error display, if it's not in
   the default or selected LBR.     (03:09:56 AM  Jul 11, 1985)

----
LSTOOL11.LBR - CP/M
  Jim Gronek's utility program designed to extend the usefulness of the
  MCAT/XCAT or LCAT/XLCAT Disk Cataloging System.  LST-TOOL can read the
  .LST files produced by XCAT/XLCAT and report useful information on them
  back to you.     V1.1 utilizes a technique to automatically determine
  available memory at run-time.

----
LUZ3.LBR
   ZCPR3 library tools.  LGET to extract and optionally unsqueeze files
   from a library, LLF to display files in a library, LX to run files from
   a library, LHELP to process HLP/HQP files in a library.  From Rick Conn.

----
M80VMN.DOC - ZCPR3
   Examples of what can be done with Z3's MENU, accessing editor, assembler,
   debugger, help system for writing programs with syslib.  Sure
   beats the L80 command line.         [ 06:00:55 AM    Nov 09, 1985 ]

----
MACPRINT.LBR - CP/M
   Public domain fancy printing program that really does enhance Epson
   compatibles!  --  Triple height, "MAC" style characters from a
   standard ASCII text file or the keyboard, runs under CP/M, and as
   the signon warns, don't hold your breath if you're running it on
   floppies!

----
MAKBATCH.LBR - CP/M
   Fast, easy way to create and execute submit-like commands, without
   submit.com or the need for an editor.  Instead of a secondary .sub
   file you get a primary .com file, ready to go. [ 06:11:25 AM  Oct 16, 1985 ]

----
MBINDX.LBR
  This program produces an index of the variables and reserved words used in
  a MBASIC program file.  The file to be indexed MUST be saved in the 'A'
  (=ASCII) mode.

----
MEMCOM.LBR
  These programs establish a virtual "ram disk", drive "E:", of various sizes,
  using space from TPA.  All that one must do is execute one of the MEMx.COM
  programs within this .LBR and a virtual disk will be created.  All
  subsequent references to "E:" will deal with the ram disk.  It appears that
  once installed, the only way to remove the ram disk is to reboot the system.

----
MENU40.LBR
   Joe Wright reworks MENU.  Many interesting new features, such as a
   'default' command on each menu, recognition of the quiet flag, better
   handling of default directory, and more.  Anyone volunteer to do
   a new .HLP file?  The changes are described more fully in the
   source code comments.  Also, try the included DEVMENU.MNU for a
   taste of what can be done with this new version.

----
MEX114-U.LBR
   (20 July 1985  Ron Fowler/NightOwl Software, Inc.)
   This release repairs several bugs reported in version 1.12, and adds
   support for 1k XMODEM file transfer packets.

----
MEXIT110.LBR - RCPM/BBS
   MEXIT version 1.1 is Kevin Murphy's newest MEXIT/MUT library.  A MUST for
   any METAL/Z-MSG BBS system.     Now supports the new features in KMD 11 or
   later so that you may select a ratio of downloads to uploads and disallow
   downloads if the ratio is exceeded.     The user is informed of this status.
   Also MUT109 has a new feature to allow a data file output from the USERS
   file, tag selectable.

----
MCOPY43.LBR
   Latest revision to MCOPY.  Adds the 'N' or 'no replace' option
   which AUTOMATICALLY refuses to copy when the file exists already
   in the destination disk/user.  Handy in aliases for setting up
   ramdisks on cold boot -- mcopy43 c15:=a15:*.* N, for example,
   will only do the copy if the file isn't already on the Ramdisk.

----
MKLINE.LBR - ZCPR3
   CP/M and ZCPR3 utility that will insert file names into a line of
   text and write them out to a disk file for use with ZEX or SUBMIT.
   Wildcards are allowed for multiple lines.  Read the .INF or .DOC
   file for more information.  Written in BDS C ver 1.50a.  Source
   and .COM file included.  jwm

----
MKRCP1.LBR
   All the tools (except MAC.COM) you need to make Resident Command
   Packages for your Z3 system.

----
MLOAD24.LBR
   Multi-file Hex Load Utility for CP/M.  MLOAD replaces the old CP/M LOAD and
   elminates the need for the 'SAVE' command.  Read the preface in MLOAD24.ASM
   for usage and details.

----
N41.LBR
   A very useful and easily used program that converts numebers to hex,
   binary or decimal.  Can also use Boolean arithmetic.  Almost any
   computer user has needed to convert hex addresses to decimal or vice-
   versa.  Source code and an interesting .DOC file included.  Assembly
   level code.    Should run on any CP/M-80 system.

----
NEWARC.LBR - CP/M
   David Rand's rewrite of Rubenstein's original programs for archive
   files.  Includes .com files for adding, deleting, sorting
   directories, running programs from archive, etc.  These are faster,
   take up 10% of the space that the originals did, and have otherwise
   been improved.

----
NEWRITE7.LBR - CP/M
   This file is used to print out the files created with TOUR (the PD
   outline processor).    It improves on and replaces WRITEGEN.COM.  The
   Turbo PASCAL source code is included. [ 05:17:19 AM    Jun 26, 1986 ]

----
NULU151.LBR - CP/M
   The BEST Library utility.

----
PASTE2.LBR - CP/M
   PASTE2 - combines two input files into a third, joining side by
   side. v1.1 corrects a bug discovered in v1.0 which dropped CRLF
   when second file expired first.  Added option to erase destination
   file if it exists or abort. Added info on optional [du:]filename.typ
   to usage message.  Originally written in a first wonderful encounter
   with SYSLIB 3.3!

----
PATCH&GO.LBR - CP/M
   This is a COM file adaptation of the Z3 POKE&GO technique for non-Z3
   systems, or for those whose Z3 implementations don't include the
   required functions.

----
PBBS03.LBR - RCPM/BBS
   PBBS v3.0 is used as the BBS program on many RCP/M systems.    PBBS is
   by far the best public domain BBS system in existance, and better
   than any non-public domain system surveyed.    This version adds many
   new features, including multiple bulletin boards, enhanced ZCPR3 sup-
   port, 25th status line and much more.  Requires BYE508 with a real-
   time clock installed.  Will work on any Z80 based computer.    Support
   files and conversion files in PBBSUP-3.LBR.    211k, 17 min at 2400 bps

----
PBBSFAST.LBR - RCPM/BBS
   Submit-type utilities for making a fast assembly/linking of the PBBS
   v3.0 system.  7k, 30 secs at 2400 bps.

----
PBBSUP-3.LBR - RCPM/BBS
   Support files required for PBBS v3.0.  Includes utilities to convert
   several existing user file formats to PBBS formats, including OxGate
   to PBBS.  88k, 7 min at 2400 bps.

----
PBBSUSR1.LBR - RCPM/BBS
   Offline utilities for the Sysop to use with PBBS v3.0, mainly for
   listing the user's file and stats on the callers file.

----
PDLN10.LBR - CP/M
   A new Public-Domain Linker, including a highly informative .DOC
   file.  For Z80 only, not for ZCPR only.  [ 06:13:17 AM  Apr 10, 1986 ]

----
PICKNUM.LBR
   A super MEX support program.  Contains PICK106 which will go through
   your .PHN files and select the numbers you want to put in a new
   .PHN file.  This contains updated versions of PICK and DLMX contained
   in Bill Norris' MEXELEC2.LBR

----
PPIP.LBR - Digital Research CP/M
   slick pip - the z80 version is fast - crc and verify options - can
   assemble to pip to destination from source or 'copy from source to
   destination' - accepts DU: - other toggles/switches - pip to text
   file with built in editor - -

----
PRICES11.RQS - Z-System (ZCPR3+ZRDOS)
   Slightly changed price list from Echelon...use for orders as of
   11 August and beyond...

----
PRINTHLP.LBR
   This program will print out an entire help tree. If you configure it
   for your printer it will highlight the text that is highlighted on
   the screen while running help. Thus if you want a nice document of
   all of the SYSLIB files just run it on SYSLIB.HLP and it will pick
   up all of the nested help files.

----
PROLINK.LBR - CP/M
   NightOwl Software releases ProLink, the great proprietary linkage editor,
   to the public for free distribution.  Included is LINKMAP, a REL file
   display utility.  ProLink is said to be vastly superior to L80 as a linker.
   Get this one if you do anything at all with relocatable assembler.

----
PSET15X.AQM - CP/M
   Upgrades PSET14 to include a real command line mode for batch and/or
   ALIAS use.  Only program that allows you to set print type from the
   command line prompt.  For Epson RX-80 and Gemini printers.

----
QEDIT125.ARC - MS-DOS
   This is an update of QEDITA and includes lots of new gimmicks.
   QEDIT is a fast, memory resident editor which has it all over
   the likes of WORDSTAR for programming.

----
QLIST14.LBR - CP/M
   Ian Cottrell, Ottowa ICBBS fixes reported bugs in QLIST14.  QLIST is a
   file lister that will automatically unsqueeze files before listing.
   QLIST allows you to select formatting options for the listing, including;
   left margin setting, line feed recognition, page headers, compressed print
   for body of listing and expanded print for the headers and page to
   start/stop printing.    See .DQC file for updates.

----
QWIKFONT.LBR - CP/M
   Sets FONT and type styles for Epson and compatible printers.  May be
   set up for differenct terminals and printers by use of SUPERZAP, etc.
   Also prints out quick labels with ability to change font in the mid-
   dle of the line.                 [ 05:48:02 AM  Nov 08, 1985 ]

----
RCPTRAPS.LBR - ZCPR3
   A little I/O redirection for ZCPR3 systems, in the form of Resident
   Command Packages.  Two files are included in the library, one sends
   all output going to the printer to a disk file, the other sends all
   output going to the screen to a disk-file.  The code is lean enough
   that this could be incorperated into your standard RCP.

----
READONLY.LBR - CP/M
   Sets the disk system in a CP/M Version 2.x operating system to read/only.
   Once executed the only way to return the disk system to read/write to do
   a system reset (cold boot).    This "safety" is intended to prevent untested
   software from changing any data on any disk. [ 08:18:28 AM  Oct 06, 1985 ]

----
RELHEX11.LBR
   Small, fast, accurate program that converts REL files to HEX format.
   Now RMAC owners can trash MAC & ASM, keep ZAS for Zilog mnemonics.

----
RESQ14.LBR - General
   This little program will help you out if you are using WS and get a 'disk
   full' error when you try to save your work.

----
ROS34.LBR - CP/M
   Remote Operating System v3.4.  A stand-alone RBBS, BYE, XMODEM, SD all
   included in one program.  Written in Pascal.  For CP/M systems.

----
SAME.LBR - CP/M
   Checks two files to see if they are the same.  Can erase one.  Read
   the .DOC file for various attributes. [ 06:14:22 AM    Oct 14, 1985 ]

----
SAP50.LBR - CP/M
   Sort and Pack. Cleans up your directories and eliminates deleted
   entries.

----
SAVESTAR.LBR - CP/M
   Saves WordStar 3.3 and Turbo text if you have 'lost' it all with a system
   crash or other accident.  From Profiles.  [ 02:16:14 AM  Feb 08, 1986 ]

----
SB180OVR.AQM - Other
   This is an overlay file that ports MDM730 to the SB180.  It's pretty
   rough, but as 'they' say in computer rooms across the land...
   "It works."    I'ld appreciate messages from anyone that can tell me
   how to do it right.    Thanks - aaron.  CRC after unsqueeze = 3FF1.

----
SETDRU13.LBR
   A clever way to enable you to use programs that require OVR (WordStar
   Perfect Writer, etc) any where on a hardisk.

----
SCAN12.LBR
   How about a TYPE that types files forwards/backwards/sideways
   and even works on squeezed files!!     [ 04:29:50 AM    Nov 19, 1985 ]

----
SCI-12.LBR - CP/M
   Small-C interpreter.  Even if you just know a little BASIC, a great way
   to get started with "C".

----
SIDEMT.LBR - CP/M
   A program to print sideways on a MT printer, for CP/M-80, NOT PC/MS-DOS!

----
SFILE26.LBR - CP/M
   Searches all allowed drives and user areas for a requested file or
   files.  An equate allows for searching into all libraries as well,
   atlhough this usually takes considerably longer.  Used on many RCPM
   systems with large disk drives and many user areas.    Very useful on
   any large hard disk system.    The .COM file is only 3k.  Source code
   included.  This version fixes a bug in the abort routine.

----
SHOWLOC.OBJ
  ANY 8 BIT CP/M COMPUTER CAN USE THIS. IT SHOWS THE LOCATION OF A FILE ON
  A DISK BY BLOCK NUMBER, TRACK AND SECTOR NUMBER.  (07:39:23 AM  Aug 08, 1985)

----
SLTRAP.LBR
   SLTRAP -- RCP which captures Screen and List output and stores it on
   disk.

----
SPOOLER.LBR - CP/M
   A new spooler/despooler utility.  Print and work at the same time.

-----
SODU.LBR - CP/M
  A screen-oriented version of the DU Disk Utility program for CP/M 2.2.

----
SSTAT18.LBR - CP/M
   A very nice, SWEEP/NSWP/DISK7-style replacement for STAT, PROT, etc.
   Does everything except change device assignments, and what it does
   it pulls off with great pizazz.

----
SUPZAP33.LBR - CP/M
   Updated version of SUPERZAP. Doesn't have all the features of some
   other patching programs. but is menu driven, easy to use and FAST.
   Source code included for adapting to diferent computers. Now Also
   supports CPM3.

----
SYSRCP14.LBR - Z3
    This library contains version 1.4 of SYSRCP.ASM, the code for the
    resident command package.  Version 1.4 has no significant differences
    from version 1.3.  Two small problems were fixed.

----
T3T-24-1.ZQ0 - ZCPR3
   Echelon releases a "telephone interface" for TERM III that supports
   300/1200/2400 baud modems such as the Hayes 2400, USR Courier 2400,
   and Racal-Vadic 2400V.  This TI allows full use of these modem's
   advanced features.        [ 03:32:45 AM  May 25, 1986 ]

----
TELENET.LBR - CP/M
   Turbo Pascal program to auto-log on PC Pursuit. Comes in two
   versions, one set up for the video Kaypros and the other generic.

----
TELL02.LBR
   This is a small utility used to find out various locations of what and
   where various addresses are within the CP/M for which this utility
   operates.  Quite useful if your writing software for CP/M, but need
   to find out the EXACT addresses that some CBOIS routines are operating
   when the occasion arises that the software CAN'T access it through
   CP/M, like rewriting FORMAT programs and such utilities as those.....

----
TEXTCOM.OBJ - CP/M
   Compares two ASCII files, reports differences and may, optionally, write
   same to a disk file.        [ 04:04:16 AM  Nov 19, 1985 ]

----
TPA3.LBR
   Indicates the TPA space available.         (08:52:50 PM  Jun 08, 1985)

----
TYPELZ15.LBR - CP/M
   Type any file (or library member) whether SQUEEZED, CRUNCHED, or
   ASCII, to CONSOLE or PRINTER.  If set for RCPM use, non-WHEEL users
   can't type SYSTEM files or access printer, and can be limited to a
   set number of lines.  Use .COM file and TZINST15.DOC along with DDT
   or PATCH to configure without reassembly.   SYSOPS note, makes a
   great LUXTYP replacement to add CRUNCHED typing to LUX Library mode.
   Source code included (Z80).

----
UNARC10.LBR - CP/M
   UNARC is a CP/M utility which allows the listing and extraction of
   subfiles contained in MS-DOS/PC-DOS archives (*.ARC files).    Requires
   CP/M 2.x or higher and Z80 only.  The library (88K) includes the Z80
   assembly language source; for minimum download: extract just UNARC10.COM
   and UNARC10.DQC (squeezed documentation).  [ 03:21:21 AM  May 09, 1986 ]

----
UNERAS12.LBR - ZCPR3
   Rescues those 'erased' files.

----
UNSPOL38.LBR - General
   An unspooler that works with squeezed files. [ 06:14:31 AM  Sep 17, 1985 ]

----
USQFST19.LBR - CP/M
   Steve Greenberg's Fast Unsqueezer, v1.9 - 04/02/86.    Takes wildcards.
   Z80 only.

----
VALIAS.LBR - ZCPR3
   Jay Sage's official release version of VALIAS, the full screen alias maker,
   editor, with built in help.    Great utility that replaces ALIAS.

----
VCED16LBR - ZCPR3
   Paul Pomerleau's Video Command Editor.  Now doubles as an error handler.
   Features a help menu, the ^O FIND option that searches the buffer for your
   command, and a command buffer locater that tells you exactly where in the
   circular buffer your command is located.  New version is faster.

----
VDE22.LBR - Text/Documentation
   Latest version of the handy little text editor.  Word-wrap, margin
   setting (left and right), crude windowing.  More WS-like with
   commands.

----
VERROR17.LBR - ZCPR3
   Version 1.7 prompts you for edit and is more responsive to keys hit before
   VERROR's message appears.  VERROR is a Z3 'error handler' that lets you edit
   mistyped commands before you get the famous '?'.  Try it.

----
VERSION.LBR - CP/M
   A small program that will allow you to add a comment line, version
   number, serial number and date to each program on your disk.  I have
   not tried it yet, but the DOC file looks interesting.

----
VFILER41.LBR - ZCPR3
   This is the latest version of VFILER4 from Jay Sage.  Jay's improvements
   now make VFILER the most powerful multi-faceted SUPER utility availabe.
   You can find a match in MS-DOS, CP/M or ....whatever.

----
VIRUS.TQT - Other
   This is an interesting description of computer viruses.  Subtopics
   include worms.  Definately more subtle and more devastating than
   'bugs'.

----
VMENU18.LBR - ZCPR3
   This is the latest update of misc and bug fixes.
   Changes made are:
   1  - "< & >" bugs fixed no longer drops to system.
   2  - it now knows what menu to use when changing user areas.
   3  - Command line no longer doubles up.
   4  - Minor cosmetic changes in banner line.
   5  - Now displays 4 lines by 5 colums, also added 1 menu line.

----
VTYPE17.OBJ - Z-System (ZCPR3 + ZRDOS)
   This is Dennis Wright's video oriented text file display utility.
   Use is easy:  VTYPE dir:filename.typ   Once started enter '/' for
   commands and options.

----
W20.LBR - ZCPR3
   Steve Cohen's new Z utility, "W" is a wild-card processing shell.  It
   allows you to give wild-card function to program that otherwise will not
   handle wild-cards.    [ 12:48:01 AM  Feb 27, 1986 ]

----
WINDEX21.LBR
   Latest version of WINDEX, a superior index generator, with improvements
   that allow use via the "R" command in Wordstar.

----
WIS105.LBR - CP/M
   Uploaded another copy becauses someone commented that the first
   had a trashed directory. This is the same one and NULU and LU both
   extracted the file fine! Hope this fixes the problem!

----
WS-BIBLE.DQC - General
   The comprehensive WordStar patch document, covering WS 2.26, 3.0, and 3.30.
   All you need is DDT or equivalent.         [ 01:37:42 AM    Dec 21, 1985 ]

----
WS-UROM.FQX - Z3
   How to patch Kaypro's U-ROM Wordstar for use with "Z-SYSTEM."

----
WSFAST24.LBR
   Sanders' latest update to the Wordstar speedup patch.  Also provides half-
   intensity reverse video for those who wish to preserve vision and CRT life.

----
WTEXT102.LBR - CP/M
   NLQ driver for Epson LX. Proportional letter widths, ragged margins.
   May also work on other FX/RX units. Draft type for MX w/Graftrax. The
   appearance of the Letter type on an LX is much better than Epson's
   fixed pitch NLQ, and better than anything else in the public domain.

----
XIZI-3.LBR - CP/M
   Irv Hoff's update contains two translators, one for Intel 8080 to
   Zilog Z80 source code and the other for Z80 to 8080 source code.
   Very fast.  This version fixes an obscure op code in the Z80 to 8080
   translator that has been present in virtually all such translators -
   check the "READ.ME" file for more information.  Will allow a single Z80
   assembler to be used for all CP/M work.  Replace such pgms as XLATE6,
   ZTOI, ITOZ, XLT8-80, XLT80-8, XLTZ80, ZCON, etc.
   20k, 152 records.                 [ 06:29:43 AM  Jun 19, 1986 ]

----
XUSER11.LBR - CP/M
   Utility permits you to use all 32 user areas.  See doc file for
   system constraints.    Interesting utility.  [ 07:12:29 AM  Nov 16, 1985 ]

----
Z-DEMO2.LBR
   Some great examples of how to utilize Z3's MENU power.

----
Z-RIP.LBR - ZCPR3
   Paul Pomerleau's newest Z-System contribution installs all ZCPR3
   utilities in a user area or in all user areas.  A fast way of re-
   installing if you have changed your memory map location of the
   environment descriptor.          [ 06:30:14 AM  Jun 19, 1986 ]

----
Z3KEY14.LBR - ZCPR3
   This latest version of the Z3 key-string utility includes
   the public domain Z80 assembler and a ZEX file to automate
   the assembly process. That should take care of all the assembly
   problems.

----
Z3NEW085.LBR - RAS-specific (Remote Access System)
   A ZCPR3 utility -- this replaces NEW andd provides many additional
   features.  This is a test version written by Edi Cramp of Tampa, FL.
   It has not been tested.  It needs to be run through its paces to
   see where the bad bugs may be lurking.

----
Z80MU310.ARC - MS-DOS
   Runs Z80/CPM programs under MS-DOS. Very good emulation. All
   standard programs seem to run (those not doing disk I/O on a
   track/sector basis, but using file open/closes) very well. This
   program has the best interactive debugger, disassembler, line
   assembler, symbolic debugger I have seen, and it is built in
   so it does not require TPA space. (which is 63k by the way!!)

-----
Z8E.LBR
   THE Z80 debugger.  Described as the best thing since Wonder......

----
ZAP.LBR - ZCPR3
  The ZAP Debugger as a RCP.  A "SYSTEM  MONITOR," most desirable for
  either the industrial or the hobbyist/experimenter environment. This
  monitor may be classified as a "DEBUG" monitor.  That is, it contains
  all needed tools to fully debug both hardware & software.

----
ZAP34B.LBR - CP/M
   SUPERZAP 3.4 (b version). A revision of SUPERZAP v3.3 to include string and
   hex-sequence search capabilities on a given file, and some 'enhancements'
   to the TYPE option, including 80 col. display, and allowances for viewing
   word-processed files of some commoner kinds.

----
ZAPN#1.LBR - ZCPR3
   The first of a series of application notes on the Z-System.    This one
   discusses the ZCPR3 Shell system 'from the inside'.    The target
   audience for these application notes are programmers and equipment
   manufacturers; however, there is probably a little something for
   everyone.

----
ZDR.LBR - CP/M
   A small ( <7 records, <1k ), but complete disk directory program.
   Its small size, and horiZontal format (the Z in ZDR) are suited to
   the screen of, say, the portable Epson Geneva PX-8.

----
ZDP.LBR - CP/M
   Z.D.P. is a Z80 assembly lang. program de-bugging, tracing, editing
   utility which runs on any CP/M based system.  The working code occupies
   just over 4k RAM positionable on any 256 byte page (e.g. can also trace
   code running in the CCP area). Inaddition to a self contained symbolic
   address feature; there are byte, word, & string search commands plus
   some other features not in DDT or ZSID. (for which this package serves
   as a useful supplement/replacement.     Library has several files including
   complete manual & implementation notes, etc.

----
ZFILE2.LBR - CP/M
   A replacement for FILE and SFILE.....for use primarily by RCPM/RAS
   systems with large Hard disks....Based on FINDF by R. Conn.    Uses
   std low memory max drive and max user locations in BYE5xx/KMD (3dh
   3eh,3fh).  May be used by any cpm system, compiled with any compiler.
   Added ^x to abort, ^s to pause, FIVE times faster than as FILE OR SFILE.

----
ZIPP.LBR
  Public doman utilities exist which execute the concatenation of files
  (i.e. join them end to end).    ZIPP was written to join up to seven ASCII
  files in a side to side or column sense.  Useful for data analysis,
  spreadsheets, reports, etc. [ This is a RENamed version of ZIP.LBR.
  This was done to avoid a name conflict with Ashton-Tate's ZIP.COM,
  the screen design program for dBASE II. ]

----
ZTP-INS2.LBR - ZCPR3
   Auto-installer for Turbo-Pascal programs on ZCPR3 systems.  Some of you
   may remember the earlier ZTP-INS.LBR.  That one used a Turbo-Pascal program
   to do the job, this one is a Z3 utility written in z80 assembler.  Other
   features include options to Turn off or reverse high and low video.

----
ZSIG-FOR.ALL - General
   N.A.O.G, the North American One-Eighty Group, becomes NAOG/ZSIG, the
   NAOG ZCPR Systems Interest Group, and embraces all users of ZCPR3.
   Jay Sage is Software Librarian, Richard Jacobson is RAS Coordinator,
   and Bruce Morgen is Director and Editor of the ONE-EIGHTY FILE.
   Membership application and full information are available in this
   file.  A users group for advanced programmers to share their dis-
   coveries and novices to learn.

----
ZSYSTEM.IQS
   A master checklist for all to assess their collection of Z-System
   (ZCPR3 + ZRDOS) utility programs, to determine where upgrades might
   be necessary or perhaps even acquire missing programs.  Altogether,
   lists 102 programs and 1 database, all distributed by Echelon, and
   nearly all available on Z-Node Central.  102 programs...What other
   operating system comes with 102 utility programs?  Wow! (Dated
   20 July 1986; will probably become inaccurate rapidly, due to the
   large amount of activity within Z-System.)

----
ZX31.LBR - CP/M
   CP/M program that includes an alphabetized (horizontally) directory
   listing, erase, unerase, scroll, type (forwards or backwards) rename,
   copy, a sector-oriented text editor, and other useful functions.  Re-
   quires a Z80 processor.  Library includes an extensive .DOC file.

----
ZWORD.TQT - General
   Richard Conn ('Mr ZCPR3') answers the four most asked Z-system questions.

----

 [ End of SEPTBEST.LST      Contact Seattle's `downspout' at 206-325-1325 for
   more details.   24 hours:  1200/2400 baud; 9am - 3pm [PST] 300 baud. ]
 1-Sep-86 16:54:42-MDT,1342;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 1 Sep 86 16:54:21-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a011453; 1 Sep 86 18:28 EDT
Date: Mon, 1 Sep 1986  16:16 MDT
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail], [e-mail]
Subject: Electronic Communication Privacy Act (S.2575) update

The latest version of the Electronic Communication Privacy Act
(S.2575), dated August 12, 1986, is now available from SIMTEL20,
thanks to Bill Bogstad <[e-mail]>, who added
them into the posting by Glenn Tenney.

Filename            Type     Bytes     CRC

Directory PD:<MISC.BBS>
PRIVCY2.BILL.1            ASCII     75835  4E46H

For those who can handle binary FTP transfers and unsqueeze:

Directory PD:<CPM.RCPM>
PRIVCY2.BQL.1            BINARY     45056  D16DH

Reviewing:

The Electronic Communications Privacy Act of 1986, which has passed the
House, now is a bill in the Senate (S.2575).  This one Act affects every
usenet, bitnet, bbs, shortwave listener, TV viewer, etc.

--Keith Petersen
Arpa: [e-mail]
uucp: {ihnp4,allegra,cmcl2,decvax,mcnc,mcvax,vax135}!seismo!SIMTEL20.ARPA!w8sdz
GEnie Mail: W8SDZ
RCP/M Royal Oak: 313-759-6569
 2-Sep-86 07:12:10-MDT,2686;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 2 Sep 86 07:11:50-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a016887; 2 Sep 86 8:00 EDT
Received: from (UZ32112)SG2.BITNET by WISCVM.WISC.EDU on 09/02/86 at
  07:01:44 CDT
Date: Tue, 02 Sep 86 14:00:23 ULG
To:  [e-mail]
From:  [e-mail]
Subject: NOTE from UZ32112

Date: 2 September 1986, 13:57:59 ULG
From: Andre PIRARD              [phone](449) UZ32112  at BLIULG12
      SEGI - Universite de Liege
      15, av. des Tilleuls
      B4000 LIEGE (Belgique)
      [e-mail]
To:   INFO-CPM at AMSAA
Subject: Commodore 128

[line eater bait]

I am the owner of a Commodore 128 and a 1571.
I bought it for its versatility and would not mind its slow speed if
there were no exageration and it were bug free. But it is not the case.
I would like to know if these problems show up on U.S. or recent machines
or does anyone have comments or cure for the following:


128 Mode:

-The DOS shell file copy function exhibits the stange behaviour of
adding one byte to the file being copied. Harmless for program files,
it is a nuisance for text files. I'd be glad to have a correction
for this otherwise very handy program.

-The 1571 is double sided and faster than the 1541... until I get to
filling side two. On that side, writing is VERY slow. The drive
alternately accesses the data and the directory sectors for EACH
sector being written. Looks like it reads and/or writes the BAM (block
availability map) for each sector. On side one, the directory is
accessed only between a group of records. The SAVE command does however
fill both sides without directory access. It only occurs during other
I/O's (e. g. program output or file copy).

-The capslock key has no effect on the letter Q.

CP/M mode:

-Is there a way to assign the printer logical unit to the user port to
a parallel printer?
-There is a device driver supposed to drive a 6251 rs232 chip. But the
128 has none. What is it there for? I would appreciate to do rs232 I/O
(not modem).
-There is an evident lack of keyboard buffering and auto repeat.
-The screen output is very slow (80 column).
-Commodore statement of a 4MHz Z80 is a very subtle lie. It DOES 4MHz,
but only HALF of the time (each other half cycle of a 2MHz clock).
Really 2MHz. Would they pay half time employees at full rate?
-The CPM+ makes ridiculous little use of the alternate memory bank for
I/O buffers.
-In other words, is there a better CP/M than the one we get with the
machine?

[These are not opinions, but facts]

 2-Sep-86 10:17:05-MDT,902;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 2 Sep 86 10:16:42-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a025220; 2 Sep 86 11:32 EDT
Received: from (MEK)UMASS.BITNET by WISCVM.WISC.EDU on 09/02/86 at
  10:33:26 CDT
Message-ID:  <860901174021.000001F4.ADSF.MA@UMass>
Date:     Mon,  1 Sep 86  17:40:21 EDT
From:  [e-mail]
Subject:  BYE510/C128/1670?
To:  [e-mail]

I'm trying to set up BYE510 on my C128 with 1670 modem.
I put in the proper insert, and have it running, except
when I type BYE E I get some information about the number of
calls, and then, continuously:

A
Echo error
A
Echo error

I assume this is something I'm doing wrong in the Modem configuartion
section.  What should the modem settings be for the 1670?  Thanks
in advance!

-Matt Kimmel,
[e-mail]
 2-Sep-86 13:06:42-MDT,602;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 2 Sep 86 13:06:27-MDT
Received: from nosc.arpa by AMSAA.ARPA id a000817; 2 Sep 86 14:16 EDT
Received: by bass.ARPA (5.31/4.7)
    id AA08308; Tue, 2 Sep 86 11:17:04 PDT
Message-Id: <[e-mail]>
Date: Tue, 2 Sep 86 11:00:28 PDT
From: Marc Wilson <crash!pnet01![e-mail]>
To: [e-mail]
Subject: Re: NOTE from UZ32112c

     Get yourself a copy of the newest CP/M system, dated 6 December 1986. It
addresses many of the problems you note, but adds a few new ones.
 3-Sep-86 05:14:50-MDT,1272;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 3 Sep 86 05:14:44-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a007475; 3 Sep 86 6:43 EDT
Received: from (SINGPANG)HLERUL5.BITNET by WISCVM.WISC.EDU on 09/03/86
  at 02:45:38 CDT
Date:
From:        [e-mail]
MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
Subject:  BITNET mail follows
To:  [e-mail]
X-Original-To:  [e-mail], SINGPANG

I am asking these questions on behalf of a friend all the way in
South America. The questions are about the Commodore 128
1. Is there a mailing list for the C128? If so can you give
   me the net address?
2. Are there any communication programs (eg. Kermit) for the C128?
3. Is there any way to read C64 disk files in C128 mode?
4. The same problem, but now reverse. Can I read C128 CP/M disk files
   in C64 mode?
5. Has anybody experience in using a modem with the C128?
   What modem is it and what communication program do you use?
6. Can I expect problems when buying generic CP/M 2.2 or 3.0 programs?
   How compatible is the Commoder CP/M version on the C128?

Thanks in advance.
Please mail to:
            [e-mail]
 3-Sep-86 05:25:17-MDT,1442;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 3 Sep 86 05:25:09-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a007566; 3 Sep 86 6:57 EDT
Received: from USENET by SMOKE.BRL.ARPA id a020229; 3 Sep 86 6:48 EDT
From: "The News System <news>" <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Date:
Message-ID: <[e-mail]>
Date: 3 Sep 86 10:48:33 GMT
To:       [e-mail]

From:        [e-mail]
MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
Subject:  BITNET mail follows
To:  [e-mail]
X-Original-To:  [e-mail], SINGPANG

I am asking these questions on behalf of a friend all the way in
South America. The questions are about the Commodore 128
1. Is there a mailing list for the C128? If so can you give
   me the net address?
2. Are there any communication programs (eg. Kermit) for the C128?
3. Is there any way to read C64 disk files in C128 mode?
4. The same problem, but now reverse. Can I read C128 CP/M disk files
   in C64 mode?
5. Has anybody experience in using a modem with the C128?
   What modem is it and what communication program do you use?
6. Can I expect problems when buying generic CP/M 2.2 or 3.0 programs?
   How compatible is the Commoder CP/M version on the C128?

Thanks in advance.
Please mail to:
            [e-mail]
 3-Sep-86 06:29:30-MDT,1041;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 3 Sep 86 06:29:18-MDT
Received: from mit-mc.arpa by AMSAA.ARPA id a008808; 3 Sep 86 7:46 EDT
Date: Wed 3 Sep 86 07:47:43-EDT
From: Mark Becker <[e-mail]>
Subject: Bondwell machine
To: [e-mail]
Message-ID: <[e-mail]>

Hello -

     I've seen several references on the net for a portable CP/M
machine going by the name of "Bondwell".  Who is selling these things
in the Maryland area?

     Also, some questions to those already owning this portable:

    Are schematics and tech info available?

    I believe there are two Bondwell machines - one runs CP/M 2.2,
    the other runs 3.0 .  True?

    How many and which of the CP/M utilities (ASM, PIP, ED, etc)
    are supplied?

    How much documentation is supplied?

    Is it bundled with any other software?

     If I get sufficient queries, I'll post a summary to the net.

Thanks -

Mark Becker
-------
 3-Sep-86 10:57:06-MDT,6150;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 3 Sep 86 10:56:35-MDT
Received: from nadc.arpa by AMSAA.ARPA id a012495; 3 Sep 86 9:23 EDT
Date: 3 Sep 1986 09:18:37-EDT
From: [e-mail]
To: [e-mail]
Subject: C128 info
Cc: [e-mail], [e-mail]
MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA

Reply to request from singpang%hlerul5.bitnet:

1. The only widely utilized mailing list for the C64/C128 is the USENET list
   called "net.micro.cbm".  This list is *not* gatewayed into the Arpanet.
   I have no idea if there is a USENET/BITNET gateway that passes this list.
   You can *submit* postings to "net.micro.cbm" by sending mail to
   [e-mail].  However, you cannot receive the postings
   because of the lack of a bidirectional gateway.  Therefore, if you do
   submit a posting that requires a reply, be sure to ask for a carbon-copy
   to be sent directly to your address.

2. There are many communications programs, including Kermit, for the C128 in
   C64 mode.  There are a few (no Kermit) for the C128 in native mode.  There
   are at least 3 (IMP, MEX, and Kermit) for the C128 in CP/M mode.  In short,
   there is no shortage of comm. programs - it's just a matter of finding
   the one you want.  All 3 CP/M programs are in the SIMTEL20 archives (I know,
   BITNET people can't get those yet, but in time.....).

3/4. C64 and C128 disks are virtually identical (there are two flavors, single
   sided and double sided, but with a 1571 drive, either machine can read or
   write either format).  There are currently bugs in the drive ROM which make
   it semi-pointless to use double sided with C64 or C128 mode.  CP/M disk
   formats are simply random accessed variants of the basic C128 double or
   single sided formats - the three possible MFM formats are documented in
   the (Commodore) C128 Programmer's Reference Manual, and with this knowledge,
   it is not tough reading or writing CP/M disk formats from non-CP/M modes
   (hint: use the U1 and U2 random access functions of the drive DOS).  On the
   other hand, CP/M cannot log in a non-CP/M formatted diskette, so reading or
   writing such from CP/M might be a hassle, if it is possible at all.

5. With the right communication software, a modem works great with the C128
   in any mode at 300 or 1200 baud.  The 128 has no UART, so there is so-called
   "bit-banging" code in both the ROM Kernal and in the CP/M BIOS to support
   receiving and sending bits at the right rate via internal clock interrupts.
   At 1200 baud, this eats up plenty of CPU time, but for general comm.
   functions (terminal emulation, uploading, downloading, capture buffer), this
   is no problem as long as the remote system can handle an occasional XON/
   XOFF flow control sequence.  I say "with the right communication software"
   because there are bugs in the Kernel ROM, so you cannot use the RS-232 port
   code by the book.  You have your choice of either a TTL/Commodore
   User Port compatible modem (from several manufacturers including Commodore),
   or an ordinary RS-232 modem.  If you use an RS-232 modem, you need level
   converters between the user port and the modem - Commodore and others sell
   such converters, or you can make your own.  I use an Andersen-Jacobson 1259
   RS-232 modem with homebrew (transistor even!) inverters.  I use IMP, MEX,
   and Kermit in CP/M mode, TERM.PLUS, Kermit, XMOBUF, and Punter programs in
   C64 mode.  The only semi-useful program I've used in 128 mode is called
   MicroVT-128 and it has not matured into a stable product yet.

6. C128 CP/M 3.0 is a very faithful implementation of banked CP/M 3.0 with a
   58K TPA.  You should be using the 6DEC85 or 8DEC85 versions to get the
   full benefit of bug fixes, RS-232 port support, and RAM expansion support.
   The only reason *any* CP/M 3.0 program would not run on the 128 would be
   that is was not configurable for the terminal emulation used by the 128
   BIOS, that is an ADM31 (almost).  Many CP/M 2.2 programs will work without
   any problem at all; in this case, any incompatibility (in addition to
   terminal emulation) would be in the form of 2.2/3.0 differences; fortunately,
   these are minimal since 3.0 was designed to be largely compatible with
   2.2, while adding new features.  One example of incompatibility is that
   some 2.2 "unerase" programs are confused by the volume header and/or time
   stamps of 3.0 and thus will not work.  But the vast majority of CP/M 2.2
   products seem to work just fine (try before you buy!).  The 1571 disk drive
   will sense (and cause the BIOS to adapt to) MFM diskettes formatted for the
   Osborn (SSDD), Kaypro II, Kaypro IV, Epson (something or other...), and
   IBM-PC CP/M-86, and possibly some others; consult the manual for details.

Beware, the 128, even in CP/M mode, is not without it's faults.  The Z-80 is
only running at 2Mhz., so don't expect the performance of a 6Mhz. system.
Screen updates are moderately slow (but not unusable - equivalent to somewhere
around 300 characters/second).  You should set the
baud rate down to 110 whenever you are not using the RS-232 port to minimize
interrupt processing overhead, and maximize *your* use of the CPU.  Diskette
reads (on a 1571 drive) are pleasingly fast (from MFM formatted diskettes), but
writes are quite a bit slower (there is a utility available which almost doubles
the write speed - much better).  40 column mode is almost useless (sideways
scrolling) for CP/M, so you better use an RGB or monochrome 80 column monitor.
And finally, ROM bugs in the 1571 drive make it nearly useless to try to use
double sided formatted diskettes in the non-CP/M modes (this has been fixed
by Commodore, but it is still not obvious how to get the new ROMS - new ROMS
are being used in newly manufactured units, but it would be hard to say if a
given drive on a dealer's shelf had the old or the new).

Sincerely,
Frank Prindle
[e-mail]
 3-Sep-86 21:45:09-MDT,767;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 3 Sep 86 21:45:03-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a010207; 3 Sep 86 23:08 EDT
Received: from (MEK)UMASS.BITNET by WISCVM.WISC.EDU on 09/03/86 at
  10:06:10 CDT
Message-ID:  <860903105954.000012D6.AFCB.MA@UMass>
Date:     Wed,  3 Sep 86  10:59:54 EDT
From:  [e-mail]
Subject:  Mailing list for C128
To:  [e-mail]

Yes, there is a general Commodore mailing list on the network.
Its address is:  [e-mail]
All requests to be added to or deleted from the mailing list should
be sent to: [e-mail]

-Matt Kimmel,
CBMList coordinator.

[e-mail]
 4-Sep-86 04:33:02-MDT,3189;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 4 Sep 86 04:32:46-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a011022; 4 Sep 86 5:47 EDT
Received: from USENET by SMOKE.BRL.ARPA id a012958; 4 Sep 86 5:40 EDT
From: Marc Lewert <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Re: Bondwell machine
Message-ID: <[e-mail]>
Date: 4 Sep 86 00:55:37 GMT
To:       [e-mail]

In article <[e-mail]>, [e-mail] (Mark Becker) writes:
>      Also, some questions to those already owning this portable:
>
>     Are schematics and tech info available?

I don't know, one would presume so, but I don't know where to get them.

>     I believe there are two Bondwell machines - one runs CP/M 2.2,
>     the other runs 3.0 .  True?

True.  The Bondwell Model 12 runs,CP/M 2.2, Model 14 (which I have) runs 3.0

>     How many and which of the CP/M utilities (ASM, PIP, ED, etc)
>     are supplied?

Quite a Few. PIP, ED, at least one macro assembler, I will have to make a list
and get back to you on that, but there is quite a bit of stuff

>     How much documentation is supplied?

Documentation is so-so.  Better in some areas than others.  The DDT
documentation is non-existant, the ED documentation is ok, I guess, the PIP
documentation seems complete.  One of the manuals is just on the CPM utiltities.
There is at least one page for each utiltiy, but it does not always cover all
that you need to know

>     Is it bundled with any other software?

Yes, Wordstar and Mailmerge (minus spelling checker), Calcstar, Datastar,
Reportstar.  All of these include manuals put out by Micropro.  No language
is included however.  I considered this a problem, but purchased Turbo
Pascal the next week.  The Bondwell 14 can read and write several different
disk formats including Kaypro II, and Osborne 1 double density, but cannot
format anything but it's own format.  I ended up getting a couple of disks
formated by an Osborne system and keep them for passing data to other systems.

The Bondwell is supposed to be a Kaypro II compatable system, and so far
it has been.  I have not bought much in the way of software (a spelling
checker, Turbo Pascal, Zork III, Right-Hand Man), but all was purchased
as if I were using a Kaypro II, and seems to work.  The only exception is
the Right-Hand Man, which I specified CP/M 3.0, and thinks there are only
24 lines on the screen (the screen is 25 lines X 80 Characters/line).

Please note all of the above is off the top of my head, and about a Bondwell 14.
I do not have any direct knowledge of the bondwell 12.
--
=========================================================================
Marc Lewert                           UUCP: ...hplabs!pyramid!triada!marc
Triad Systems Corp.
PO Box 61779                          MA Bell: [phone]
Sunnyvale, Ca. 94088-1779

Disclaimer:  All views are my own and do not reflect those of my
             employer, friends, or family unless otherwise noted.
=========================================================================

 4-Sep-86 04:45:12-MDT,1125;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 4 Sep 86 04:45:06-MDT
Received: from nosc.arpa by AMSAA.ARPA id a011173; 4 Sep 86 6:18 EDT
Received: by bass.ARPA (5.31/4.7)
    id AA27292; Thu, 4 Sep 86 03:19:03 PDT
Message-Id: <[e-mail]>
Date: Thu, 4 Sep 86 02:53:54 PDT
From: Matt Smiley <crash!pnet01![e-mail]>
To: [e-mail]
Subject: Re: C128 info/CP/M 3.0

Something else as to using CP/M and a modem...

You must have the December 6(?) overlay for your CP/M 3.0. The system included
with the machine is *not* capable of using a modem! This overlay is available
on Quantum-Link for sure, and possibly GENIE.

I have not used a 128 for over six months, however, and CBM may be including
the new version of CP/M with the machines by now. Surefire way to tell: Look
at the release date when you boot the system. If it's August, it's the old
one. The new one is dated December '85 or later.

I suggest you use IMP or MEX for your modeming. They are superior to anything I
have seen in the C-128 public domain world.
 4-Sep-86 08:53:22-MDT,972;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 4 Sep 86 08:53:01-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a018050; 4 Sep 86 10:12 EDT
Received: from (MAILER)UNBMVS1.BITNET by WISCVM.WISC.EDU on 09/04/86 at
  09:13:25 CDT
Date:        04 Sep 86 10:57:06 ADT
From:            [e-mail]
MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
To:  [e-mail]
Message-ID:  <ID47201.D860904.T105706.SEA@UNBMVS1>

Date/Time:    86/09/04  10:45 AST
From:         Steve Allain, University of New Brunswick, Canada
              [e-mail]
To:           Users of MULTIFLEX CPM 2.2

Is anyone out there familiar with the MULTIFLEX S-100 system (Z-80 CPU,
Floppy Controller, Video/Keyboard Card and MULTIFLEX CPM 2.2 )?
Before I order any software (on disk), I want to know which
types of 5-1/4 " disks it can read with the existing CBIOS -
eg. KAYPRO, OSBORNE...

 4-Sep-86 10:01:55-MDT,12639;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 4 Sep 86 10:01:12-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a019602; 4 Sep 86 10:55 EDT
Date: Thu 4 Sep 86 08:56:24-MDT
From: "Frank J. Wancho" <[e-mail]>
Subject: New Service Available!
To: [e-mail]
Message-ID: <[e-mail]>

This message marks an historic moment, and a bit of background history
which has brought us to this moment is in order.  Please bear with me
while you read this lead-in to details you have all been eagerly
awaiting at the end of this message.

Seven years ago this past Friday, August 29, 1979, INFO-CPM was formed
as a spin-off of INFO-MICRO, both homed at the time on MIT-MC.  The
following month Keith Petersen's Royal Oak RCP/M system was
discovered, and Keith was invited to directly participate in the
INFO-CPM discussions.  Through Keith's direct access, he was able to
upload, crudely at first, selected files for FTP from MIT-MC from his
vast up-to-date RCP/M collection.  As new files became available,
Keith made the announcements to the INFO-CPM list.  New contributions
and updates to existing files were likewise made available from other
ARPANET users.  Thus, the CP/M archives was born, with disk space
courtesy of the MIT-MC management.

This activity caused the development of several mainframe versions of
CP/M utilities, such as the first mainframe implementation of the
Christensen Protocol, in MacLisp, by Ed Barton, called LMODEM.  Then
Gail Zacharias developed MMODEM, USQ, HEXFIY, COMIFY, MAKLBR, DE-LBR
and others, some of which were modified for use on TOPS-20 systems.
Bill Westfield wrote the original and invaluable MODEM program for
TOPS-20, which has recently been overhauled into TMODEM.

Disk space was inherently limited on MIT-MC, and when the Macsyma
Consortium was dissolved at the end of September, 1983, SIMTEL20 at
White Sands Missile Range (WSMR) was already online and had disk space
to spare on the required 176MB RP06 boot disk.  (SIMTEL20 is a
contraction of the name of the branch which then owned the machine,
SIMulation and TELeprocessing, DECSYSTEM-20.)  During that month, the
CP/M collection was moved from MIT-MC to the RP06, designated as the
MICRO: structure, on SIMTEL20.  Already purchased for a closely
related project, the then named DARCOM Microcomputer Software Sharing
System (DMSSS), were the entire sets of the CPMUG, SIG/M, and PC/BLUE
distributions, which were uploaded as-is to MICRO:.  Since then we
managed to get placed on the tail end of the regional distribution of
both the SIG/M and PC/BLUE update sets which periodically extend both
of those collections.

As this was all going on, it became evident that a collection of
Unix/C versions of the CP/M utilities would be required and that
collection was started.  That collection has since come under the
sponsorship of another organization within the Army Materiel Command
(AMC) to which WSMR belongs.  That organization, Logistics Systems
Support Activity, LSSA, provided the funds for the 512MB disk drive
known as PD:, to which all the collections residing on the out-grown
MICRO: structure were moved in November, 1985.

In November, 1984, Rick Conn volunteered to start the extremely
popular Ada Software Repository, originally on PS: as there was no
room on MICRO:, and then moved to PD: when that device came online.

As with the CP/M archives in PD:<CPM.*> being considered the best and
most recent, the MSDOS archives are also in the process of being
similarly organized in PD:<MSDOS.*>, with files culled from the latest
releases of the PC/BLUE collection as well as the INFO-IBMPC
collections on ISI-B and Pete Galvin's collection on UTEXAS-20.

When the CP/M collection first started, there was only one directory
with subdirectories, and several not-necessarily CP/M-related
directories lived under that tree.  Recently, a new top-level
directory was created on PD:, named PD:<MISC>.  Now those generic
subdirectories in PD:<CPM.*>, PD:<UNIX.*>, and PD:<MSDOS.*> are being
moved to that new directory tree.

The original INFO-CPM list was maintained on MIT-MC until 1983 and
then moved to BRL, where it was maintained by Ron Natalie for a short
while.  Ron, who has been the maintainer of INFO-MICRO, among other
lists, drafted Dave Towson to maintain the INFO-CPM list on AMSAA.
Dave has been continuously maintaining the list since November 1983,
periodically rewriting and distributing the SIMTEL20 Archive Users
Guide, commonly referred to as the "Archive Blurb" and answering
numerous user requests for information on access to the SIMTEL20
collections.

As the subscription list to INFO-CPM grew, it was gatewayed into the
USENET community, first as fa.info-cpm, and now as a two-way
newsgroup, net.micro.cpm.  Later, members from other communities
joined the list from CSNET, BITNET, and others.  Meanwhile, new files
and entire collections were added to the SIMTEL20 archives and
announced to the INFO-CPM list.  Access to these files was inherently
limited to those with Internet FTP access to SIMTEL20, unless some
kind soul volunteered to mail selected files on request.

Recently, there was a flurry of messages pleading for some form of
automated access to the SIMTEL20 archives via net mail.  About two
weeks ago, while reading these pleadings while on travel in the
mountains of Colorado, I said that all the pieces were falling into
place to be put together to provide that service.  Maybe it was the
altitude that made me say that, but everything eventually did fall
into place in the two weeks since then.

A Mail File Server was written in C using a beta version of an about
to be released compiler for TOPS-20 systems.  If it wasn't for the
quick turnaround on reported bug fixes by the two principal
maintainers of that compiler and run-time library, Ken Harrenstien and
Ian Mackey at SRI-NIC, this program could not have been developed in
such a short time by a person whose only other claim to fame in C
programming is one other C program he co-authored two years ago.

The original concept for this service came from a similar service
developed by Jack Dongarra of the Argonne National Laboratory and Eric
Grosse of AT&T Bell Laboratories called NetLib, which is available
from ANL-MCS for mail access into its collection of well-indexed and
documented high quality public domain mathematical software routines.
Their work was supported, in part, by the National Science Foundation.
From their sources came that part of the package which extracts the
requestor's return address from the request file.

The SIMTEL20 version of this service has been in beta test for almost
two weeks now, with new features added and many bugs fixed since then.
While credits are being handed out, I wish to thank Matt Kimmel for
checking out access from the BITNET side, and Eric Hildum from the
USENET side.  And, to Keith Petersen, Dave Towson, Bernie Eiben, Rick
Conn, and Mark Crispin for participating in a lively discussion of the
principles of operation of this service.

Now, before I bombard you with details on how to access the files, let
me caution you that this system is experimental.  There is no such
thing as finding the "last" bug in any program.  Furthermore, I sit in
awe and fear that even selective and judicious use of this system by
the potential audience this message will eventually reach may overload
this machine or some of the fragile mail links between hosts on the
various networks connecting us all together.

This means that those of you already with FTP access to SIMTEL20 must
not use this service and continue using FTP.  There is no blocking
mechanism in place right now, but I will consider taking the time to
install one if you choose to ignore this request.  Those of you on
USENET, BITNET, and CSNET hosts should consider appointing one point
of contact through which you should funnel your requests and the
reconstructed files from the replies from this service should be made
available to all your local users.  This particularly applies to the
HELP, INFO, and BOOTSTRAP messages and the files they point to.

This message is being sent only to the readers of INFO-CPM so that we
can gauge the impact on the system.  Please do not redistribute this
message to any other mailing list or newsgroup.   Their time will come.

What follows is the message you get in response to the SEND HELP
command...

Enjoy!
Frank

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

           HOW TO ACCESS THE SIMTEL20 ARCHIVES VIA NET MAIL

To obtain one or more files by netmail from the public domain archives
kept on SIMTEL20.ARPA, send a message to:

[e-mail], or via uucp:
...!seismo!simtel20.arpa!archive-request
...!ucbvax!simtel20.arpa!archive-request
...!uw-beaver!simtel20.arpa!archive-request

The message body must contain lines beginning with the keyword SEND,
one SEND line for each file requested.  Case is not significant.

The general syntax of a SEND line is:

SEND format filename

In general, a filename consists of the following components:

device:<directory>file.type.generation

"device:" is usually PD:, and the combination of PD:<directory> is
expected unless an alias has been advertised of the form "alias:",
which takes the place of both device and directory fields.  The
generation field may be left off and defaulted to the highest
generation number.  "file.type" follows the usual filenaming
conventions.

In all formats listed below, if the file to be sent is larger than
55K, the file is sent in numbered parts.  The parts must be
reassembled in order and edited to remove any headers, preface, and
trailers before the process can be reversed to reconstruct the
original file.

Allowable formats are:

SEND HELP
    This file you are reading now.

SEND INFO
    A detailed description of the SIMTEL20 Archives, which
    includes this file, pointers to certain key files, and
    descriptions of various file transfer programs and related
    utilities.

SEND BOOTSTRAP
    A brief quick reference listing of filenames of the key
    utilities used to reconstruct files sent by the compression
    and encoding techniques listed below.

SEND DIR filespec
    This format returns a CRC list of the requested files, and is
    the only format which allows wildcard filenames (but not
    wildcard directory names).  The list is sent as an ASCII text
    file.  The wildcard characters are "*" and "%".  The asterisk
    means any number of characters, while the percent sign means
    exactly one character.  Either or both may appear in any
    combination in either or both the file or type fields, while
    only the asterisk may appear in the generation field.

SEND RAW filename
    If the file is ASCII, it is sent as-is, regardless of size.
    This format is the least efficient over network and mail
    gateway resources.  Use this format only if you absolutely
    must to get yourself bootstrapped.  Then please use one of the
    other formats listed below.

With the four formats listed below, if the file is ASCII and under 25k
characters, it is sent as-is, as if RAW format was requested.  Binary
files are always processed according to the requested format.
However, a request for ARC or SQ processing of files with type .ARC,
.LBR, or .%Q% is ignored and the original file is either uuencoded or
hexified (if possible), according to the requested format.  If the
file was not sent RAW, a short preface is inserted at the front of the
message describing the process actually taken and a CRC entry
describing the original file.

SEND ARE filename  or  SEND filename
    The original file is made into a uuencoded ARC file.

SEND ARH filename
    The original file is made into a hexified ARC file if the ARC
    file is under 64K bytes long.  Otherwise, an apology is
    returned instead of the requested file.

SEND SQE filename
    The original file is made into a uuencoded SQueezed file.

SEND SQH filename
    The original file is made into a hexified SQueezed file if the
    Squeezed file is under 64K bytes long.  Otherwise, an apology
    is returned instead of the requested file.

To get started in finding your way around the SIMTEL20 archives, send
another request: SEND INFO

The ARCHIVE-REQUEST address is serviced by a batch job that
reschedules itself one hour after it completes the current pass.  That
frequency is subject to change.
====================
-------
 4-Sep-86 12:01:51-MDT,664;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 4 Sep 86 12:01:44-MDT
Received: from ll.arpa by AMSAA.ARPA id a023413; 4 Sep 86 13:19 EDT
Date: Thu 04 Sep 1986 13:15:15 EDT
From: [e-mail]
MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
Subject: Peter Kendell's Address
To: [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>

I still have heard nothing from Peter Kendell, whose request for
information got swallowed up in a system crash here.  Peter, are you
out there?  My mailing address is Jay Sage, MIT Lincoln Lab, PO Box 73
Lexington, MA 02173-0073 USA.


 5-Sep-86 04:10:46-MDT,1131;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 5 Sep 86 04:10:37-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a005142; 5 Sep 86 5:32 EDT
Received: from USENET by SMOKE.BRL.ARPA id a005346; 5 Sep 86 5:30 EDT
From: Dustin Clampitt <[e-mail]>
Newsgroups: net.micro.apple,net.micro.cpm
Subject: Re: Home Accounting?
Message-ID: <[e-mail]>
Date: 3 Sep 86 18:49:03 GMT
To:       [e-mail]

In article <[e-mail]>, [e-mail] (Kee Hinckley) writes:
>
> I highly recommend "Time is Money (personal)" from Turning Point Software
> (11A Main St., Watertown, MA 02172).  It's easy, it's quick and it's.........

.......not available for CP/M.  I just called them, this product is for apple
and IBM only.

I need a product like this (home accounting) for cp/m or zcpr3/zrdos.  Please
mail me any suggestions you might have.

Thanks, Dustin Clampitt


--

Dustin Clampitt  "Is it Saturday yet?"         ..!decvax!linus!axiom!lpi!jdc

[][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][][]
 5-Sep-86 04:14:47-MDT,1242;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 5 Sep 86 04:14:28-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a005195; 5 Sep 86 5:46 EDT
Received: from USENET by SMOKE.BRL.ARPA id a005506; 5 Sep 86 5:35 EDT
From: David Shanks <[e-mail]>
Newsgroups: net.lang.f77,net.micro.pc,net.micro.cpm
Subject: Fortran compiler quality query
Message-ID: <[e-mail]>
Date: 2 Sep 86 20:36:47 GMT
To:       [e-mail]

Can anyone out there tell me anything good or bad about the Utah Fortran
compiler from Ellis Computing that I see advertised in Byte?  This compiler
(along with compilers for Cobol and Pascal, and intrepreters for Basic and
Pilot) is advertised at $39.95. Normally I'd guess that it's a low quality
product (you usually get what you pay for) but this company has been around
for several years marketing the same thing for CP/M (called Nevada Fortran).
I also know that there ARE some good quality compilers out there for a low
price.  Does anyone know if this is one of them?  Thanks.

--
Dave Shanks             ..!tektronix!tessi!atelabs!cds
AT&E Laboratories
1400 NW Compton  Suite 300
Beaverton, OR  97006
[phone]
 5-Sep-86 06:47:18-MDT,1276;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 5 Sep 86 06:47:07-MDT
Received: from mitre.arpa by AMSAA.ARPA id a007440; 5 Sep 86 8:17 EDT
Full-Name: Jeff Edelheit
Organization: The MITRE Corp., Washington, D.C.
Return-Path: <edelheit@mitre>
Received: from localhost by ernie.mitre.org (2.2/SMI-2.2)
    id AA13566; Fri, 5 Sep 86 08:19:43 edt
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Home Accounting?
In-Reply-To: Your message of 3 Sep 86 18:49:03 GMT.
             <[e-mail]>
Date: Fri, 05 Sep 86 08:19:21 -0500
From: [e-mail]

Dustin - If you are interested in tracking expenses by user-defined
catagories, just grab any dbms (like dBase) and set up a few fields like
ck. no., date, payee, amount, and catagory.  Once your check register(s)
are loaded, you can just sum by catagory.

I have been doing this for about 5 years and it works like a champ.
(The only problem comes up when my wife says things like "We spent
HOW MUCH at the supermarket last year!!!???")

Regards,

Jeff Edelheit           ([e-mail])
The MITRE Corporation,  1820 Dolley Madison Blvd.
McLean, VA  22102       [phone]
 5-Sep-86 09:21:21-MDT,1331;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 5 Sep 86 09:19:55-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a011867; 5 Sep 86 10:30 EDT
Received: from (FISHER)RPICICGE.BITNET by WISCVM.WISC.EDU on 09/05/86
  at 09:31:32 CDT
Date: 5 September 86 10:30-EST
From:  [e-mail]
To:  [e-mail]
X-Acknowledge:
Subject: BITNET mail follows

Date: 5 September 1986, 10:19:08 EAS
From: FISHER at RPICICGE
To:   INFO-CPM at AMSAA.ARPA

Re:   Previous request-for-information about P2DOS

Many thanks to the those who responded.  As pointed out by "Bernie
<[e-mail]>" my only real problem was that the .COM file
created using the utilites provided in the .LBR is just a touch to
large.  A LOAD/SAVE 14 restores the file to its actual and proper
size.  After that it suddenly worked just fine....

...Well, almost:  If others attempt to install P2DOS, be forwarned
that as distributed the search path table is stored at 0040H
and following.  This area is designated as reserved for BIOS use
(not for the BDOS).  So, confirm first that your BIOS does not use
this scratch area or move the search path table elsewhere.  (My H89
BIOS--vanilla from Heath--does use it :-)

John S. Fisher    [e-mail]

 5-Sep-86 19:48:11-MDT,830;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 5 Sep 86 19:17:44-MDT
Received: from xerox.arpa by AMSAA.ARPA id a000498; 5 Sep 86 20:40 EDT
Received: from Burger.ms by ArpaGateway.ms ; 05 SEP 86 15:15:36 PDT
Sender: [e-mail]
Date: 5 Sep 86 13:02:13 PDT (Friday)
Subject: Re: C128 info
From: [e-mail]
To: [e-mail]
cc: [e-mail], [e-mail],
    [e-mail], [e-mail]
In-Reply-to: prindle%nadc:ARPA:Xerox's message of 3-September-86
 (Wednesday) 7:29:27 PDT
Message-ID: <860905-151536-1257@Xerox>

Can somebody tell me all the CP/M formats (double sided as well as
single sided) the Commodore 128 will read and convert to run.

Larry
 5-Sep-86 21:34:45-MDT,7571;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 5 Sep 86 21:34:17-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a000796; 5 Sep 86 22:40 EDT
Date: Fri, 5 Sep 1986  19:55 MDT
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: Assembling SYSLIB with ZAS and Z80ASM (SLR)
Reply-To: [e-mail]

Relayed from my RCP/M...I've had complaints from users about not being
able to assemble the new SYSLIB, Z3LIB and VLIB wihout purchasing the
ZAS assembler.  It used to be possible to use M80/L80.  This file
tells about one alternative.

--Keith

--cut here--ZAS-SLR.DOC--cut here--
                ASSEMBLING SYSLIB WITH ZAS AND Z80ASM (SLR)

                                  Jay Sage
                             September 4, 1986


     I was moved to write these comments after reading Richard Conn's
article on the libraries (SYSLIB, Z3LIB, and VLIB) in Micro/Systems Journal.
In that article he states that ZAS is the only assembler that is capable of
assembling the new version 3.6 release of SYSLIB.  This statement seemed
both odd and self-serving, odd because ZAS is always promoted as being
compatible with other standard assemblers and self-serving because Conn is
now an employee of Echelon, which distributes ZAS.  I began to do a little
investigating.

     Please understand that I am generally a strong supporter of Echelon,
the company marketing the Z-System and its support programs.  They are, I
believe, the last hope for 8-bit CP/M-type computers, and we should support
them by buying their products and encouraging our friends to do the same.
However, ZAS has been a sticking point for me.  I formed a less than
enthusiastic opinion of ZAS at the beginning and tried to help the author
make an honest Z-System program out of it.  Unfortunately, its subsequent
development has done nothing to change my original opinion (more on that
below).  Once the superbly written, high performance assembly-language tools
from SLR Systems became available at a comparable (slightly higher) price, I
saw no reason to settle for the mediocrity of ZAS.  If Conn had said in the
article that the SYSLIB source was written to be assembled using ZAS and
might require slight modifications for other assemblers, I would not be
writing this comment.

     I found it hard to believe that Z80ASM would have any significant
problem assembling SYSLIB, so I gave it a try.  The complete assembly of 189
source modules to Microsoft-format REL files took only 11 minutes and 25
seconds on my Ampro floppy-based system, an average of 3.6 seconds per
module (considering the tremendous disk thrashing required to read 189
source files and write 189 REL files, things would have been much faster
with a hard disk).

     It turned out that very strictly speaking Conn was right.  There were
five files, the ones dealing with library management (SLUDIR, SLUOPEN,
SLUCLOSE, SLUREAD, and SLUINIT), that produced error messages.  The reason
was their use of ZAS's idiosyncratic ".IN" insert pseudo-op.  If one spends
a moment with a text editor and changes the five instances of ".IN" to
".INCLUDE", then Z80ASM works beautifully.  Knowing Steve Russell of SLR, I
would not be surprised if the next version of Z80ASM recognizes the ".IN"
pseudo-op.  It already tolerates ZAS's peculiar requirement of square
brackets where other assemblers use normal parentheses.  Changing ".IN" to
"MACLIB" and putting in the ".Z80" directives might even make M80 work (I
did not try that).  If anyone reading Conn's comment thought that he should
buy ZAS just to be able to work with the SYSLIB source code, he was
seriously misled.  I am sure that almost any assembler using Zilog mnemonics
can be made to work with very little effort.  Since the code appears to use
no Zilog-only instructions, one could probably even convert the source back
to the Intel mnemonics in which Conn wrote the original routines and use an
Intel assembler.

     Having gone through the assembly process with Z80ASM, I was now curious
to see how ZAS would perform.  I got out a copy of ZAS version 2.3.  Since
ZAS does not support internal script files and multiple assemblies as Z80ASM
does, I prepared a ZEX script file to perform the task.  At first I wrote
the script to invoke ZAS for each module.  Then it occurred to me that it
was unfair to force ZAS to reload for each module when Z80ASM only had to
load once.  So I decided to use the ZCPR "GO" command for all but the first
module.

    For some reason I decided first to make sure that ZAS could be rerun
using "GO", as Z-System programs generally should.  I tried it manually on a
pair of files with the command line "ZAS FILE1;GO FILE2".  It seemed to work
fine.  I ended up with two appropriately named REL files, but something
about the ZAS output message made me suspicious -- both files were reported
as having the same number of lines, symbols, etc.  Sure enough -- ZAS messed
up.  It gave the appearance of working but in fact did not, the worst kind
of failure.

     I don't know exactly what ZAS is doing, since the second output REL
file did not correspond to either the second or the first source file.  One
thing is for sure.  The author of ZAS still does not fully understand the
principles of Z-System programming.  [My first disillusionment with ZAS came
when I tried for many months to get the author to make it support the ZCPR3
program error flag (I even sent the code to do it).  Steve Russell grasped
the principle immediately and implemented it quickly and correctly; he even
made the logical extensions of the concept to CP/M3 (set CP/M3 error flag)
and CP/M2.2 (kill $$$.SUB submit file).]  ZAS apparently relies on the
initial loading of ZAS.COM from disk to initialize some data space.
Programs that are to work under the "GO" command must, obviously, perform
all required initializations in code.  Otherwise the buffers, flags, and
file control blocks will not necessarily be in their initialized state when
the program is rerun using "GO".

     With a ZEX script that reloaded ZAS for each assembly (I had no
choice), ZAS took 43 minutes and 30 seconds to assemble SYSLIB, nearly four
times as long as Z80ASM.  Carrying out the five source changes to make
SYSLIB compatible with other assemblers, including Z80ASM, would take much
less than the 22-minute time difference.

     One final note on the SYSLIB code itself.  There are some unfortunate
inconsistencies in the code due to reliance on the truncated external
references of the Microsoft REL format.  The SLR assemblers can optionally
generate special SLR-format REL files (only the SLR linker can process
these) that, among other advantages, support 16-character external names.
When assembling SYSLIB to SLR-format REL files, however, one discovers that
the external and internal names of some routines in SYSLIB are not
consistent.  The module S0FILEIO.Z80 makes reference to the externals
"FI$CLOSE" and "FO$CLOSE".  However, the module SFILEIO, which defines these
references, specifies the public names as "FI$CLOS" and "FO$CLOS".  With
Microsoft truncation of externals to 6 or 7 characters (I don't know which
ZAS does), these are equivalent.  In making the SLR versions of the
libraries (SYSSLR.REL, Z3SLR.REL, and VSLR.REL), I had to correct these
inconsistencies.
 6-Sep-86 14:36:20-MDT,7885;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 6 Sep 86 14:36:00-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a003337; 6 Sep 86 15:38 EDT
Date: Sat 6 Sep 86 13:39:33-MDT
From: Rick Conn <[e-mail]>
Subject: Some data on ZCPR 3.3
To: [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>

    The New Z System
    by Richard Conn, 6 Sep 1986

    I have been working quietly on the development of the new Z System
for quite some time, and I feel that I must speak out now on what I am doing
so that people will know the true story.  This presentation is short and not
complete, but it is enough to answer some basic questions without taking too
much of my time away from the development activities.


Why create a new Z System?
--------------------------
    First of all, why am I creating a new Z System?  There are many
reasons:
        1) I have studied the old Z System for over two years now,
reviewing it for flaws and weaknesses.  From the beginning, I have stated
that the Z System is evolutionary, and I have enough new ideas now to implement
the next step in this evolution.
        2) I have been learning many new things about other
environments, including Ada Programming Support Environments (APSEs),
UNIX, SUN window-based systems, TOPS-20, VAX/VMS, and Symbolics workstations.
I have seen many good ideas that I would like to incorporate into my
personal computer environment, the Z System.
        3) My next real goal is the development of a banked Z System
followed by a multitasking Z System.  An improvement in the current non-banked
Z System is a logical step along the way, giving me a platform from which to
experiment with some of the new ideas before fully incorporating them into
the new systems.  ZCPR 3.3 is not a goal, but is a milestone along the road
to a goal.
        4) My needs have changed and are continuing to change, and
the old Z System no longer meets my needs.  I have to change the system in
order to continue advancing toward my other goals.

    At a recent talk I gave at the Trenton Computer Festival, someone
asked me if I plan to move over to the IBM community.  If I was motivated
by profit to a large extent, my answer would obviously have been yes.  But
my principal motivation is to learn and grow and to have fun doing it.  The
money is a very nice side effect, but it is not the driving side effect.
I definitely intend to keep learning through the Z System.  The Z System,
coupled with the very rich computer environment I am accessing through
my communications system, has enough potential to meet my needs for many
years to come.


New Standards
-------------
    Good software engineering principles and common sense indicate that
a lot of benefit can be derived through standards.  The evolving ZCPR 3.3
and Z System now have a number of standards going for them:

        1) a common language, implemented by the ZAS assembler
        2) a common support library, implemented by SYSLIB, Z3LIB,
            and VLIB
        3) a common format for all assembly language programs,
            implemented by PPAL - the Pretty Printer for
            Assembly Language
        4) a common operating system and support base, implemented
            by ZCPR3 and ZRDOS
        5) a common documentation format which allows easier
            upgrading of the documentation as the programs
            change; this system is for both hardcopy (MAN)
            and online (HELP) mediums
        6) a common configuration management system, CONFIG,
            which allows users to easily identify their
            configuration and determine if all of their
            programs are current
        7) page-relocatable structures for system segments,
            ZCPR 3.3 itself, and ZRDOS, which server to
            further support transportability and make
            installation easier
        8) a very robust communications protocol, supporting
            packet sizes from 1 data byte to 4K data bytes

    You will see all of these in the months to come.


The Libraries
-------------
    One key point to make here is that I purposely did not mention
a common binary structure, like the Environment Descriptor.  The Environment
Descriptor is not a standard, but the interface to it, namely Z3LIB and VLIB,
is.  This was purposely done so that future growth would be supported.
As the Z System evolves, it will probably be necessary to delete old features
which are no longer needed in favor of new features which provide new
capabilities.  If the binary structures, like the Environment Descriptor,
are to preserved, then the growth will be hampered by the lack of availability
of space in which to implement the new features.  By standardizing on the
interface to the Environment Descriptor and not the structure of the
descriptor itself, then the Environment Descriptor can take any desired form
without concern for the impact on other programs.  Specifically,

        ld    hl,envadr    ; get base address of env
        ld    de,offflag    ; get offset to a flag
        add    hl,de        ; point to the flag
        ld    a,(hl)        ; get the flag value

would be severly impacted if the structure of the Environment Descriptor
changed, but a call like:

        ext    getflag        ; reference library routine to get flag
        ...
        call    getflag        ; return flag in A

would not be impacted at all by such a change.  The library containing the
GETFLAG routine would be impacted, but it is a lot easier to change one
module in a library and reassemble 100 programs than it is to track the
necessary changes in, edit, and then reassemble 100 programs.

    With one exception, the routines in the new Z3LIB for ZCPR 3.3
have the same names and interfaces as the routines in the old Z3LIB.
Conversion is simple - reassembly is all that is required.

    Unfortunately, many programmers have not yet learned this lesson.
They continue to write code which does not use the libraries.  Imagine
the work that will be required to go through their programs, modifying the
references in order to be compatable with the banked ZCPR3.  Imagine them
going through the work again for the multitasking ZCPR3, and again and again
as ZCPR3 continues to evolve.  Thanks to Echelon, ZCPR 3.3 is still
compatable at the binary level in terms of the Environment Descriptor.
Certain values have been replaced with others, so changes will still be
necessary, but many of the key values have stayed in the same places with
the same meanings.  My original approach was to free up all of the dead
space left by the removed values, making more room at the end for growth,
but Echelon convinced me that the impact on programs written by those who
didn't understand the basic principle of the libraries would be devastating.
Thanks to the new design, it only took me 3 hours to convert back with no
loss of functionality -- yet another benefit from the new structured design
of the system -- but I can guarantee that the future systems will not be
converted in this manner.

    If everyone starts thinking in terms of the libraries, the future
growth of the Z System is assured.  If people cling to the old ideas of not
using the libraries, then it is clear that growth will be curtailed.


The Bottom Line
---------------
    I am moving forward with the development of the new ZCPR 3.3 and
the new Z System.  As you can see, there are many changes in it, and I have
barely skimmed the surface.  I will move ahead and release it only when I am
satisfied that it is usable to others.  Documentation must go with the
release, so the release will not take place until the documentation is ready.
My goal is to meet my needs, as outlined above, and this goal will be met.
I thank those of you who have been supportive in the efforts of Echelon and
myself, and I sincerely hope that you will share in my enthusiasm for the
new ZCPR 3.3 when I release it to you.

                    Rick Conn

-------
 6-Sep-86 15:12:56-MDT,5971;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 6 Sep 86 15:12:39-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a003332; 6 Sep 86 15:37 EDT
Date: Sat 6 Sep 86 13:38:42-MDT
From: Rick Conn <[e-mail]>
Subject: Response to Sage's comments
To: [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>

    ZAS (from Echelon)/Z80ASM (from SLR), and the Z System Libraries
        by Richard Conn, 6 September 1986

    Jay Sage's recent comments in the file ZAS-SLR.DOC are understood,
although somewhat in error, and I feel that it is necessary to clarify my
position on the subject.

    First, as Jay admits, there are no errors in the article.  ZAS is
the only assembler (to my knowledge and his) that can assemble the libraries
without error at this time.  Granted, I'll take Jay's word for it that five
library modules (LUDIR, LUOPEN, LUCLOSE, LUREAD, and LUINIT) can be modified in
a minor way to allow Z80ASM to assemble them.  What Jay doesn't know is that
the new Z3LIB requires all 70+ modules to be edited and reassembled in order to
use the SLR assembler with them.

    Second, Jay is totally wrong and uninformed about my relationship
with Echelon.  I am not an employee of Echelon and have never been an
employee of Echelon.  I receive royalty checks from Echelon for the sale
of my books and software and I work closely with them.  The sale of ZAS
has no impact whatsoever on my income.  Obviously, the sale of the libraries
does, since the libraries constitute a product line of which I am the author.
I really resent Jay's insinuations and feel they reflect very poorly on him.

    Third, ZAS is the only assembler I use today.  I use it for the
following reasons: (1) it meets my needs, (2) it represents a standard
language that Echelon and I have some influence on, (3) it is reliable
in the way I use it, and (4) it is supported.  I have been an advocate of
Ada for many years now, and the reasons for my love of Ada include the same
reasons given in the previous sentence (with the exception that I don't
have as extensive influence on the development of Ada as I do of ZAS).  I
have seen the benefits of having a standard language and am completely sold
on them.  Among many other reasons, having a standard language like ZAS
allows us to change the language definition as our needs change, and I
definitely have such changes in mind for the future.

    Fourth, I have nothing whatsoever against SLR or any other
company or its products.  I have heard others say that the SLR tool is
a fine tool, and I have no reason to doubt such a statement.  I have
never used the SLR Z80ASM tool, but this may change since SLR contacted
me and wanted to send me a copy.

    Fifth, we are not at an impass.  Taking a lesson from the Ada
community, we see Ada as a standard language with over 50 different compilers
for it.  All of these compilers implement the same language, which means
that there are no subsets or supersets, and I can write an Ada program on
any computer using any one of these compilers and port this program to
any other computer using any other of these compilers.  Porting the program
amounts to placing the source code on the target system, compiling, and
running.  No change to the source code at all.  But these compilers are not
all identical.  Some are faster than others, some generate more efficient
code than others.

    I want to see the same thing happen in the Z System community.
Any source code program can be ported to any Z System machine and assembled
with the standard assembly language.  This was my goal in standardizing on
ZAS from the beginning.  Echelon will soon be offering an implementation of
C, which I haven't seen yet, but if it meets the four requirements outlined
above, I imagine that I will adopt it in the same way.

    This action does not close the Z System market in any way, just like
Ada did not close the compiler market.  The vendors who wanted a piece of
the Ada action simply (actually, after enormous investments) marketed their
own Ada compilers which were validated.  Validation meant that each compiler
was approved by the US Government Ada Joint Program Office after passing
through a suite of over 4000 tests to assure that it compiled Ada programs
with no supersets or subsets.  This test suite was not exhaustive, and some
minor differences exist in the compilers, but the test suite is under
constant revision to make it progressively better.

    Echelon supports something called the "Z Team", which is a
team of people developing products for the Z System.  The authors of ZAS,
DSD, ZDM, the new C compiler, etc., as well as myself are on this team.
We receive our own mailings from Echelon as a team and are kept up to
date with each other's activities.  We also receive internal data on what
Echelon is up to.  I understand that Echelon and SLR, which is the subject
of this particular message, discussed the possibility of SLR joining the
Z team (ie, Echelon carrying their product), but an agreement was
not reached.  The Z Team works well together overall.

    If SLR or any other company wants to join in Echelon's adventure
with the Z System, there is no reason that yet another team, one concerned
with the Z System standard language (which is now ZAS only) and other
details of the Z System development, can be formed.  It is not appropriate
to use the Echelon Team for this purpose, since companies that may be
competators of Echelon may be involved.  The Z System as a standard
goes beyond specific companies.

    With a standard language, call it ZA, then ZAS and Z80ASM could
become products which compete with each other fairly and we could still
have ONE language for the Z System.  One language is what I want, and
I don't care if it is just ZAS or a group of assemblers made by a group
of companies.

-------
 6-Sep-86 15:34:07-MDT,1484;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 6 Sep 86 15:34:00-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a003524; 6 Sep 86 16:05 EDT
Date: Sat 6 Sep 86 14:07:19-MDT
From: Rick Conn <[e-mail]>
Subject: New files in ZSYS
To: [e-mail]
Message-ID: <[e-mail]>

    Thanks to Keith for uploading most of them.


   PD:<ZSYS.NEW>
          Bytes(SZ)

 AUTOZINS.CCP.1   1420(7)    -- also in PD:<ZSYS.ZSIG>
 DU312.LBR.1      64896(8)   -- also in PD:<ZSYS.ZCPR3>
 PPAL.DOC.1       11755(7)   -- also in PD:<ZSYS.DOC>
 VF41.IQF.1       11008(8)   -- also in PD:<ZSYS.ZCPR3>
 VF41H.LBR.1      27776(8)   -- also in PD:<ZSYS.ZCPR3>
 ZAS-SLR.DOC.1    7613(7)    -- also in PD:<ZSYS.DOC>
 ZAS-STD.DOC.1    5564(7)    -- also in PD:<ZSYS.DOC>
 ZHELPR16.RQS.1   2688(8)    -- also in PD:<ZSYS.DOC>
 ZSTD.DOC.1       7484(7)    -- also in PD:<ZSYS.DOC>


    AUTOZINS.CCP is about modifying the old ZCPR 3.0 to install Z3
tools it loads; this will be unnecessary with ZCPR 3.3
    DU312.LBR and VF41H.LBR and new versions of DU3 and VFILER
    PPAL.DOC is short doc on PPAL (Pretty Printer for Assembly
Language) for the beta testers
    ZAS-SLR.DOC  is Jay Sage's message in response to my article
in Microsystems
    ZAS-STD.DOC is my response to ZAS-SLR.DOC
    ZSTD.DOC is some information on the new ZCPR 3.3
    ZHELPR16 is the latest list of Z System helper volunteers

-------
 6-Sep-86 15:55:07-MDT,1467;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 6 Sep 86 15:55:00-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a003654; 6 Sep 86 16:53 EDT
Date: Sat 6 Sep 86 14:41:14-MDT
From: Rick Conn <[e-mail]>
Subject: New file in ZSYS
To: [e-mail]
Message-ID: <[e-mail]>

    Sorry if this is a repeat ...

   PD:<ZSYS.NEW>
          Bytes(SZ)

 AUTOZINS.CCP.1   1420(7)    -- also in PD:<ZSYS.ZSIG>
 DU312.LBR.1      64896(8)   -- also in PD:<ZSYS.ZCPR3>
 PPAL.DOC.1       11755(7)   -- also in PD:<ZSYS.DOC>
 VF41.IQF.1       11008(8)   -- also in PD:<ZSYS.ZCPR3>
 VF41H.LBR.1      27776(8)   -- also in PD:<ZSYS.ZCPR3>
 ZAS-SLR.DOC.1    7613(7)    -- also in PD:<ZSYS.DOC>
 ZAS-STD.DOC.1    5564(7)    -- also in PD:<ZSYS.DOC>
 ZHELPR16.RQS.1   2688(8)    -- also in PD:<ZSYS.DOC>
 ZSTD.DOC.1       7484(7)    -- also in PD:<ZSYS.DOC>


    AUTOZINS.CCP is about modifying the old ZCPR 3.0 to install Z3
tools it loads; this will be unnecessary with ZCPR 3.3
    DU312.LBR and VF41H.LBR and new versions of DU3 and VFILER
    PPAL.DOC is short doc on PPAL (Pretty Printer for Assembly
Language) for the beta testers
    ZAS-SLR.DOC  is Jay Sage's message in response to my article
in Microsystems
    ZAS-STD.DOC is my response to ZAS-SLR.DOC
    ZSTD.DOC is some information on the new ZCPR 3.3
    ZHELPR16 is the latest list of Z System helper volunteers

-------
 6-Sep-86 16:29:51-MDT,12439;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 6 Sep 86 16:29:19-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a003380; 6 Sep 86 15:40 EDT
Date: Sat 6 Sep 86 13:42:02-MDT
From: Rick Conn <[e-mail]>
Subject: Some info on PPAL
To: [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>

    The following is the documentation now being used by PPAL's
(PPAL = Pretty Printer for Assembly Language) beta testers.  I don't know
when or how PPAL will be released yet, but PPAL is working fine right now.
I ran it on all of Z3LIB the other day without any problems.

        Rick

;%BEGIN 0
;%Program: PPAL
;%Author: Richard Conn
;%Version:
VERS    equ    2
;%Date: 3 Sep 1986
;%Revision History:
;1. 1 Sep 86, Richard Conn
;    Initial beta-test release
;2. 3 Sep 86, Richard Conn
;    Fixed Z3INS compatability problem
;    Created LSy option to control colons after labels of MACRO, SET,
;        and EQU
;    Placed IF/ELSE/ENDIF at same indentation level
;    Change Iy option to IIy option
;    Added IMy option for MACRO/ENDM indentation
;    Added directives I+ and I- for manual increment and decrement of
;        indentation level
;    Fixed input line counting problem
;%Invocation: PPAL file_list [directive_list]
;%Index: Pretty Assembler
;%Index: PPAL
;%Index: Pretty Printer
;%Description:
;    PPAL is a Pretty Printer for Assembly Language for the Z System.
;Its purpose is to reformat assembly language source programs in order to
;have all Z System programs conform to a standard structure.  PPAL is highly
;configurable, accepting directives from both the command line and the source
;code itself, so that PPAL may be used to format programs in different ways
;for a variety of standards.
;    Directives for specific configuration of the pretty printing process
;may be presented on the command line or within the body of the code in
;special comment lines, beginning with ";#".  The following directives are
;recognized.  In each general case (like, Au), the first letter indicates the
;directive name, and the following letters indicate types of characters which
;may be specified; specifically:
;        o - option chars specific to the directive
;        u - case indication, U for Upper-case, L for Lower-case,
;            X for unchanged
;        y - yes/no indication, Y for Yes, N for No, X for unchanged
;
;    Au - controls the case of operands (arguments)
;        AU makes non-quoted alphabetic argument characters upper-case
;        AL makes non-quoted alphabetic argument characters lower-case
;        AX leaves the case of argument characters unchanged
;    By - remove blank lines
;        BY (yes) turns on removal of blank lines
;        BN (no) turns off removal of blank lines
;        BX (unchanged) is the same as BN
;    Cou, Coy - comment line formatting (a comment line is a line beginning
;        with a semicolon, as opposed to an embedded comment)
;        CWy controls removal of the space character after the
;            semicolon
;            CWY (yes) removes the space after the semicolon if a
;                      space is present, else no change
;            CWN (no) inserts the space after the semicolon if no
;                     space is present, else no change
;            CWX (unchanged) makes no change
;        CFu controls case of the first character in the comment line
;            CFU makes the first character upper-case
;            CFL make the first character lower-case
;            CFX leaves the case of the first character unchanged
;        CAu controls case of all characters in the comment line
;            except the first character if CFU or CFL is in effect
;            CAU makes all characters upper-case
;            CAL makes all characters lower-case
;            CAX leaves the case of all characters unchanged
;    Eou, Eoy - embedded comment formatting
;        ECy controls placement of the embedded comment if it begins
;            after field4 (column 33)
;            ECY (yes) places embedded comments on the next line
;            ECN, ECX (no, unchanged) leaves embedded comments
;                on the same line
;        EWy controls removal of the space character after the
;            semicolon
;            EWY (yes) removes the space after the semicolon if a
;                      space is present, else no change
;            EWN (no) inserts the space after the semicolon if no
;                     space is present, else no change
;            EWX (unchanged) makes no change
;        EFu controls case of the first character in the comment
;            EFU makes the first character upper-case
;            EFL make the first character lower-case
;            EFX leaves the case of the first character unchanged
;        EAu controls case of all characters in the comment
;            except the first character if EFU or EFL is in effect
;            EAU makes all characters upper-case
;            EAL makes all characters lower-case
;            EAX leaves the case of all characters unchanged
;    Ioy - indent lines subordinate to IFs or MACROs
;        I+ increases the indentation level by 1 character
;        I- decreases the indentation level by 1 character (0 min)
;        IIy controls indentation for the IF/ELSE/ENDIF pseudo-ops
;            IIY causes all opcodes subordinate to an IF to be
;                 indented one character; each successive IF
;                 causes another indentation; ENDIF brings the
;                 indentation level out; ELSE temporarily brings
;                 the indentation level out for the ELSE pseudo-op
;                 only
;            IIN, IIX (no, unchanged) causes indentation under IFs
;                 to not take place
;        IMy controls indentation for the MACRO/ENDM pseudo-ops
;            IMY causes all opcodes subordinate to a MACRO to be
;                 indented one character; ENDM brings the
;                 indentation level out
;            IMN, IMX (no, unchanged) causes indentation under
;                 MACROs to not take place
;    Lou, Loy - control format of labels
;        LFu controls the case of the first character of a label
;            LFU makes the first character upper-case
;            LFL makes the first character lower-case
;            LFX leaves the case of the first character unchanged
;        LAu controls the case of all characters in a label except
;            the first character if LFU or LFL is in effect
;            LAU makes all characters upper-case
;            LAL makes all characters lower-case
;            LAX leaves the case of all characters unchanged
;        LCy controls the presence of a colon after a normal label
;            LCY ensures that there is a colon after each label
;            LCN ensures that there is no colon after each label
;            LCX has no effect on a trailing colon; if one was
;                present in the input, it is present in the output
;        LSy controls the presence of a colon after a special label,
;            where a "special" label is a label in front of a MACRO,
;            SET, or EQU pseudo-op
;            LSY ensures that there is a colon after a special label
;            LSN ensures that there is no colon after a spec label
;            LSX has no effect on a trailing colon; if one was
;                present in the input, it is present in the output
;        LLy controls the presence of a new line following a label
;            LLY places a new line after a label
;            LLN, LLX does not place a new line after a label
;        L8y controls the presence of a new line following a label
;            which is longer than 8 characters
;            L8Y places a new line after an 8+ character label
;            L8N, L8X does not place a new line after an 8+
;                     character label
;    Ou - controls the case of opcodes
;        OU makes opcodes upper-case
;        OL makes opcodes lower-case
;        OX leaves the case of opcodes unchanged
;
;    In addition to the above directives, four predefined formats
;are available via the Fn directive, where 0 <= n <= 3.  The predefined
;formats are:
;        F0 - reset all directives to null
;            Remove blank lines (B):            No
;            Comment lines
;                First char (CF):        Unchanged
;                All chars (CA):            Unchanged
;                Remove Space after ; (CW):    Unchanged
;            Embedded comments
;                First char (EF):        Unchanged
;                All chars (EA):            Unchanged
;                Remove Space after ; (EW):    Unchanged
;                Next line if after col 33 (EC):    No
;            Indentation
;                of IFs (II):            No
;                of MACROs (IM):            No
;            Labels
;                First char (LF):        Unchanged
;                All chars (LA):            Unchanged
;                Colon after label (LC):        Unchanged
;                Colon after special label (LS):    Unchanged
;                Line after label (LL):        Unchanged
;                Line after 8+ char label (L8):    Unchanged
;            Opcode case (O):            Unchanged
;            Operand (argument) case (A):        Unchanged
;
;        F1 - Z System standard format
;            Remove blank lines (B):            No
;            Comment lines
;                First char (CF):        Unchanged
;                All chars (CA):            Unchanged
;                Remove Space after ; (CW):    Unchanged
;            Embedded comments
;                First char (EF):        Unchanged
;                All chars (EA):            Unchanged
;                Remove Space after ; (EW):    Yes
;                Next line if after col 33 (EC):    Yes
;            Indentation
;                of IFs (II):            Yes
;                of MACROs (IM):            Yes
;            Labels
;                First char (LF):        Unchanged
;                All chars (LA):            Upper
;                Colon after label (LC):        Yes
;                Colon after special label (LS):    No
;                Line after label (LL):        Yes
;                Line after 8+ char label (L8):    Yes
;            Opcode case (O):            Lower
;            Operand (argument) case (A):        Lower
;
;        F2 - special format
;            Remove blank lines (B):            Yes
;            Comment lines
;                First char (CF):        Unchanged
;                All chars (CA):            Unchanged
;                Remove Space after ; (CW):    Yes
;            Embedded comments
;                First char (EF):        Upper
;                All chars (EA):            Lower
;                Remove Space after ; (EW):    Yes
;                Next line if after col 33 (EC):    Yes
;            Indentation
;                of IFs (II):            Yes
;                of MACROs (IM):            Yes
;            Labels
;                First char (LF):        Upper
;                All chars (LA):            Lower
;                Colon after label (LC):        Yes
;                Colon after special label (LS):    No
;                Line after label (LL):        Yes
;                Line after 8+ char label (L8):    Yes
;            Opcode case (O):            Lower
;            Operand (argument) case (A):        Lower
;
;        F3 - special format
;            Remove blank lines (B):            Yes
;            Comment lines
;                First char (CF):        Unchanged
;                All chars (CA):            Unchanged
;                Remove Space after ; (CW):    No
;            Embedded comments
;                First char (EF):        Upper
;                All chars (EA):            Lower
;                Remove Space after ; (EW):    Yes
;                Next line if after col 33 (EC):    Yes
;            Indentation
;                of IFs (II):            Yes
;                of MACROs (IM):            Yes
;            Labels
;                First char (LF):        Unchanged
;                All chars (LA):            Upper
;                Colon after label (LC):        Yes
;                Colon after special label (LS):    No
;                Line after label (LL):        Yes
;                Line after 8+ char label (L8):    Yes
;            Opcode case (O):            Upper
;            Operand (argument) case (A):        Upper
;
;    If no directives are given, the format F1 is selected.  F1 is always
;selected as the default format, and directives can be used to vary specific
;settings or all settings within this default.
;
;    Examples of various forms a label may take on:
;        Forms        AbCd    hello    EXEC
;        --------    ----    -----    ----
;        LFX, LAX    AbCd    hello    EXEC
;        LFU, LAX    AbCd    Hello    EXEC
;        LFL, LAX    abCd    hello    eXEC
;        LFX, LAU    ABCD    HELLO    EXEC
;        LFU, LAU    ABCD    HELLO    EXEC
;        LFL, LAU    aBCD    hELLO    eXEC
;        LFX, LAL    abcd    hello    exec
;        LFU, LAL    Abcd    Hello    Exec
;        LFL, LAL    abcd    hello    exec
;
;    Directives may be placed in any order with any or no delimiters:
;        "LFXLAU"    "LFX LAU"    "LFX,LAU"
;have the same meanings.  This applies to both command lines and embedded
;comments.
;        PPAL file1,file2 LFX LAU
;        ;#LFX, LAU
;    Note that allowing directives embedded in the files they are acting
;on allows one part of the file to take on one format and another part of the
;file to take on another format.
;
;    Sample file before processing by PPAL:
;
;    ; Sample file to illustrate PPAL
;    mymac    macro
;        if    debug    ; this is a test
;        call    print
;        db    'debug macro',0
;        else
;        call    print
;        db    'no debug macro',0
;        endif
;        endm
;    loop:
;        if    debug
;        if    debug2
;        call    print; this is only a test
;        db    'debug2',0
;        else
;        call    print
;        db    'debug',0
;        endif
;        else
;        call    print
;        db    'not debug',0
;        endif
;        jp    loop
;        end
;
;    Sample file after processing by PPAL:
;
;    ; Sample file to illustrate PPAL
;    MYMAC    macro
;         if    debug        ;this is a test
;          call    print
;          db    'debug macro',0
;         else
;          call    print
;          db    'no debug macro',0
;         endif
;        endm
;    LOOP:
;        if    debug
;         if    debug2
;          call    print        ;this is only a test
;          db    'debug2',0
;         else
;          call    print
;          db    'debug',0
;         endif
;        else
;         call    print
;         db    'not debug',0
;        endif
;        jp    loop
;        end
;
;%END
-------
 7-Sep-86 03:58:33-MDT,3484;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 7 Sep 86 03:58:24-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a004947; 7 Sep 86 5:32 EDT
Received: from USENET by SMOKE.BRL.ARPA id a007242; 7 Sep 86 5:32 EDT
From: Chris Gray <[e-mail]>
Newsgroups: net.micro.cpm
Subject: New shareware compiler
Message-ID: <[e-mail]>
Date: 4 Sep 86 19:08:44 GMT
Posted: Thu Sep  4 15:08:44 1986
To:       [e-mail]

Greetings fellow CP/M'ers.

I have over a Megabyte of new CP/M software that I would like to get out
in the world as shareware. It was originally intended to be a commercial
product, but I think the time has passed for that. What I want to know is
how to go about doing it. Posting it to the net might raise just a few
hackles, so I'm reluctant to do that. Also, spending a few hundred dollars
to ship it to a BBS a thousand or so miles away doesn't sound attractive.
(I'm physically in Edmonton, Alberta - home of West Edmonton Mall.)

What I have to give away is a full programming language system. The language,
called Draco (pronounced Drayko), has been in use for a couple of years now,
so the compiler is fairly stable, as are the other utilities. The compiler
compiles at about 1500 lines per minute (5 MHz 8085) directly to relocatable
object files. The linker is similarly capable. Code produced is about on
par with the best produced by any C or Pascal compiler I've heard of. As an
example, the compiler itself is about 10000 lines. It compiles on a single
8" floppy in under 10 minutes, yielding about 40K of code. For small programs,
under 100 lines, the time to load the compiler is easily the dominant factor.
All of the tools are easy to use, and fit well into CP/M. Again, as an
example, to build the compiler from scratch, I just type

    draco dr*
    link dr1 dr2 dr3 dr4 dr5 dr6 dr7 dr8 dr9 -sodraco

(I built file patterns into the compiler, but not the linker - sigh.) The
entire package includes fairly complete documentation on everything, a few
thousand lines of sample sources (including a CRT-oriented adventure game
system needing only a scenario), and several utilities. Major programs:

    draco.com - the compiler itself
    link.com - the linker
    drlib.com - the library builder
    ddis.com - the disassembler
    das.com - a simple, one-pass assembler
    xref.com - call cross referencer
    trrun.lib - 8080 version of run-time library (quite comprehensive)
    trcpm.lib - CP/M-80 interface stubs
    crt.lib - terminal independent CRT I/O library (facilities vary from
        simple cursor addressing up through on screen formatter,
        menu builder and forms input routines)
    config.com - program to configure .set programs to a given terminal
    config.dat - database of terminal definitions (from a termcap)
    ded.set - visual programming editor
    hedit.set - visual hex editor/viewer
    cmp.set - visual file comparer
    - several CRT oriented games. Some are trivial, but two are major
        entities in their own right.

OK, so what should I do with this stuff? (Nasty comments can be directed to
/dev/null.) I'm willing to package up one or two copies (takes 5 single
sided single density disks) and send them to major sites (note that the
stuff is SHAREWARE, not FREEWARE), but I do not want to get into distributing
it myself - I figure I'm better off porting my compiler to the 68000 family.

            Chris Gray (...alberta!myrias!cg)
 7-Sep-86 09:53:29-MDT,509;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 7 Sep 86 09:53:19-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a005415; 7 Sep 86 11:24 EDT
Date: Sun 7 Sep 86 09:26:07-MDT
From: Rick Conn <[e-mail]>
Subject: Z-NEWS.509 Available
To: [e-mail]
Message-ID: <[e-mail]>

    In PD:<ZSYS.NEW> are Z-NEWS.509 and 5Q9.  In PD:<ZSYS.Z-NEWS> is
Z-NEWS.5Q9.

    Thanks to Keith for the upload.

        Rick
-------
 7-Sep-86 12:24:40-MDT,1273;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 7 Sep 86 12:24:30-MDT
Received: from nadc.arpa by AMSAA.ARPA id a005635; 7 Sep 86 13:54 EDT
Date: 7 Sep 1986 13:51:58-EDT
From: [e-mail]
To: [e-mail]
Subject: c128 cp/m disk formats
Cc: [e-mail]

The C128 can (in CP/M mode with a 1571 disk drive) read, write, and format the
following diskette formats:

   Single Sided Commodore GCR CP/M 2.2 (32 tracks of 17 (256 byte) sectors)
   Single Sided C128 CP/M 3.0 GCR (680 logical tracks of 1 (256 byte) sector)
   Double Sided C128 CP/M 3.0 GCR (1360 logical tracks of 1 (256 byte) sector)
   Epson QX10 DS MFM (80 tracks of 10 (512 byte) sectors)
   IBM CP/M 86 SS MFM (40 tracks of 8 (512 byte) sectors)
   IBM CP/M 86 DS MFM (80 tracks of 8 (512 byte) sectors)
   Kaypro II SS MFM (40 tracks of 10 (512 byte) sectors)
   Kaypro IV DS MFM (80 tracks of 10 (512 byte) sectors)
   Osborn DD MFM (80 tracks of 5 (1024 byte) sectors)

Hope this clarifys things.  Most Commodore documentation implies there are
additional formats, but without committing to what they are.  Thus, the above
are obviously all the "official" formats!

Frank Prindle
[e-mail]
 7-Sep-86 16:39:55-MDT,950;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 7 Sep 86 16:39:47-MDT
Date:     Sun, 7 Sep 86 18:01:09 EDT
From:     David Towson (SECAD) <[e-mail]>
To:       Rick Conn <[e-mail]>
cc:       [e-mail], [e-mail]
Subject:  Re:  Response to Sage's comments

Rick - After reading Jay,s message and your reply regarding SYSLIB, I decided
to take a look to see whether the archives still contained a version of SYSLIB
that could be assembled with M80.  I was surprised when the string-search of
CPM.CRCLST failed to come up with ANY entry for SYSLIB.  I thought for sure it
would be in the ZCPR2 directory.

     How about restoring to the archives the latest version of SYSLIB that
will still work with the tools lots of people already have?  It seems a shame
to limit the use of such a good thing to those who wish to purchase a new
assembler.


Dave

 7-Sep-86 18:07:26-MDT,10281;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 7 Sep 86 18:06:57-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a006311; 7 Sep 86 18:58 EDT
Date: Sun, 7 Sep 1986  16:59 MDT
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: New CP/M files on SIMTEL20 31-July to 7-September

The following is a list of new files added to SIMTEL20's <CPM.*>
directories between 31-Jul-86 and 7-Sept-86.  For a complete list of
all files, get PD:<CPM>CPM.CRCLST.

        Filename        Type     Bytes   CRC

PD:<CPM.ASMUTL>
        MAKE-DS.LBR.1   BINARY   59136  0715H <--DateStamper Unix make clone
        ZAS-SLR.DQC.1   BINARY    4480  9D72H <--alternatives asm'g SYSLIB
        ZMACLINK.LBR.1  BINARY   24576  24BAH <--Z80 macro asm/linker

PD:<CPM.AZTEC-C>
        COMND004.ARC.1  BINARY   72114  BE7EH <--Tops-20 style command parser
        MINDER.ARC.1    BINARY   62402  02CAH <--reminders
        QUOTE.ARC.1     BINARY   52356  B382H <--prints quotes to terminal

PD:<CPM.BASIC>
        MBPRE-12.LBR.1  BINARY   17536  907BH <--MBASIC pre-processor

       [ Note: non-CP/M lists have been moved to PD:<MISC.BBSLISTS> ]
PD:<CPM.BBSLISTS>
        BBSRGAUG.LBR.1  BINARY  144128  ABF7H <--august world BBS list
        PDFT-086.LQT.1  BINARY   11520  AC4FH <--abreviated RCP/M phone list
        RCPM078.LQT.1   BINARY   59904  C99CH <--RCP/M phone list
        ROSNET07.LQT.1  BINARY    7936  A76CH <--ROS systems phone list

PD:<CPM.BDOS>
        BDOSFUNC.DQC.1  BINARY    4608  EAB0H <--explains BDOS calls

PD:<CPM.BYE5>
        B5OX-2.IQS.1    BINARY    3328  7A5CH
        BYE5-INS.LQT.1  BINARY    3712  9DCCH
        BYE510.FIX.1    ASCII     2460  59AEH
        BYE510.LBR.1    BINARY  174208  2DA0H
        KMDRSX.LBR.1    BINARY    4480  7892H

PD:<CPM.C128>
        801PRT10.LBR.1  BINARY   26752  59D8H <--printer file lister
        B5C8-2.IQS.1    BINARY    4992  E7EFH <--BYE5 insert for C128
        C128-MEX.FIX.1  ASCII     1329  19BEH <--making buffer smaller
        C128CNF3.LBR.1  BINARY   10880  A1D5H <--latest CONFIGURE
        C128TVX2.LBR.2  BINARY  200320  12F7H <--TVX editor ready to run
        C1571-2.COM.1   BINARY    1024  DBA9H <--disk speedup
        C8FILCPY.LBR.2  BINARY   11392  2BE8H <--file copy
        CPMPRMR1.TQT.1  BINARY    4608  BAFEH <--CP/M-Plus tutoral #1
        CPMPRMR2.TQT.1  BINARY    7552  C9BFH <--CP/M-Plus tutoral #2
    VDE22-C8.LBR.1    BINARY     52480  6A10H <--video editor ready to run
        WORDSTAR.IQF.1  BINARY    6400  29A8H <--WordStar color patches

PD:<CPM.CPM3>
        CCP104P.LBR.1   BINARY   84608  B7EAH <--CP/M-Plus ZCPR-like CCP
        CPMMAKE.ARC.1   BINARY   46443  E455H <--Unix-like MAKE util.

PD:<CPM.CPM68K>
        COM.68K.1       BINARY   23808  A4F5H <--CP/M-80 emulator
        COM.LBR.1       BINARY   50560  6A51H <--sources for above

PD:<CPM.CPMINFO>
        CPM-CC26.AQT.1  BINARY    6016  5522H <--CP/M connection articles
        CPM-CC27.AQT.1  BINARY    6912  4CA3H <--- /
        CPM-CC28.AQT.1  BINARY    4352  EA6BH <-- /
        CPM-CC29.AQT.1  BINARY    6400  8BBBH <--/
        CPM22APP.LBR.1  BINARY   34944  7C00H <--CP/M 2.2 application notes

PD:<CPM.DATABASE>
        CHEFREC.5Q.1    BINARY   25856  531EH <--more recipies for CHEF db

PD:<CPM.DATABASE>
        SEARCH.LBR.1    BINARY   36352  BFA0H <--search for key strings

PD:<CPM.DBASEII>
        BANKING.LBR.1   BINARY   32256  4B48H <--do your banking records
        CHECKBK2.LBR.1  BINARY   24832  0D4DH <--check book db
        VIDLOG20.LBR.1  BINARY   58880  9CD9H <--videotape log database

PD:<CPM.DIRUTL>>
        SAP49.WRN.1     ASCII     1192  71F7H <--warning on bad program
        SAP50.LBR.1     BINARY   40704  2C6AH <--update, good version

PD:<CPM.DSKUTL>
        BWFMT.LBR.1     BINARY    5376  C98EH <--format pgms for Bondwell

PD:<CPM.EDUCATION>
        MDLPLNE2.LBR.1  BINARY   35456  2C05H <--model plane design

PD:<CPM.FILE-DOCS>
        SEPBEST2.LQT.1  BINARY   29440  C50BH <--best of CP/M pd programs

PD:<CPM.GENDOC>
        GOVTPUBS.TQT.1  BINARY   14720  67E9H <--gov't publications list

PD:<CPM.GENIE>
        GE-FILES.AQG.1  BINARY   63488  473BH <--complete dir of GEnie CP/M
        GENIE.CPM.2     ASCII     1103  DC2FH <--info on GEnie CP/M RT
        GENIE.IDX.2     ASCII     2401  47F2H <--index of GEnie groups

PD:<CPM.HEX>
        UUDECODE.HEX.1  ASCII    25555  50F5H <--uudecode for CP/M
        UUENCODE.HEX.1  ASCII    24939  4228H <--uuencode for CP/M

PD:<CPM.IMP>
        I2DG-1.AQM.1    BINARY    7936  FE17H <--Digital Group overlay
        IMPATCH.LBR.1   BINARY   20480  C0ECH <--easy patching for IMP
        IMPSTEPS.TQT.1  BINARY    5248  A189H <--steps for implementing IMP

PD:<CPM.KAYPRO>
        256CRKT.UPD.1   ASCII     2889  5E47H <--256k memory mod update
        256NEW.ANS.1    ASCII     2669  F5D5H <---/
        84KP256.LBR.1   BINARY   26880  43B3H <--/
        CRHRDSFT.LBR.1  BINARY   25088  A3CCH <--WordStar Doc/Non-Doc conv.
        KAY256.FIX.1    ASCII     1120  20DAH <--more on 256k mod
        SAVECRT.LBR.1   BINARY    5120  AE26H <--blanks screen after no use
        SEP86.MQG.1     BINARY   17408  F578H <--user's magazine
        WS-UROM.FQX.1   BINARY    2560  6A71H <--Micro-C rom fix

PD:<CPM.LIST>
        PMASTER.LBR.1   BINARY  116736  5DFAH <--dot matrix printer util.

PD:<CPM.MEX>
        MEX-BUFF.LBR.1  BINARY    7808  C04FH <--setting MEX buffers, etc.
        MEX114.PQN.1    BINARY   33792  0C45H <--printer formatted MEX.HLP
        MEXSTEPS.TQT.1  BINARY    6016  12ACH <--steps to implement MEX
        MX114DOC.PQN.1  BINARY   54656  5BB0H <--printer formatted MEX manual
        MXH-VT.AQM.1    BINARY   11648  E75BH <--DEC VT100 overlay
        MXO-RS21.AQM.1  BINARY   17280  9DA2H <--Radio Shack Mod. 4 overlay

PD:<CPM.MISC>
        ROYALOAK.ARC.1  BINARY   65293  6B5BH <--RCP/M Royal Oak directory

PD:<CPM.MODEM>
        PC-PSUIT.LBR.1  BINARY   15872  3741H <--PC Pursuit info

PD:<CPM.MODEM2>>
        FAST.TQT.1      BINARY   11648  B7FDH <--FAST protocol proposal
        WXMODEM.DQC.1   BINARY   32256  4C78H <--windowed XMODEM "

PD:<CPM.MODEM7>>
        M7H8-2-1.AQM.1  BINARY    8320  01DCH <--Heath H89 overlay

PD:<CPM.NUBYE>
        NUBYE101.FIX.1  ASCII     1287  862FH
        NUBYE101.LBR.1  BINARY  147712  BAA6H <--alternative to BYE5
        NUCD.LBR.1      BINARY   31744  C90BH <--fixes for ZCPR3 CD pgm
        NUKMD102.LBR.1  BINARY  130688  1461H <--alternative to KMD

PD:<CPM.PACKET>>
        9LANDMAP.009.1  ASCII     9453  E860H
        9LANDTBL.009.1  ASCII    20568  5B7BH
        PACKT117.ARC.1  BINARY  212704  0B69H <--W0RLI packet BB ver 11.7
        PACKT117.MSG.1  ASCII     4500  9F43H <--info on above

PD:<CPM.PBBS>  (note: new directory, most files not new, check list)
        FASTPBBS.LBR.1  BINARY    8192  BD7AH
        MBB2PBBS.LBR.1  BINARY   11392  8740H
        PBBS-L02.HQK.1  BINARY    3840  AA53H
        PBBS-MSD.HQK.1  BINARY    6528  5402H
        PBBS-PHN.MOD.1  ASCII      569  6C94H
        PBBS03.LBR.1    BINARY  212480  7FB2H
        PBBS3-01.FIX.1  BINARY    1152  030FH
        PBBS3-02.FIX.1  BINARY     768  3976H
        PBBS3-03.FQX.1  BINARY    1408  3313H
        PBBS3-04.FIX.1  ASCII     2059  4D83H
        PBBS3-4A.FIX.1  ASCII      706  AFBBH
        PBBSCPM3.NQT.1  BINARY    1408  B736H
        PBBSUP-3.LBR.1  BINARY   89472  9C2EH
        PBBUTL-3.LBR.1  BINARY   11520  6C95H
        PBYE3-01.FIX.1  BINARY    1280  2A3AH
        PBYEHACK.ADD.1  ASCII     1063  F6E8H
        PCHAT11.MQC.1   BINARY    5376  4727H
        PHACKS01.LBR.1  BINARY   10240  78D4H
        PMAINT02.FIX.1  ASCII     2173  4582H

PD:<CPM.RCPM>
        AVATEXSM.TQT.1  BINARY    2816  5111H <--using Avatex modem
        MB-KMD11.LBR.1  BINARY  139776  D5F2H <--MBYE KMD or stand-alone

PD:<CPM.RCPM>
        NEW-SYS.OPS.2   ASCII     5875  9637H <--registering your RCP/M

PD:<CPM.RCPM>
        PRIVCY2.BQL.1   BINARY   45056  D16DH <--updated Privacy Bill

PD:<CPM.SQUSQ>
        CRUNCH20.LBR.1  BINARY   50304  75F5H <--file cruncher, Z80 only
        USQFST20.LBR.1  BINARY   27520  E993H <--fast unsqueezer

PD:<CPM.STARTER-KIT>
        UNARC.COM-Z80.1         BINARY    4096  C209H <--ARC extract Z80
        UNARCA.COM-8080.1       BINARY    4736  DF9BH <--ARC extract 8080
        UUDECODE.COM.1          BINARY   10496  00D8H <--uudecode
        UUENCODE.COM.1          BINARY   10240  2EAFH <--uuencode

PD:<CPM.TURBOPAS>
        COMDEMO.ARC.1   BINARY   18179  7E70H <--communications demo
        UUECPM.ARC.1    BINARY   48862  3700H <--uuencode/uudecode

PD:<CPM.TXTUTL>
        FOGINDEX.LBR.1  BINARY   12288  BD13H <--grade level of text files
        REPLACE.LBR.1   BINARY   23040  A9E0H <--find and replace util.

PD:<CPM.VAXVMS>
        VMSSWEEP.FOR.3  ASCII    50461  92E5H <--LBR/SQ/USQ/CRUNCH/UNCRUNCH

PD:<CPM.VDOEDIT>
        VDE-QX.LBR.1    BINARY   27648  2E2AH
        VDE-SMC.AQM.1   BINARY    8448  47AFH
        VDE211SB.AQM.1  BINARY    8832  76A7H
        VDE22.LBR.1     BINARY   54272  FAF3H <--video editor
        VDE22RS4.AQM.1  BINARY   10752  FB7FH <--RS Mod. 4 overlay for VDE22

PD:<CPM.WSTAR>
        WSPATCH.TQL.1   BINARY   14208  52BBH <--WordStar patch table
        XEROX-WS.LBR.1  BINARY    4480  DD6CH <--Xerox computer WS enhance

PD:<CPM.ZMODEM>  (Chuck Forsberg's extended XMODEM/YMODEM for Unix)
        GZ..3           ASCII       15  0792H
        RBSB.C.4        ASCII     7748  E717H
        RZ.1.3          ASCII     6295  3EBAH
        RZ.C.3          ASCII    24907  AA2BH
        RZ.MAN.4        ASCII     7007  3108H
        SZ.1.4          ASCII     8834  9FE7H
        SZ.C.4          ASCII    27600  CD6BH
        SZ.MAN.5        ASCII    10359  A666H
        ZM.C.3          ASCII     9913  3DB9H
        ZMODEM.DOC.3    ASCII    64543  8D0CH
        ZMODEM.H.5      ASCII     4400  F9F1H
 7-Sep-86 18:25:00-MDT,548;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 7 Sep 86 18:24:50-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a006462; 7 Sep 86 19:40 EDT
Date: Sun 7 Sep 86 17:41:53-MDT
From: Rick Conn <[e-mail]>
Subject: New PPAL.DOC
To: [e-mail]
Message-ID: <[e-mail]>

    In PD:<ZSYS.NEW> and PD:<ZSYS.ZCPR3> is a new version of
PPAL.DOC, the documentation (beta test) on the Pretty Printer for Assembly
Language for the Z System.

        Rick
-------
 7-Sep-86 19:04:13-MDT,652;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 7 Sep 86 19:04:07-MDT
Received: from brl-vgr.arpa by AMSAA.ARPA id a006464; 7 Sep 86 19:44 EDT
Received: from LLL-MFE.ARPA by VGR.BRL.ARPA id aa03480; 7 Sep 86 19:40 EDT
Date: Sun, 7 Sep 86 16:39 PDT
From: [e-mail]
Subject: Remove me.
To: [e-mail]
Message-ID:  <[e-mail]>


Dispite the request for removal being specific I wanted to thank all
for making this a very interesting forum to be associated with
the last several year.
So...
Please remove me from the list, it is time to move on.
--Neil
 7-Sep-86 19:08:07-MDT,1158;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 7 Sep 86 19:08:00-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a006482; 7 Sep 86 19:49 EDT
Date: Sun 7 Sep 86 17:50:50-MDT
From: Rick Conn <[e-mail]>
Subject: Re:  Response to Sage's comments
To: [e-mail]
cc: [e-mail], [e-mail]
In-Reply-To: Message from "David Towson (SECAD) <[e-mail]>" of Sun 7 Sep 86 16:08:28-MDT
Message-ID: <[e-mail]>

    The original ZCPR 3.0 SYSLIB is in PD:<ZSYS.SYSLIB>.  It is also
in PD:<SIGM> in the proper volume (as referenced by the article).  The
new libraries will be released when ZCPR 3.3 is released.

    In PD:<ZSYS> are:
        ZSYS.CRCLST
        ZSYS.USAGE - frequency of access/most popular
        ZSYS.SNP - snapshot

    The ZSYS archive is like the ADA archive in its management,
and the ZSYS archive is for Z System - specifics only.

        Rick

PS. Don't forget that any assembler compatable with the Microsoft REL
format can USE the new SYSLIB ... you don't have to assemble it to use it.
Using it is simply a matter of linking.
-------
 7-Sep-86 19:38:26-MDT,1759;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 7 Sep 86 19:38:18-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a006545; 7 Sep 86 20:11 EDT
Date: Sun 7 Sep 86 17:56:21-MDT
From: Rick Conn <[e-mail]>
Subject: ZSYS Snapshot
To: [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>

    This is what the ZSYS.SNP file looks like at this time.  It
will be updated by morning.

                                ---- Source Code ---- | --- Documentation ---
Directory                             Byte Count      |       Byte Count
-----------------------               ----------      |       ----------
PD:<ZSYS.DOC>                                  0      |           217676
PD:<ZSYS.INSTALL>                         547920      |           166166
PD:<ZSYS.NEW>                              93213      |            47632
PD:<ZSYS.SYSLIB>                          653184      |            41655
PD:<ZSYS.VLIB>                             27733      |            20408
PD:<ZSYS.Z-NEWS>                               0      |           540916
PD:<ZSYS.Z3LIB>                           229015      |            24171
PD:<ZSYS.ZCPR3>                          1502072      |           351300
PD:<ZSYS.ZSIG>                            682320      |            45506


                                ---- Source Code ---- | --- Documentation ---
Totals                                Byte Count      |       Byte Count
-----------------------               ----------      |       ----------
Column Totals            -->             3735457      |          1455430
Grand Total (Col 1 Only) -->             5190887      |                0
-------
 7-Sep-86 21:46:01-MDT,990;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 7 Sep 86 21:45:55-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a006913; 7 Sep 86 23:26 EDT
Received: from USENET by SMOKE.BRL.ARPA id a012696; 7 Sep 86 23:30 EDT
From: [e-mail]
Newsgroups: net.micro.cbm,net.micro.cpm
Subject: Z80 Cartridge for C64... HELP!!!
Message-ID: <7264OP4@PSUVMA>
Date: 6 Sep 86 18:57:37 GMT
Expires: 21 Sep 86 05:00:00 GMT
To:       [e-mail]

Hi all!
I seem to be having some trouble with the Z80 cartridge I purchased recently
for my C-64.  It doesn't want to boot up on my machine.  I did find some
information that the Z80 will not work on the later models of the C-64,
namely, the 3rd and 4th models.
Does anybody out there have any information on how to make the Z80 work on
these later models?  It would be a great help.

Thanks in advance,

Bill Myers
Penn State/York
[e-mail]

 8-Sep-86 04:01:48-MDT,2148;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 8 Sep 86 04:01:37-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a007611; 8 Sep 86 5:39 EDT
Received: from USENET by SMOKE.BRL.ARPA id a014794; 8 Sep 86 5:38 EDT
From: Michael Portuesi <[e-mail]>
Newsgroups: net.micro.cpm
Subject: CP/M system info wanted
Message-ID: <[e-mail]>
Date: 6 Sep 86 17:52:19 GMT
Posted: Sat Sep  6 13:52:19 1986
Keywords:
To:       [e-mail]

I recently purchased a VT-100 clone and am thinking of purchasing a
low-cost CP/M box to attach to it.  Could anyone answer the following
questions:

    * Does CP/M terminal support handle VT-100's?  Is there some
    type of Install program, or do I have to hack the BIOS to make
    things work?

    * Does anyone know of cheap CP/M boxes that can be had?  SWP
    products makes the ATR8000, which is a CP/M system that can be
    attached to Ataris and RS-232 terminals.  I have also seen the
    "Little Board" advertised in Byte, which is supposed to be a
    CP/M system that can be mounted in a disk drive case along
    with the drive.  Ideally, I would like to spend as little
    money as possible.  I am looking for 64K and two drives.

    * What Emacs-like editors run under CP/M?  I know of Mince,
    but I have heard that it has nasty bugs (at least its
    incarnation on the PC did).  Is it possible to get MicroEmacs
    to run in 64K?  It has conditional compilation for CP/M-86 --
    will this also work with CP/M-80?

Please send replies by E-mail.  Thank you.

--

+----------------------------------------------------------------------------+
| Mike Portuesi                                     |
| Carnegie-Mellon University Computer Science Department             |
|                                         |
| ARPA: [e-mail] (preferred), [e-mail]             |
| UUCP: {harvard | seismo | ucbvax | decwrl}!spice.cs.cmu.edu!mjp         |
|                                         |
| "Little things remind me of you...Cheap cologne and that damn song too!"   |
|            --The Flirts, "Jukebox"                     |
+----------------------------------------------------------------------------+
 8-Sep-86 08:06:18-MDT,2128;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 8 Sep 86 08:06:00-MDT
Received: from nadc.arpa by AMSAA.ARPA id a012766; 8 Sep 86 9:09 EDT
Date: 8 Sep 1986 09:10:43-EDT
From: [e-mail]
To: [e-mail], [e-mail], [e-mail]
MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
Subject: Z80 cartridge for C64

The Z80 CP/M add-on cartridge for the Commodore 64 *will not* work on any C64
which contains the newer improved video (VIC II) chip.  The reason is that the
original video chip (used during about the first year of C64 production) had
a flaw in the derivation of the internal clocks and the processor clock from
the color clock input - this flaw caused the dot-clock to be in-phase with the
horizontal scan rate (a no-no for NTSC color character generation). The net
result was excessive chroma distortion of the characters in most color combi-
nations on a TV set or NTSC monitor.

It took Commodore a while to realize what the problem was, but eventually they
fixed it.  Unfortunately, the phase relationship between the processor clock
and the dot clock was irrevocably altered, and all CP/M cartridges (which
worked with the old chips) suddenly croaked.  I think the Federal Trade
Commission considered this a massive enough screw-up on Commodore's part to
order them to refund the purchase price on any and all CP/M cartridges, which
they did and are still doing.

As the proud owner of one of these, your only alternatives are:

  1. Find a C64 owner with one of the old VIC II chips (display red characters
     on a black background and look at the output on a TV set - if you can't
     read every other character, it's the old chip.  If the display is quite
     readable, it's the new chip) and swap chips with him.  He'll enjoy the
     better video; your CP/M cartridge will work.  However, unless you're using
     a "separated" video monitor (e.g. C= 1702), your eyes will suffer!

  2. Contact Commodore and ask how to get your money back!

Sincerely,
Frank Prindle
[e-mail]
 8-Sep-86 10:21:33-MDT,399;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 8 Sep 86 10:21:21-MDT
Date:     Mon, 8 Sep 86 11:01:48 EDT
From:     David Towson (SECAD) <[e-mail]>
To:       Rick Conn <[e-mail]>
cc:       [e-mail], [e-mail]
Subject:  Re:  Response to Sage's comments

Very good, Rick.  Thanks for the pointers.


Dave

 8-Sep-86 21:29:02-MDT,1812;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 8 Sep 86 21:28:54-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a029110; 8 Sep 86 23:05 EDT
Date: Sunday, 7 September 1986  17:01-MDT
Message-ID: <[e-mail]>
Sender: [e-mail]
From: [e-mail]
To: [e-mail]
Subject:   Commodore C128 printer program update
ReSent-From: [e-mail]
ReSent-To: [e-mail]
ReSent-Date: Mon 8 Sep 1986 21:02-MDT

801PRT11 - MPS801 file printer version 1.1 is now available from
SIMTEL20 as:

Filename            Type     Bytes     CRC

Directory PD:<CPM.C128>
801PRT11.LBR.1            BINARY     27136  4663H

This is a file printer designed with the Commodore MPS801 and 1525
printers in mind.  It should, however, work with any printer that does
not need linefeeds.  It sends two extra carriage returns to the
printer at the end to clear out the buffer, so that no lines will be
dropped as happens with many file listers when used with the MPS801.
It also filters out linefeeds.

This source code and the program are in the public domain. Modify them
as you see fit.

Update:
9/7/86 - Removed code-wasting check to see if printer opened ok
         since it didn't work and added tab expansion to make
         version 1.1.

The files included in the original distribution library for 801prt11
are:

801PRT11.INF - Info on the distribution library
801PRT10.DOC - Documentation for 801PRT11
801PRT11.C   - C source code for 801PRT11
801PRT11.COM - The actual 801PRT11 program.
801PRT11.UPD - Update notes.

Enjoy the program!!

-Matt Kimmel

I can be reached on the ARPANet as:

[e-mail]

and on BITNet as:

[e-mail]
 9-Sep-86 01:25:22-MDT,605;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Sep 86 01:25:17-MDT
Received: from usc-isi.arpa by AMSAA.ARPA id a029471; 9 Sep 86 2:58 EDT
Date:  8 Sep 1986 22:08:10 EDT
Subject: Kermit <--> TAC problems
From: Rex Buddenberg <[e-mail]>
To: [e-mail]
cc: [e-mail]

My trusty Kermit (CP4) which ran like a champ over a TAC to a TOPS-20
Kermit no longer will talk.  File transfers abort without a single
packet successfully passed.  Probably due to the new TAC software...
Anybody got a fix?
-------
 9-Sep-86 04:30:21-MDT,922;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Sep 86 04:30:15-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a029835; 9 Sep 86 5:48 EDT
Received: from USENET by SMOKE.BRL.ARPA id a008114; 9 Sep 86 5:44 EDT
From: David Shanks <[e-mail]>
Newsgroups: net.micro.pc,net.micro.cpm,net.wanted.sources
Subject: need z80 cross assembler and disassembler
Message-ID: <[e-mail]>
Date: 5 Sep 86 16:20:15 GMT
To:       [e-mail]

I am looking for an inexpensive or free (public domain) set of tools to
assemble and disassemble z80 code.  If these tools are not in source code
form they should run on an IBM PC.  Will anyone who knows of such tools
please contact me by mail.  Thanks.
--
Dave Shanks             ..!tektronix!tessi!atelabs!cds
AT&E Laboratories
1400 NW Compton  Suite 300
Beaverton, OR  97006
[phone]
 9-Sep-86 06:58:42-MDT,1474;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Sep 86 06:58:34-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a002150; 9 Sep 86 8:21 EDT
Date: Tue, 9 Sep 1986  06:22 MDT
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: ZAP34B bug - must contact author

Bug report: ZAP34.MQC, included in ZAP34B.LBR, has a checksum error
when unsqueezing.  We need a replacement for this file.  If anyone
knows how to contact Peter G. Martin, please let me know.  Below are
some excerpts which may help in locating him.

--Keith Petersen, W8SDZ, Co-SysOp RCP/M Royal Oak (MI) 313-759-6569

----------
                SUPERZAP MOD 3.4  DOCUMENTATION
                from Peter G. Martin  24 July 1986

(UPDATED 24 July 1986 -- 3.4b version)

This version adapts version 3.3 as updated by John Hastwell-Batten,
SYSOP for Tesseract RCPM, and adds some additional functions on John's
'wish-list' as well as some I had on my own wish-list.

From ZAP34.MAC:

;       SUPERZAP - A screen-oriented disk editor for CP/M-80
;
;       Versions prior to 3.x by Davidson and Sheldrake
;
;       Upgraded to CP/M+ operation by:
;               John Hastwell-Batten,
;               SYSOP, Tesseract RCPM+,
;               P.O. Box 242,
;               Dural, NSW 2158,
;               AUSTRALIA.
 9-Sep-86 09:08:44-MDT,948;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Sep 86 09:08:20-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a005799; 9 Sep 86 10:22 EDT
Received: from (FISHER)RPICICGE.BITNET by WISCVM.WISC.EDU on 09/09/86
  at 09:23:52 CDT
Date: 9 September 86 10:18-EST
From:  [e-mail]
To:  [e-mail]
X-Acknowledge:
Subject: BITNET mail follows

Date: 9 September 1986, 10:15:02 EAS
From: FISHER at RPICICGE
To:   INFO-CPM at AMSAA.ARPA
Re:   Information on SQ, CRUNCH, ARC and LBR formats

I am interested in writting some IBM-based utilities for dealing
with PD archive files before shipping to my micro.  Can somebody
point me at the appropriate documentation, etc, for the format of
ARC and LBR files and for the compression algorithms used by the
SQ and CRUNCH utilities?

Micro-happiness to all,
John Fisher              [e-mail]
 9-Sep-86 09:18:48-MDT,828;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Sep 86 09:18:35-MDT
Received: from apg-3.arpa by AMSAA.ARPA id a006312; 9 Sep 86 10:34 EDT
Date: Tue, 9 Sep 86 10:31:20 EDT
From: John Shaver STEEP-TMAC 879-7602 <[e-mail]>
Subject: Re: Kermit <--> TAC problems
In-Reply-To: Your message of 8 Sep 1986 22:08:10 EDT
To: Rex Buddenberg <[e-mail]>
Cc: [e-mail], [e-mail]

SRI-NIC@NIC has a file for kermit on TACS.  IT suggests the following commands
to the TAC and explains them which I shan't.

@DCA
or rather @D C A         :ass the TAC expect words sepearated by spaces
@F I S
@F O S
@I 6                              :this changes the @@ to a CTRL-F

Kermit runsl ike a champ after these few commands.

John

 9-Sep-86 11:05:12-MDT,2286;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Sep 86 11:04:55-MDT
Received: from brl-vgr.arpa by AMSAA.ARPA id a009694; 9 Sep 86 12:29 EDT
Received: from ADA20.ISI.EDU by VGR.BRL.ARPA id aa15776; 9 Sep 86 12:22 EDT
Date:  9 Sep 1986 09:19:58 PDT
Subject: Where's my Avatex?
From: Daniel Reigada <[e-mail]>
To: [e-mail]
cc: [e-mail]
Message-ID:  <[e-mail]>

     I read Keith Petersen's message of July 28 on the Avatex 1200 bps modem
and Steve Sanders glowing testimonial, and decided that I could finally break
away from the 300 baud mode.  I ordered the Avatex from The Wholesale Outlet of
Albany, NY, and charged it to my Visa account.

     A few days later I received a note from them saying that the modem was on
back order and would be shipped in 30 days.  Well, at $87 I figured I could
wait a bit.

     After a little more than 30 days had passed, UPS dropped off a package
which I eagerly opened to find, not an Avatex but, an EasyData 1200D.  A quick
look at the invoice revealed that the price was not $87 but $110.

     Has this happened to anyone else on the net?

     Is this some kind of "bait-and-switch" scam?

     Should I call The Wholesale Outlet and cuss at them or thank them?

     Does anyone have any experience using this modem?

     This modem is manufactured by a company called GCH Systems of Sunnyvale,
CA.  I quickly tried it out on the DDN and it worked flawlessly at 300 and 1200
bps.  (My old 300 baud modems would be affected by noisy phone lines and would
result in numerous crc errors while downloading).

     It seems to do everything the Avatex does and it has a built-in speaker
too.  I realize that $110 is still a great price for a 1200 bps modem but I
can't help feeling a bit uneasy about this unexpected substitution.

     Any information on this "EasyData 1200D" modem or on "GCH Systems" or on
"The wholesale Outlet" or just a few soothing words to allay my fears, will be
greatly appreciated.
                    -Dan-
==============================================================================
    " Nothing is absolute."     Can I rely on that?    ABSOLUTELY!
-------
 9-Sep-86 18:16:00-MDT,1404;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Sep 86 18:15:46-MDT
Received: from ucb-vax.arpa by AMSAA.ARPA id a002211; 9 Sep 86 19:05 EDT
Received: by ucbvax.Berkeley.EDU (5.53/1.16)
    id AA29533; Tue, 9 Sep 86 14:02:28 PDT
Received: by ucdavis.UCDAVIS.EDU (4.12/4.7)
    id AA03686; Tue, 9 Sep 86 13:24:14 pdt
Received: by clover.ucdavis.edu (4.12/4.7)
    id AA17767; Tue, 9 Sep 86 13:22:43 pdt
Date: Tue, 9 Sep 86 13:22:43 pdt
From: Eric Hildum <ucdavis!clover![e-mail]>
Message-Id: <[e-mail]>
To: ucdavis![e-mail]
Subject: MAC compatible assembler


Gentlemen:

I need to locate a public domain assembler compatible with the MAC assembler
supplied by Digital Research.  As I am trying to modify a BIOS apparently
assembled with this assembler, I also need the macro libraries containing
the disk parameter table macros.

My access to the network is somewhat restricted by the form of our connection;
however I can transfer files located on SIMTEL20.

                Thank you,
                  Eric Hildum


        Preferred:    [e-mail]
                [e-mail]
                ucdavis!clover![e-mail]
                ucdavis!clover![e-mail]

        Otherwise:    [e-mail]
                [e-mail]
                [e-mail]
 9-Sep-86 18:47:45-MDT,671;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Sep 86 18:47:37-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a002347; 9 Sep 86 19:53 EDT
Date: Tue 9 Sep 86 17:51:41-MDT
From: Rick Conn <[e-mail]>
Subject: SLR
To: [e-mail]
Message-ID: <[e-mail]>

    Thought you might be interested ... a bunch of SLR software
came today, including Z80ASM, and, while I haven't tried it yet, it really
looks like a nice tool based on my review of the documentation.  I also
talked to SLR today and the guy mentioned that SLR and Echelon are talking
again.

        Rick
-------
 9-Sep-86 20:39:46-MDT,2586;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Sep 86 20:39:36-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a002719; 9 Sep 86 22:03 EDT
Date: Tue, 9 Sep 1986  20:05 MDT
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Cc:   [e-mail]
Subject: ARC LBR and Crunched files

No need to re-invent the wheel.  There are already IBM-PC programs to
deal with these files.  Here is the latest info on bootstrap files
available from SIMTEL20.

--Keith
                      GETTING STARTED

CP/M-80 files:

PD:<CPM.STARTER-KIT>COMPRESS.TXT <--explains compressed files
PD:<CPM.STARTER-KIT>LU300.DQC    <--explains CP/M "LU" program
PD:<CPM.STARTER-KIT>LU310.COM    <--the LU program itself
PD:<CPM.STARTER-KIT>LU310.HLP    <--and a help file for it
PD:<CPM.STARTER-KIT>SQ111.COM    <--CP/M-80 file squeezer
PD:<CPM.STARTER-KIT>SQUEEZE.TXT  <--explains squeezed files
PD:<CPM.STARTER-KIT>UNARC.COM-Z80 <--extracts files from ARCs (Z80 only)
PD:<CPM.STARTER-KIT>UNARCA.COM-8080 <--ditto, for 8080
PD:<CPM.STARTER-KIT>USQ120.COM   <--CP/M-80 file unsqueezer
PD:<CPM.STARTER-KIT>USQ120.DOC   <--how to use it
PD:<CPM.STARTER-KIT>UUDECODE.COM <--uudecode for CP/M-80
PD:<CPM.STARTER-KIT>UUENCODE.COM <--uuencode for CP/M-80

MS/PCDOS files:

PD:<MSDOS.STARTER>ARC51.COM   <--when run makes ARC512.EXE and DOC
PD:<MSDOS.STARTER>ARCE120.COM <--fast ARC file extractor
PD:<MSDOS.STARTER>ARCE120.DOC <--how it works
PD:<MSDOS.STARTER>ARCV106.COM <--ARC directory lister
PD:<MSDOS.STARTER>ARCV106.MSG <--how it works
PD:<MSDOS.STARTER>LUE220.COM  <--extracts files from LBR's
PD:<MSDOS.STARTER>LUE220.DOC  <--how it works
PD:<MSDOS.STARTER>LUU208.LBR  <--adds files to LBR's
PD:<MSDOS.STARTER>NUSQ110.COM <--file UnSQueezer
PD:<MSDOS.STARTER>NUSQ110.DOC <--how it works
PD:<MSDOS.STARTER>SQDATE.DOC  <--how dates are put into squeezed files
PD:<MSDOS.STARTER>SQPC129.DOC <--how SQPC12A works
PD:<MSDOS.STARTER>SQPC12A.COM <--file SQueezer
PD:<MSDOS.STARTER>UUDECODE.BAS <--decodes uuencoded files (BASIC) (slow)
PD:<MSDOS.STARTER>UUDECODE.EXE <--decodes uuencoded files
PD:<MSDOS.STARTER>UUDECODE.PAS <--decodes uuencoded files (Turbo Pascal)
PD:<MSDOS.STARTER>UUENCDEC.DOC <--notes on uuencode/uudecode EXE for MSDOS
PD:<MSDOS.STARTER>UUENCODE.EXE <--makes uuencoded files, see DOC file note
PD:<MSDOS.STARTER>UUENCODE.PAS <--makes uuencoded files (Turbo Pascal)
 9-Sep-86 21:02:02-MDT,794;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Sep 86 21:01:55-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a002755; 9 Sep 86 22:12 EDT
Date: Tue, 9 Sep 1986  20:14 MDT
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   Eric Hildum <ucdavis!clover![e-mail]>
Cc:   [e-mail]
Subject: MAC compatible assembler
In-reply-to: Msg of 9 Sep 1986  14:22-MDT from Eric Hildum <ucdavis!clover!hildum at ucb-vax.ARPA>

This may not be fully MAC compatible, but it's worth a try.  It's a
public domain Z80 macro assembler.

Filename            Type     Bytes     CRC

Directory PD:<CPM.ASMUTL>
Z80MR.LBR.1            BINARY     41344  B0D0H

--Keith
 9-Sep-86 23:18:05-MDT,1366;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Sep 86 23:17:57-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a002946; 10 Sep 86 0:46 EDT
Received: from (CSNET)UKANVAX.BITNET by WISCVM.WISC.EDU on 09/09/86 at
  22:53:50 CDT
Date:     Tue, 9 Sep 86 22:53 CDT
From:        [e-mail]
MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
Subject:  archive-request Catch-22
To:  [e-mail]
X-Original-To:  [e-mail], CSNET

I have a problem concerning the archive-request mechanism that is
in place at SIMTEL20.

It seems that when I attempt to get the <CPM.STARTER-KIT> files (in
particular USQ120.COM), I receive the file in a 'squeezed' format.
Well, needless to say, I cannot unsqueeze this file (I am using
the SEND RAW PD:<CPM.STARTER-KIT>USQ120.COM request command.)

Am I doing something wrong?  Is there a way of getting a USQ120.ASM?

Or have I yet to fly the required number of bombing missions?
Is Major Major in? Oh, he is only 'in' when he is not here?  :-)

                                        Thanks in advance,

                                        Dave Long
                                        KU-CS

                        BITNET:  [e-mail]
                        CSNET:   [e-mail]

 9-Sep-86 23:20:04-MDT,4037;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 9 Sep 86 23:19:54-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a002944; 10 Sep 86 0:43 EDT
Date: Tue, 9 Sep 1986  22:44 MDT
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Cc:   [e-mail], [e-mail], [e-mail]
Subject: $299 2400 bps modem

I just received the following file from Steve Sanders on my RCP/M:

--cut here--2400$299.MDM--cut here--

                   Best Deal Yet for 2400 Baud

Basic Time 2400 baud modems  ------------>>> $ 2 9 9 . 0 0

                     Auto-Dial  Auto-Answer

Either internal (IBM-PC) or external standalone type modems, fully Hayes
dial compatible and 2400/1200/600/300/110 bps capable conforming to the
CCITT V.22/V.22 bis and Bell 212A standards.  Automatic adaptive equal-
ization which adjusts to telephone lines and decreases error rate.

Internal modem uses only a 1/2 slot on the IBM-PC and gives you an
external RS-232C port.  Comes with PC-Talk III software on disk.

External version has 8 LED indicators and a snap hatch front for easy
access to DIP switches.  External version is also asynch or synchronous
capable.  Tough plastic case.  Modem cable req'd for external modems.

Both modems are supplied with modular phone cords.

   >>> Full 30-day money-back guarantee if not satisfied <<<

QUBIE
570 Calle San Pablo
Camarillo, Calif 93010

1-800-821-4479  Visa/ Master Card

+++++++++++++++++++

Addt'l comments 08/08/86

I now have one of the Basic Time 2400 modems, I placed an order
for it on a Monday and rec'd the modem on Thursday ($5 extra for
UPS Blue Label service.)  As you know, I already have 2 Courier
2400 modems and have been 100% satisfied with them, but I wanted
to try one of the BT modems - the price looked to good to be true.

The BT2400E (external RS-232C version) is housed in a slimline
plastic enclosure with 8 LEDs on the front and NO hardware DIP
switches - all configuration is done via software.  I was a little
bothered by the lack of the familiar DIP switches until I found
out how easy the modem is to software program - now I don't
miss the DIP switches at all!  The BT2400E modem has more features
than the Couriers (did I say that!) and at a savings of around
$75 - latest mail order price on Courier is $375.00

I have been giving the BT2400E a real work-out the last 3 or
4 days and am happy to report that it works fine at 1200 or 2400
baud to all the systems I have called.  The modem appears to have
good filtering as I have not experienced any more line noise than
I do with the Couriers.  I am using the modem with PibTerm and
ProComm modem programs for the IBM-PC and it's a perfect match.
The only thing you need do is issue an intialization string when
the modem is first brought online.  The default settings have
the DTR and DCD lines ALWAYS HIGH - so for normal modem mode
you need to issue the following string:

                   AT &D2 &S1 &C1 &W <return>

This command tells the modem to respond normally to the flow
control on the DTR line and DCD line and then stores this data
internally in its non-volatile memory.  Configuring a modem via
software is much simpler than changing DIP switches which usually
entails pulling off a faceplate to access the switches.

All in all, I give the BT2400E modem 5 stars out of a possible
5 stars.  The price is great, the delivery is quick, the modem
performs 100% and seems to be very compatible with most other
2400 baud modems, and the supplier (QUBIE) stands behind the
product with a 30-day money back guarantee of satisfaction.
How could you lose on a deal like this - you have 30 days to
try it and see if it meets your needs.


              Steve Sanders - DataCOM Systems

            [phone] modem 300/1200/2400

{eof}
10-Sep-86 02:53:24-MDT,1054;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 10 Sep 86 02:53:18-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a003394; 10 Sep 86 4:19 EDT
Date: Wed, 10 Sep 1986  02:21 MDT
Message-ID: <[e-mail]>
From: [e-mail]
To:   [e-mail]
Cc:   [e-mail], [e-mail]
Subject: archive-request Catch-22
In-reply-to: Msg of 9 Sep 1986  21:53-MDT from CSNET%UKANVAX.BITNET at wiscvm.ARPA

Dave,

The "RAW" format applies only to ASCII text files.  Thus, your
"Catch-22" observation is quite valid.  The following HEX versions of
those key files now exist, which you can request in "RAW" format:

Filename                        Type     Bytes   CRC

Directory PD:<CPM.STARTER-KIT>
UNARC.HEX-Z80.1                 ASCII     9928  3613H
UNARCA.HEX-8080.1               ASCII    11459  4B24H
USQ120.HEX.1                    ASCII     4382  AEA9H
UUDECODE.HEX.1                  ASCII    25555  50F5H

--Frank
10-Sep-86 03:22:38-MDT,1170;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 10 Sep 86 03:22:22-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a003492; 10 Sep 86 4:34 EDT
Received: from (IFF095)DJUKFA11.BITNET by WISCVM.WISC.EDU on 09/10/86
  at 03:35:36 CDT
Date: Wed, 10 Sep 86 10:33:39 MEZ
To:  [e-mail]
From:  [e-mail]
Subject: NOTE from IFF095

Date: 10 September 1986, 10:24:32 MEZ
From: Joachim K. Anlauf         [phone]       IFF095   at DJUKFA11
To:   INFO-CPM at AMSAA

Subject: SQ, CRUNCH, ARC, LBR and vice versa on IBM mainframes

I think there was a misunderstanding in a reply to John Fishers letter about
informations on SQ, CRUNCH,... formats. He seems to have the same problem as
me. We are working on IBM mainframes and want to look at the file we get
from SIMTEL20 before shipping them to our micros. Documentation files can be
printed on high speed printers. There is no need to ship them via telephone
lines to the micros. My question: Is there any software available for IBM
mainframes (not PC's) to do the job? Thanks in advance for any reply.
Joachim Anlauf
10-Sep-86 04:09:35-MDT,1437;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 10 Sep 86 04:09:29-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a003670; 10 Sep 86 5:41 EDT
Received: from (IFF095)DJUKFA11.BITNET by WISCVM.WISC.EDU on 09/10/86
  at 04:42:20 CDT
Date: Wed, 10 Sep 86 11:41:53 MEZ
To:  [e-mail]
From:  [e-mail]
Subject: NOTE from IFF095

Date: 10 September 1986, 11:31:20 MEZ
From: Joachim K. Anlauf         [phone]       IFF095   at DJUKFA11
To:   INFO-CPM at AMSAA

subject: Need help for turbo-pascal(-bug?)

I have the following problem with a program, using the turbo tool-box
(access system version 1.0) and turbo pascal version 3.00A.
I wrote a program that uses 2 different databases and 4 different
index-files. Sometimes the program runs perfectly. Somtimes, when I only
add a few lines of code, the program crashes immediatly, without coming
to the added code. Sometimes senceless error messages  occur with
filenames made of random characters. Then I switch on the $U+ compiler
option without any other changes on the program and the program perfectly
runs again. It is a mystery for me. I never had any difficulties with
this version of turpo pascal before. All other programs are still running
so it is not the hardware. Is there someone out there who has an idea?
Any, really any, comments are welcome.
Joachim Anlauf
11-Sep-86 01:06:38-MDT,1795;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Sep 86 01:06:28-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a026966; 11 Sep 86 0:28 EDT
Date: Wed, 10 Sep 1986  19:37 MDT
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: Apple CP/M overlays for BYE5

The following Apple CP/M overlays for BYE5 are now available from
SIMTEL20:

Filename            Type     Bytes     CRC

Directory PD:<CPM.BYE5>
B5AA-3.IQS.1            BINARY      4608  9797H
B5AB-1.IQS.1            BINARY      8448  88CEH
B5AC-1.IQS.3            BINARY      2432  3BBAH
B5AS-2.IQS.1            BINARY      3840  F82EH

B5AA-3.IQS is the BYE5 insert for the Apple ][, ][+, or //e, with PCPI
Applicard Z80 card and Super Serial card. This version corrects the
bug that prevented BYE5 from dropping DTR to hang up the phone when
the caller typed 'BYE'. Tested with Prometheus Promodem with good
results.

B5AB-1.IQS is the BYE5 insert for Apple // with the ALS CP/M+ card and
Super Serial card.

B5AC-1.IQS is the BYE5 insert for the Apple ][, ][+, or //e with the
Microsoft Softcard (or clone) and Applecat plug-in modem card.

B5AS-2.IQS is the BYE5 insert for the Apple ][, ][+, or //e with
Microsoft Softcard (or clone) and Super Serial Card. It probably will
also work on the Apple //c with ZRAM or equivalent Z80 enhancement.
Version 2 corrects the address offset problem and should be fully
functional. Tested on Apple ][+, Softcard, Super Serial card, and
Prometheus Promodem with good results.

--Keith Petersen
Arpa: [e-mail]
uucp: {ihnp4,allegra,cmcl2,decvax,mcnc,mcvax,vax135}!seismo!SIMTEL20.ARPA!w8sdz
GEnie Mail: W8SDZ
RCP/M Royal Oak: 313-759-6569
11-Sep-86 03:44:49-MDT,685;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Sep 86 03:44:43-MDT
Received: from seismo.css.gov by AMSAA.ARPA id a027426; 11 Sep 86 5:02 EDT
Return-Path: <unido!nixpbe>
Received: from unido.UUCP by seismo.CSS.GOV with UUCP; Thu, 11 Sep 86 05:00:04 EDT
From: Nixdorf UUCP <unido![e-mail]>
Message-Id: <[e-mail]>
Received: by unido.uucp with uucp;
      Thu, 11 Sep 86 10:30:54 +0200
Subject: help
Date: loschner Wed Sep 10 14:54:06 1986
To: [e-mail]

please send more details on your subjects and
describe the way how to get information about
your activities.

J. Loschner
11-Sep-86 04:29:08-MDT,2090;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Sep 86 04:28:49-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a027548; 11 Sep 86 5:42 EDT
Received: from USENET by SMOKE.BRL.ARPA id a023387; 11 Sep 86 5:35 EDT
From: Dave Haynie <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Re: Re: C128 info
Message-ID: <[e-mail]>
Date: 9 Sep 86 19:55:14 GMT
To:       [e-mail]

>
> Can somebody tell me all the CP/M formats (double sided as well as
> single sided) the Commodore 128 will read and convert to run.
>
> Larry

The C128 has built-in code to read and write Kaypro II, Kaypro IV,
Osborne Double Density, and some kind of IBM format.  The limit on
this, however, is only the software.  I believe there is at least one
public domain program out there that will set the 1571 drive up for many
different formats.  The 1571 drive has a programmable MFM controller that
can read most of the CP/M formats that have been used once it is properly
set up.  As for software compatibility, the C128 is most compatible with
a Kaypro.  This is basically screen driver compatibiliy, as I've found most
CP/M stuff to be very transportable (Epson stuff is often an exception to
this; they do quite a bit of machine specific things).  The C128 screen
driver is an ADM-31 (or ADM-3A) with a few extensions for color.  Some
Kaypro machines have a few non-compatible extensions to the ADM standard,
though the latest versions of the C128 BIOS (December '85 or later) are
a bit more Kaypro compatible than the early C128 BIOS was.


--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Dave Haynie    {caip,ihnp4,allegra,seismo}!cbmvax!daveh

    "I gained nothing at all from Supreme Enlightenment, and
     for that very reason it is called Supreme Enlightenment."
                            -Gotama Buddha

    These opinions are my own, though for a small fee they be yours too.
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
11-Sep-86 04:49:12-MDT,2037;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Sep 86 04:49:04-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id aa27548; 11 Sep 86 5:42 EDT
Received: from USENET by SMOKE.BRL.ARPA id a023403; 11 Sep 86 5:35 EDT
From: Dave Haynie <[e-mail]>
Newsgroups: net.micro.cbm,net.micro.cpm
Subject: Re: Z80 Cartridge for C64... HELP!!!
Message-ID: <[e-mail]>
Date: 9 Sep 86 19:58:31 GMT
To:       [e-mail]

> Xref: cbmvax net.micro.cbm:455 net.micro.cpm:598
>
> Hi all!
> I seem to be having some trouble with the Z80 cartridge I purchased recently
> for my C-64.  It doesn't want to boot up on my machine.  I did find some
> information that the Z80 will not work on the later models of the C-64,
> namely, the 3rd and 4th models.
> Does anybody out there have any information on how to make the Z80 work on
> these later models?  It would be a great help.
>
> Thanks in advance,
>
> Bill Myers
> Penn State/York
> [e-mail]
>

You've found a classic problem , which is waht resulted in the Z-80 card
being discontinued.  The original card worked fine on the C64 that it was
designed for.  That machine used a Revision 5 (as I recall) VIC chip.
Later on, the VIC was revised to cure a problem it had with sparkling
characters.  That impacted on total system timing, but no effort was made
to fix the CP/M card.  The result is that if you have a system with a
REV 7 or 8 VIC, you have less than about 50% chance of the CP/M card
working.

--
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Dave Haynie    {caip,ihnp4,allegra,seismo}!cbmvax!daveh

    "I gained nothing at all from Supreme Enlightenment, and
     for that very reason it is called Supreme Enlightenment."
                            -Gotama Buddha

    These opinions are my own, though for a small fee they be yours too.
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
11-Sep-86 06:07:15-MDT,1087;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Sep 86 06:07:01-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a028647; 11 Sep 86 7:35 EDT
Received: from USENET by SMOKE.BRL.ARPA id a024807; 11 Sep 86 7:39 EDT
From: [e-mail]
Newsgroups: net.micro.cpm
Subject: Great Lakes drive doc?
Message-ID: <104600010@uiucuxc>
Date: 8 Sep 86 22:25:00 GMT
Nf-ID: #N:uiucuxc:104600010:000:490
Nf-From: uiucuxc.CSO.UIUC.EDU!grayson    Sep  8 17:25:00 1986
Posted: Mon Sep  8 18:25:00 1986
To:       [e-mail]


Does anybody have the documentation which tells how to format a
Great Lakes hard disk drive?  It's a 23MB drive which runs off a
serial port (!).  Please send mail.

        uucp:   [e-mail]
    old uucp:    {ihnp4,pur-ee}!uiucdcs!uiucuxc!grayson
    internet:   [e-mail]
       telex:    5101011969 UI TELCOM URUD --> Dan Grayson, Altgeld Hall.
     us mail:    Dan Grayson, Math Dept, Univ of Ill, Urbana 61801
       phone:    [phone] home   217-333-6209 office
11-Sep-86 10:38:05-MDT,795;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Sep 86 10:37:48-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a007298; 11 Sep 86 11:48 EDT
Received: from (MEK)UMASS.BITNET by WISCVM.WISC.EDU on 09/11/86 at
  10:49:46 CDT
Message-ID:  <860911114332.00000638.AGZM.MA@UMass>
Date:     Thu, 11 Sep 86  11:43:32 EDT
From:  [e-mail]
Subject:  ARC format
To:  [e-mail]
cc:  [e-mail]

Is there a file anywhere, perhaps on SIMTEL20, that defines the ARC
file format, similiar to LUDEF5.DOC?  Please respond to me directly
as I don't subscribe to Info-IBMPC.  Thanks!

/ Matt Kimmel,
 [e-mail]

\ The poor neutron, he thought he was a proton but he wasn't positive.
11-Sep-86 13:00:07-MDT,1026;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 11 Sep 86 12:59:56-MDT
Received: from lll-mfe.arpa by AMSAA.ARPA id a010824; 11 Sep 86 13:15 EDT
Date: Thu, 11 Sep 86 13:13 EST
From: [e-mail]
Subject: Kudos for Frank, Keith, et.al. re Archive-Server
To: [e-mail]

From:    <[e-mail]>   (Richard C. Secrist)
Date:    Thu, 11-SEP-1986 13:14 EST
To:      [e-mail]
Message-ID: <[OAK.SAINET.MFENET].6F0E8940.008F4CE1.SECRIST>
Header-Disclaimer: I don't like my headers either !
X-VMS-Mail-To: CPM

Just a note of sincere thanks to Frank, Keith, and everyone else who put
up the SIMTEL20 archive-server for all for us !  Your efforts are most
appreciated, and as soon as I recover from the feeding frenzy brought
about by this Christmas-in-September, I'll be sure to show my gratitude
with uploads !  Thank you VERY much !

Richard (aka rcs)
[e-mail]
13-Sep-86 06:17:01-MDT,1085;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 13 Sep 86 06:16:55-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a000960; 13 Sep 86 7:40 EDT
Received: from USENET by SMOKE.BRL.ARPA id a011368; 13 Sep 86 7:35 EDT
From: Andrew Klossner <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Cheap S-100 memory?
Message-ID: <[e-mail]>
Date: 11 Sep 86 16:57:12 GMT
To:       [e-mail]

Now that RAM chip prices have dropped through the floor ...

Can anyone recommend a cheap board with a huge slug of memory for an
IEEE S-100 system, with memory mapping suitable for CP/M 3?  My CPU
board (a 1978 vintage Ithaca) doesn't do appropriate memory mapping.
In 1983 there was a great little board, with each 4k page independently
mappable, for a couple of grand; seems like it should cost a couple of
hundred by now if still in production.

Thanks,

  -=- Andrew Klossner   (decvax!tektronix!tekecs!andrew)       [UUCP]
                        (tekecs!andrew.tektronix@csnet-relay)  [ARPA]
13-Sep-86 09:30:40-MDT,907;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 13 Sep 86 09:30:30-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a001657; 13 Sep 86 11:03 EDT
Received: from (MEK)UMASS.BITNET by WISCVM.WISC.EDU on 09/13/86 at
  10:04:54 CDT
Message-ID:  <860913095025.000005B8.AQUF.MA@UMass>
Date:     Sat, 13 Sep 86  09:50:25 EDT
From:  [e-mail]
Subject:  UUENCODING
To:  [e-mail]
cc:  [e-mail], [e-mail]

I have heard of an article, which I believe was posted to net.unix,
which described in detail the operation of UUENCODE so it could be
implemented in any language on any system.  Does anyone out there
know how I could obtain a copy of this article?  Please respond
to me directly as I do not subscribe to Info-UNIX.  Thanks!

Matt Kimmel,
[e-mail]
Pi is secretly rational!
13-Sep-86 13:54:01-MDT,2115;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 13 Sep 86 13:53:48-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a002380; 13 Sep 86 15:11 EDT
Date: Sat, 13 Sep 1986  13:13 MDT
Message-ID: <[e-mail]>
From: [e-mail]
To:   [e-mail]
Subject: Special characters in TOPS-20 filenames

All the files in our collections which were uploaded as-is from
existing collections, such as CPMUG, SIG/M, and PC/BLUE, have
some filenames containing "special characters" as far as our TOPS-20
file system is concerned.  These characters are not considered
"special" by their respective operating systems, but they must be
quoted by prefixing a ^V immediately prior to each such character.

I have scanned our collections, and the following special characters
currently exist in the filenames:

& - ampersand          @ - at sign
/ - slash              + - plus sign
# - pound sign         ^ - caret
% - percent sign       ' - single quote
! - exclamation mark

In general, all punctuation characters are considered special.  When
in doubt, it doesn't hurt to prefix the character with a ^V, except
for the period between the filename and filetype.

Those of you accessing our collections via FTP have already discovered
this ^V prefix requirement.  However, those of you accessing our
system through ARCHIVE-REQUEST may be wondering why you are getting
back "File Not Found" messages.  This ^V prefix requirement is part of
the reason.  The other part is that there is a bug in the runtime
library for the version of the C compiler I am using for the server
and some of the utilities it uses.  The next release should have this
fixed and hopefully I will have figured out how to have the server
automatically insert the ^V prefix where required so that you need not
have to bother remembering to do so.

Where that leaves us at the moment is that files with those special
characters, especially the slash, imbedded in filenames are currently
inaccessible via ARCHIVE-REQUEST.

--Frank
14-Sep-86 03:19:39-MDT,2206;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 14 Sep 86 03:19:21-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a003742; 14 Sep 86 4:38 EDT
Date: Sun, 14 Sep 1986  02:32 MDT
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: Quick reference list of SIMTEL20 CP/M directories

Quick reference list of SIMTEL20's PD:<CPM.x> directories
as of Sept. 14, 1986 (where 'x' is one of the names below):

22RSX         CCP           FILUTL        MODEM         STARTER-KIT
6502          COBOL         FINANCE       MODEM2        SUBMIT
AMETHYST      COMND         FORTH-83      MODEM7        SYSUTL
APPLE         CPM3          FORTRAN       MSOFT         T20-SQUSQ
ASMUTL        CPM68K        GENASM        NEWS          TERM
ATARI         CPM86         GENCOM        NSTAR         TOPS-20
AZTEC-C       CPMINFO       GENDOC        NUBYE         TRS-80
BASIC         CPMLIB        GENIE         OSBORN        TURBODOS
BBS           CPR86         GRAPHICS      PACKET        TURBODOS-SIGI
BBSLISTS      CUG           HAMMING       PASCAL        TURBOPAS
BDOS          DATABASE      HAMRADIO      PBBS          TXTUTL
BDSC-1        DBASEII       HDUTL         PILOT80       VAXVMS
BDSC-2        DEBUG         HEATH         PLOT33        VDOEDIT
BDSC-3        DIRUTL        HELP          PPSPEL        VOICE
BDSC-4        DISASM        HEX           PUBKEY        WSTAR
BSTAM         DISKPLOT      IMP           PUBPATCH      XCCP
BYE3          DSKBUF        INSIDCPM      RBBS          XLISP
BYE5          DSKUTL        KAYPRO        RBBS4         YAM
BYT85FEB      EDITC80       LIST          RCPM          Z8EDEBUG
BYT85JAN      EDITOR        MACLIB        ROS           ZCPR
C128          EDUCATION     MATH          SCREENGEN     ZCPR2
C64           EMX           MBBS          SMALLC21      ZCPR3
C80           EPSON         MEMTEST       SORT          ZMODEM
CATLOG        FAST2         MEX           SPELL
CB80          FILCPY        MICNET        SQU-PORT
CBIOS         FILE-DOCS     MISC          SQUSQ
14-Sep-86 16:26:15-MDT,1902;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 14 Sep 86 16:26:05-MDT
Received: from nosc.arpa by AMSAA.ARPA id a005742; 14 Sep 86 17:39 EDT
Received: by bass.ARPA (5.31/4.7)
    id AA12739; Sun, 14 Sep 86 14:41:15 PDT
Message-Id: <[e-mail]>
Date: Sun, 14 Sep 86 14:21:36 PDT
From: Marc Wilson <crash!pnet01![e-mail]>
To: [e-mail]
Subject: AMPRO MULTIFMT utility


     I have a small problem which I hope that those of you out there in
net-land may be able to help me with....

     I have an Ampro LB computer. The BIOS that Ampro supplies with the
machine ( currently v3.8 ) allows reading/writing from approximately sixty
different formats, with a utility included to format about half of them as
well. Problem: I have 2 96-tpi drives... and I need to format a 48-tpi
disk. The read/write routines use something called a "double-step bit" to
enable the 96 track drive to read a 48 track disk. This is done in the
BIOS, and the utilities include an option to set this bit.

     Is there a way to cause the drives to "double-step" so that I can use
the MULTIFMT program, which does *not* include this option? Or is it
impossible? I would appreciate any insights.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Marc Wilson

        ARPA: ...!crash!pnet01!mwilson@nosc             ( preferred )
              ...!crash!pnet01!pro-sol!mwilson@nosc

        UUCP: [ ihnp4 | cbosgd | sdcsvax | noscvax ]!crash!pnet01!mwilson@nosc

     "The difference between science and the fuzzy subjects is that science
      requires reasoning, while those other subjects merely require
      scholarship."

                                                      -Lazarus Long

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
14-Sep-86 21:34:48-MDT,1320;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 14 Sep 86 21:34:41-MDT
Received: from umd2.arpa by AMSAA.ARPA id a006356; 14 Sep 86 23:01 EDT
Date: Sun, 14 Sep 86 22:40:27 EDT
From: Manasseh Katz <[e-mail]>
To: [e-mail]
Subject: Unsqueezing files
Message-ID: <M1986$[e-mail]>

I have uuencode/uudecode working for CPM-86.  I would like to get other
files from SIMTEL20, but most of them are squeezed (or ARCed) and I can't
get an unsqueeze program in an unsqueezed format.  If there is someone
out there who can send me a uuencoded unsqueeze program for CPM-86 through
mail or if someone can find a way to get the program from archive-request
at simtel20 then I will be really grateful.  It seems to be no problem
for CPM-80 and MS/DOS, but CPM-86 seems to be a problem.  If noone can
help then I will have to try something else (I'm not sure exactly what...)
Thanks in advance (I hope).
                                Manasseh Katz
                                [e-mail] or [e-mail]
                                (I am somewhat confused about where this
                                node fits into the scheme of things)
                                or [e-mail]

15-Sep-86 14:34:20-MDT,1116;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 15 Sep 86 14:34:11-MDT
Received: from csnet-relay.arpa by AMSAA.ARPA id a023675; 15 Sep 86 15:05 EDT
Received: from gmr.com by csnet-relay.csnet id ah01670; 15 Sep 86 12:18 EDT
Date:     Mon, 15 Sep 86 09:18 ???
From:     RLH <[e-mail]>
To:       [e-mail]
Subject:  simtel20 archive access

Is the mail server that allows remote access to the SIMTEL20 PD archives
working?

I sent two requests for the info files, one about 10 days ago and the
second about a week ago. I have gotten nothing back - not even an
"addressee unknown" error message. Since I didn't get a message saying
that it was undeliverable, I assume my message got thru to ARCHIVE-REQUEST.

My only suspicion is that the server was not able to correctly extract
a return address for me since the chain of VAX/VMS mail to CSNET phone
mail to ARPANET can produce some bizarre address syntax.

Can anyone tell me what is going on?

    Bob Haar
    G.M. Research Labs

    HAAR.GMR.COM@CSNET-RELAY
15-Sep-86 14:36:20-MDT,749;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 15 Sep 86 14:36:12-MDT
Received: from xerox.arpa by AMSAA.ARPA id a027444; 15 Sep 86 16:15 EDT
Received: from CheninBlanc.ms by ArpaGateway.ms ; 15 SEP 86 07:23:06 PDT
Date: Mon, 15 Sep 86 07:23 PDT
From: [e-mail]
Subject: Re: AMPRO MULTIFMT utility
In-reply-to: <[e-mail]>
To: Marc Wilson <crash!pnet01![e-mail]>
cc: [e-mail]
Message-ID: <860915-072306-5640@Xerox>



A 96 tpi drive requires a floppy disk designed for 96 tpi (called high
density).  You can format a high density disk to 48 tpi but only on a 96
tpi drive.  Subsequent writes on a 48 tpi drive will be unreliable.

15-Sep-86 18:12:31-MDT,874;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 15 Sep 86 18:12:19-MDT
Received: from nosc.arpa by AMSAA.ARPA id a029498; 15 Sep 86 19:29 EDT
Received: by bass.ARPA (5.31/4.7)
    id AA01319; Mon, 15 Sep 86 16:31:10 PDT
Message-Id: <[e-mail]>
Date: Mon, 15 Sep 86 15:20:12 PDT
From: Marc Wilson <crash!pnet01![e-mail]>
To: [e-mail]
Subject: Re: AMPRO MULTIFMT utility

     What you are referring to is a quad density disk. As I said earlier, I
have been using normal DSDD and even SSDD disks in these drives witth no
problems. I have been trading files between the PC I was using at school and
my CP/M machine here at home, in both directions, with no problems.

     There has *got* to be a way to do this!


                                                    --Marc
15-Sep-86 23:14:43-MDT,13353;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 15 Sep 86 23:14:14-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a000491; 16 Sep 86 0:10 EDT
Date: Mon, 15 Sep 1986  22:12 MDT
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail]
Subject: More on ZAS and SLR assemblers
Reply-To: [e-mail]

I just received the following file on my RCP/M.

--Keith Petersen
Arpa: [e-mail]
uucp: {ihnp4,allegra,cmcl2,decvax,mcnc,mcvax,vax135}!seismo!SIMTEL20.ARPA!w8sdz
GEnie Mail: W8SDZ
RCP/M Royal Oak: 313-759-6569
--cut here--ZAS-SLR2.DOC--cut here--
            THE LIBRARIES, ZAS, AND THE SLR ASSEMBLERS -- PART 2

                                  Jay Sage
                             September 11, 1986


                                 Background

     After reading Richard Conn's article on the libraries in Micro/Systems
Journal (MSJ), I felt that Richard had been highly misleading in his
statements such as the following:

     SYSLIB Version 3.6 (the most recent version) is written in the
     ZAS assembler language and can only be assembled by the ZAS
     assembler (SYSLIB.REL is provided in the distribution, so it is
     not necessary to be able to assemble SYSLIB in order to use it).

This statement and an identical one about Z3LIB Version 1.3 imply that
anyone who wants to work with the library source code has to go out and buy
ZAS.  I felt that this impression needed to be corrected, especially where
(in my opinion) ZAS is at best a mediocre assembler, particularly in
contrast to the superb assemblers from SLR systems that are available at
nearly the same price.  I released the file ZAS-SLR.DOC to clarify matters.
Richard has now released his rebuttal in ZAS-STD.DOC.  While Richard's
comments in MSJ were merely misleading, some of those in ZAS-STD.DOC could
well be construed as an affront to what is left of the 8-bit programmer
community.  More on that a little later.  First I would like to deal
specifically with Richard's comments in rebuttal to mine.


                       Rebuttal to Richard's Rebuttal

     In Richard's responses to my comments I thought I was reading something
composed by the State Department -- a lot of semantic sidestepping to
distract one's attention from the real issue, the misleading statements in
the MSJ article.

     First Richard corrects me concerning his employment by Echelon.  OK,
let's use the words "very closely associated, including financially"
instead.  Actually, I may indeed have been wrong.  I had been told several
months ago by someone definitely in a position to know that Richard was
working full time for Echelon.  Perhaps I misunderstood; perhaps things did
not work out as planned; perhaps the legal relationship is technically not
employment.  It really doesn't matter.  The real issue is that Richard is
using ZAS not because he examined a lot of assemblers and found ZAS to be
the best.  He uses it, I submit, because it is the product promoted by
Echelon.  AND THERE IS NOTHING WRONG WITH THAT.  There would also be nothing
wrong with his being employed by Echelon and supporting his employer by
using and promoting the employer's products (the fact that Richard makes no
money directly from the sales of ZAS is irrelevant; I don't make any money
directly from my employer's sales either).  What is wrong is to promote
those products in a misleading way.

     Richard pointed gleefully to my admission that SLR's Z80ASM assembler
could not fully assemble the SYSLIB source as released.  I ask the rest of
the community out there: Do you think that, in the nearly three hundred
modules and thousands of lines of code, five lines with ".IN LUDDEF" that
have to be changed to "INCLUDE LUDDEF.LIB" justify conveying the impression
that you better go out and buy ZAS if you want to use the source code?  I
find it very hard to believe that anyone who would know what to do with the
source code would have any trouble whatsoever converting the source back to
one of the standard assembler formats.

     Richard states that SLR's Z80ASM cannot assemble the latest Z3LIB
without completely editing the source (though in the same text he also
states that he has never seen or used the SLR assembler!).  In fact, Z80ASM
assembles the latest releases of Z3LIB (1.3) and VLIB (1.1) without any
problems at all.  Perhaps Richard was referring to a future version of the
libraries.  Is he planning to make deliberate use of idiosyncrasies of the
ZAS assembler to make sure that only ZAS can be used?  Even then I am sure
there would be no serious difficulty in converting the code to a format
suitable for conventional assemblers.

     To sum all this up, I repeat my previous statement that if Richard had
said something like "the most recent versions of the libraries are written
in the ZAS assembler language and might require some minor changes for use
with other assemblers" I would have had no problem and would not have
written ZAS-SLR.DOC.


                            Two Technical Asides

     While I was running the code through the SLR assemblers, I decided to
check my speculation that the libraries contained only 8080-compatible
opcodes (Richard implied repeatedly in the article that the older releases
of the libraries were for 8080 but that the current versions were for Z80
and HD64180 only).  SLR's fancier, virtual-memory assembler Z80ASM+ has an
option to flag any non-8080 instructions as errors (its further ability to
flag absolute jumps that could be replaced by relative jumps saved
significant code in VFILER 4.1).  I ran it on all modules of all three
libraries.  Only four modules contained any Z80-specific opcodes.  These
were in the same library-utility modules that have the ZAS-specific ".IN"
pseudo-ops.  Since these are the newest routines, they suggest that Richard
is now writing code that will not support 8080- and 8085-based computers.
This in not a criticism; I also think it is time to start taking advantage
of the Z80 opcodes.  (The SLR assemblers carry this to a very high degree,
increasing speed and efficiency by making extensive use of alternate and
index registers.)  I would leave it to the minority with 8085s to convert
the source and release 8080 versions of the libraries.

     While I am on asides, let me note another technical shortcoming of the
coding in the libraries (in ZAS-SLR.DOC I noted a few inconsistencies in
symbol names).  None of the routines place their uninitialized data space
into data segments (DSEGs).  As a result, COM files made using the libraries
include useless bytes that slow down loading and take up extra disk space.
This has been a problem with all Z programs.  It's not an earthshaking
matter, but it is completely unnecessary.  VFILER Version 4.1 is the first Z
program (to my knowledge) where the main program has support for DSEGs.  I
am now in the process of modifying the libraries code for VFILER.  The
linking step is more complicated (except with SLR's virtual-memory linker
SLRNK+, which does it automatically), requiring two linking operations, one
to determine the end of the program space (CSEG) and a second one to perform
the linkage with the data space ORGed immediately after the program space.
With SLRNK this is no big deal, since it will perform two linkages in less
time than other linkers can do one.  And during development there is no need
to place the data space precisely at the end of the code space.


                     The Standard for 8-Bit Assemblers

     Now I turn my attention to the part of Richard's ZAS-STD.DOC that I
feel is a real chutzpah.  In that file we learn that Richard Conn (King
Richard, perhaps) has decreed a new standard for assembly language that we
all must follow if we want to be a part of the Z programming community.  He
argues very eloquently and convincingly for the value of standards, pointing
to the example of Ada, his other major interest.

     I, too, place a high value on standards, especially when they are a
help to everyone.  But consider how standards are usually arrived at in a
democratic society.  Several steps are involved:

    1.  Notice is given to the community that a standard is being
        considered;

    2.  A committee of experts and interested parties is formed to
        oversee the development of the standard;

    3.  Existing products are examined, studied, and evaluated;

    4.  Input is solicited from the community at large.

     Richard Conn, as far as I can tell, has done none of these things!
First, the announcement of "The ZAS Standard" in ZAS-STD.DOC fell like a
bombshell.  I have not seen any notice in Z-News or on Z-Node Central of the
intention to formulate and enforce an assembler standard.  There is a BIG
difference between ZAS as the only assembler sold and supported by Echelon
and ZAS as THE STANDARD assembler.  Any company may choose to market a
particular product, but only IBM then declares it to be a world standard
(actually, even IBM doesn't do that; their choice just becomes the de facto
standard).

     Second, there has been no committee of experts, at least not a public
one.  Richard Conn, perhaps with others on the "Echelon Team", seems to have
appointed himself.  Does Echelon really think it is the IBM of the 8-bit
world?!

     Third, from Richard's own text we see that no examination of existing
products has been conducted.  He states plainly in that text that he has
never seen the SLR assemblers.  Anyone who keeps himself at all informed
about activities in the computer world other than his own would surely have
noticed the advertisements for the SLR tools.  The utterly outrageous (but
true!) claims in those ads should have at least led a standards setter to
investigate.

     Fourth, since the community was not even notified of an impending
standard, its input was neither solicited nor given consideration.  We have
been presented with a fait accompli.  I, and I am sure others, would like to
ask that Richard Conn show some genuine respect for the rest of the 8-bit
programming community by paying a little attention to our ideas in addition
to his own.  That means not only listening to us when we talk directly to
him but more importantly looking at the new programs and program
enhancements that we release and at the dialogue on Z-Node Central and the
other Z-Nodes.  And it also means actively soliciting input before he makes
decisions that he expects the whole community to follow.

     Richard's actions would be open to criticism even if the standard
decreed for us were a good one, but it is not.  When Echelon first offered
ZAS, many of us in the community wanted to and tried to support it.
Unfortunately, we found it to be a very mediocre assembler plagued with a
continuing series of problems and deficiencies (I don't want to go into them
here).  I have reached the point where I am no longer willing to expend the
effort to check my code for ZAS compatibility; Joe Wright, a member (or
former member?) of the Echelon Team, has even consented to be quoted in the
SLR advertisements (I would, too).

     It is with regret that I make the above statements about ZAS.  In
general, the Echelon product line is a superb one that lives up to Echelon's
image of excellence.  Many of the products (the DSD debugger and REVAS3
disassembler) are, I think, the best available.  Joe Wright's auto-install Z
System packages are marvels of ingenuity; ZRDOS offers excellent new
functionality; ZCPR3 itself, the centerpiece, is dazzling.  ZAS,
unfortunately, stands out like a sore thumb in this list.  When I first used
the SLR assemblers, my immediate reaction was: There are the assemblers that
belong in the Echelon product line!


                              A Silver Lining

     There is a silver lining I am happy to report.  Yesterday Richard sent
a message over the INFO-CPM mailing list on the Defense Data Network (ARPA-
NET), where our previous round of files also appeared, noting that he had
just received copies of the SLR assemblers and, though he had not yet used
them, was impressed with them based on the documentation.  He also reported
that Echelon and SLR Systems are talking.  Perhaps this false start at
standard-setting will be set aright, and we will all benefit.


                               Final Footnote

     Lest anyone take the above remarks excessively seriously, I would like
to temper them by adding that under circumstances such as these I am given
to a degree of overstatement.  After all, with nothing but a steady stream
of superb new Z programs week after week, one looks for something to break
the monotony.  And why should Frank Gaude' with his Z-News be the only one
to provide some color?  Of course, Frank's style and mine are not exactly
the same, and I prefer Cabernet Sauvignon to Zinfandel.
16-Sep-86 08:24:53-MDT,557;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 16 Sep 86 08:24:46-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a007496; 16 Sep 86 9:36 EDT
Received: from USENET by SMOKE.BRL.ARPA id a000894; 16 Sep 86 9:33 EDT
From: [e-mail]
Newsgroups: net.micro.cpm
Subject: A Z System ??
Message-ID: <[e-mail]>
Date: 10 Sep 86 13:49:26 GMT
Sender: [e-mail]
To:       [e-mail]

Pardon me for asking this
::::::::
What is a Z system ?
::::::::
16-Sep-86 17:24:58-MDT,744;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 16 Sep 86 17:24:42-MDT
Received: from usc-eclc.arpa by AMSAA.ARPA id a021513; 16 Sep 86 16:00 EDT
Date: Tue 16 Sep 86 11:28:56-PDT
From: Dick <[e-mail]>
Subject: Re:AMPRO MULTIFMT utility
To: [e-mail]
Desires:"gag me with a Valley girl"    (ohmigod!)
Message-ID: <[e-mail]>


Contrary to a previous message, you DON'T HAVE to have 96tpi floppies for
a 96tpi drive. I use the cheapest SSSD $7.00 a box floppies in my SA465's
which are 80trk DSDD.. the problem with formatting 48tpi disks on 96tpi
drives is the track is narrower, and may not be readable by other 48tpi
drives..\
-------
16-Sep-86 17:35:42-MDT,2352;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 16 Sep 86 17:35:23-MDT
Date:     Tue, 16 Sep 86 15:36:25 EDT
From:     David Towson (SECAD) <[e-mail]>
To:       [e-mail]
Subject:  Let's "mellow out" a bit!

Fellow CP/Mers - I have been reading with interest but also with growing
concern the exchange of messages between Jay Sage and Rick Conn concerning
Rick's adoption of the ZAS assembler as a "standard" for his further develop-
ment of ZCPR and related software.  The "discussion" started off a bit on the
"edgy" side, but it is now rapidly approaching nasty.  This is a real shame,
because Jay is generally raising reasonable questions of interest to many of
us, and I for one would like to hear the answers.  But having witnessed one
p___ing contest on this list already (it was about a modem program, a couple
years ago), I definitely don't want to see that happen again.

     In my opinion, Rick Conn DOESN'T OWE US ANYTHING!  He has created and
donated free of cost an ENORMOUS software suite that takes about 5 megabytes
of storage in the archive.  This is the result of several years of work,
and it still boggles me that Rick has GIVEN IT AWAY.  Just reading through the
pounds of well written documentation seems to take forever!  So if Rick wants
to standardize on the ZAS assembler (or COBOL, or SNAFU, or whatever), it's
entirely his business, and I don't think we have any RIGHTS in the matter.
Rick may possibly do some things that will cut off part of the community who
are currently enjoying his efforts, and that will be sad.  I don't think this
has happened yet, but if it does, I hope to see some messages in this forum
seeking a compromise solution.  I also hope such messages will be courteous
and respectful.  After all, even the creator of 5 megabytes of first class
free software can screw up occasionally!

     So let's continue to explore the new directions Rick's efforts are
taking.  If Rick says some things that seem inaccurate or that we don't
understand, let's ask him about them.  But let's also remember that Rick isn't
a one-man benevolent society.  He is not our servant.  Even if we strongly
disagree with what he is saying, let's be graceful about it.

     Let's mellow out a bit, PLEASE!


Dave

16-Sep-86 19:32:46-MDT,730;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 16 Sep 86 19:32:41-MDT
Received: from nprdc.arpa by AMSAA.ARPA id a024060; 16 Sep 86 20:38 EDT
Received: by nprdc.arpa (4.12/ 1.1)
    id AA14896; Tue, 16 Sep 86 17:40:47 pdt
From: Mel Moy <[e-mail]>
Message-Id: <[e-mail]>
Date: 16 September 1986 1740-PDT (Tuesday)
To: [e-mail]
Subject: Re: Let's "mellow out" a bit!
Cc: [e-mail], [e-mail]

Hear, hear! to Dave Towson's comments.  If there are those who
take exception to Rick Conn's choice, then let them blaze the
"road not taken".  They can be tomorrow's heros rather than
today's martyrs.

Mel

16-Sep-86 21:43:23-MDT,657;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 16 Sep 86 21:43:18-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a024354; 16 Sep 86 23:09 EDT
Date: Tue 16 Sep 86 21:07:37-MDT
From: Rick Conn <[e-mail]>
Subject: New files in ZSYS
To: [e-mail]
Message-ID: <[e-mail]>

    I've placed Jay Sage's recent diatribe and the responses to it
that I received today in PD:<ZSYS.NEW> and <ZSYS.DOC> as ZAS-SLR2.DOC
and ZAS-SLR3.DOC (actually, Keith already posted SLR2.DQC - thanks,
Keith).  I'll probably formulate a reply in a day or two.

        Rick
-------
17-Sep-86 15:01:37-MDT,653;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 17 Sep 86 15:01:15-MDT
Received: from usc-ecl.arpa by AMSAA.ARPA id a012876; 17 Sep 86 16:09 EDT
Date: Wed 17 Sep 86 13:10:57-PDT
From: Ted Shapin <[e-mail]>
Subject: Re: AMPRO MULTIFMT utility
To: crash!pnet01![e-mail]
cc: [e-mail]
In-Reply-To: <[e-mail]>
Phone: [phone]; Mail:Beckman Instruments, Inc.
Mail-addr: 2500 Harbor Blvd., X-11, Fullerton CA 92634
Message-ID: <[e-mail]>

Ampro has their own BBS at [phone].  Try asking them.
-------
18-Sep-86 12:26:11-MDT,824;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 18 Sep 86 12:25:57-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a028802; 18 Sep 86 13:43 EDT
Received: from USENET by SMOKE.BRL.ARPA id a001070; 18 Sep 86 13:31 EDT
From: Blackwell <[e-mail]>
Newsgroups: net.micro.cpm
Subject: MIDI for Otrona Attache
Message-ID: <[e-mail]>
Date: 15 Sep 86 15:28:55 GMT
To:       [e-mail]

I have just completed a simple MIDI interface for the Otrona Attache.
I have tested it with my Ensoniq ESQ-1, but it should work with anything else...
If anyone out there is interested, drop me a note.

NOTE:  This is just the hardware part; the software part should keep me
busy for quite a while :-)

< These opinions are, of course, my own...>
18-Sep-86 12:33:04-MDT,1609;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 18 Sep 86 12:32:54-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id aa28802; 18 Sep 86 13:45 EDT
Received: from USENET by SMOKE.BRL.ARPA id a001109; 18 Sep 86 13:32 EDT
From: "A. Dain Samples" <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Re: Kudos for Frank, Keith, et.al. re Archive-Server
Message-ID: <[e-mail]>
Date: 16 Sep 86 18:27:18 GMT
Sender: [e-mail]
To:       [e-mail]

In article <[e-mail]> [e-mail] writes:
>
>Just a note of sincere thanks to Frank, Keith, and everyone else who put
>up the SIMTEL20 archive-server for all for us !  Your efforts are most
>appreciated, ...
>
>Richard (aka rcs)
>[e-mail]

My thanks, too!  However, being a relatively new subscriber to the group, I
only know of the existence of this boon, and not how to take advantage of
it.  Perhaps it was in a message I didn't read closely enough because
I didn't know what I had, but  ...

Would it be possible for someone to post again how someone can take
advantage of the SIMTEL20 archives?  What kind of account is needed, and
where, and how to know what to order, etc.

I apologize if this produces tedious net.mail for others, but I would sure
appreciate some assistance here.

Dain
A. Dain Samples, 573 Evans, UC Berkeley, [e-mail]
All opinions expressed herein are mine, and do not reflect the opinions of
anyone that does not want them to.
18-Sep-86 13:04:00-MDT,962;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 18 Sep 86 13:03:53-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a028859; 18 Sep 86 13:45 EDT
Received: from USENET by SMOKE.BRL.ARPA id a001208; 18 Sep 86 13:33 EDT
From: Luis Basto <[e-mail]>
Newsgroups: net.micro.cpm
Subject: RE: Kudos for Frank, Keith, etc.
Message-ID: <[e-mail]>
Date: 16 Sep 86 18:15:28 GMT
To:       [e-mail]

>Just a note of sincere thanks to Frank, Keith, and everyone else who put
>up the SIMTEL20 archive-server for all for us !  Your efforts are most
>appreciated . . .
>
>Richard (aka rcs)
>[e-mail]

Lots of thanks from me also. You must have crossed very difficult
barriers to get this whole thing set up for the benefit of everyone.
Now people can upload/download faster than mailing disks.
Excellent work you guys are doing!

Luis Basto
18-Sep-86 21:51:25-MDT,2214;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 18 Sep 86 21:51:17-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a007321; 18 Sep 86 22:33 EDT
Date: Thu, 18 Sep 1986  20:16 MDT
Message-ID: <[e-mail]>
From: [e-mail]
To:   [e-mail]
Subject: Recent changes to the Archive Server

For those of you who missed the announcement, send a message to
ARCHIVE-REQUEST@SIMTEL20 which contains the one line: SEND INFO
in the message body.  Please do not send to ARCHIVE-SERVER via your
reply mechanism as it ends up in my mailbox and delays processing of
your requests.

I have made a couple of changes in the Server.  The first is that you
will no longer need to remember to quote certain characters in
filenames which are "special" characters to TOPS-20.  The Server now
does that for you, except for the slash ("/") character, and I expect
that to be fixed shortly.  (That means that any file with a slash in
the filename will show up as Not Found for now.)

The second change is to block certain extremely large files from being
processed in their original form.  These files are available from
other sources, as are most of the files we keep here.

In the two weeks since the availability of this service was announced,
we have processed just over 2,800 requests.  About 200 of those were
requests for the basic HELP, INFO, and BOOTSTRAP files.  About 260
were for filenames that didn't exist for one reason or another, and
about 300 resulted in multi-part replies.  The remaining 2,100
requests were answered with one message file in reply.  Of those, only
200 were for directory listings; the remaining 1,900 requests were for
actual files.

This is certainly a very active rate, and far greater than I
anticipated.  But, then again, I had no way to even guess the rate.
We seem to be able to tolerate the additional load to a point.
However, I still am considering a less responsive frequency and push
the processing back to nights and weekends.  This may happen without
warning, especially after other groups receive the notice that this
service is available...

--Frank
19-Sep-86 01:17:38-MDT,568;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 19 Sep 86 01:17:32-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a007697; 19 Sep 86 2:12 EDT
Date: Thu 18 Sep 86 23:40:27-MDT
From: Rick Conn <[e-mail]>
Subject: My final reply
To: [e-mail]
Message-ID: <[e-mail]>

... to Jay Sage's messages is in PD:<ZSYS.NEW> and <ZSYS.DOC> as
ZAS-SLR4.DOC.  I don't plan to reply to any further messages from Jay
until after I finish my current workload.

    Rick
-------
20-Sep-86 18:37:26-MDT,668;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 20 Sep 86 18:37:13-MDT
Received: from xerox.arpa by AMSAA.ARPA id a010760; 19 Sep 86 8:23 EDT
Received: from Aurora.ms by ArpaGateway.ms ; 19 SEP 86 05:24:54 PDT
From: [e-mail]
Date: 19 Sep 86 8:24:48 EDT
Subject: Re: MIDI for Otrona Attache
In-reply-to: [e-mail]'s message of 15 Sep 86 15:28:55
 GMT, <[e-mail]>
To: Blackwell <[e-mail]>
cc: [e-mail]
Message-ID: <860919-052454-1054@Xerox>

I'd be very interested in seeing the circuit diagram, or reading a description
of it.

Thanks,
Pete
20-Sep-86 18:39:07-MDT,1000;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 20 Sep 86 18:38:55-MDT
Received: from lll-mfe.arpa by AMSAA.ARPA id a026628; 20 Sep 86 12:06 EDT
Date: Sat, 20 Sep 86 12:07 EST
From: [e-mail]
Subject: RUNOFF woes
To: [e-mail]

From:    <[e-mail]>   (Richard C. Secrist)
Date:    Sat, 20-SEP-1986 12:08 EST
To:      [e-mail]
Message-ID: <[OAK.SAINET.MFENET].AA19E420.008F53EA.SECRIST>
Header-Disclaimer: I don't like my headers either !
X-VMS-Mail-To: CPM

On SIMTEL20 I can't seem to get PD:<SIGM.VOL085>RUNOFF.COM, a text
formatter in Pascal similar to the PDP-11 version, to run for me...
has anyone else succeeded ?  If you don't pass it params or some-
thing it fires up and asks you to try again, but once it opens
files it says "PAGE 1" on the output device and quits.

Looking for inspiration...

rcs
[e-mail]
21-Sep-86 11:18:36-MDT,6156;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 21 Sep 86 11:18:16-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a029482; 21 Sep 86 12:25 EDT
Date: Sun, 21 Sep 1986  10:27 MDT
Message-ID: <[e-mail]>
Sender: [e-mail]
From: Keith Petersen <[e-mail]>
To:   [e-mail], [e-mail]
Subject: Technical Information for ARC files

ARC-FILE.INF, created by Keith Petersen, W8SDZ, 21-Sep-86, extracted
from UNARC.INF by Robert A. Freed.

From:     Robert A. Freed
Subject:  Technical Information for ARC files
Date:     June 24, 1986

Note: In the following discussion, UNARC refers to my CP/M-80 program
for extracting files from MSDOS ARCs.  The definitions of the ARC file
format are based on MSDOS ARC512.EXE.

ARCHIVE FILE FORMAT
-------------------

Component files are stored sequentially within an archive.  Each entry
is preceded by a 29-byte header, which contains the directory
information.  There is no wasted space between entries.  (This is in
contrast to the centralized directory used by Novosielski libraries.
Although random access to subfiles within an archive can be noticeably
slower than with libraries, archives do have the advantage of not
requiring pre-allocation of directory space.)

Archive entries are normally maintained in sorted name order.  The
format of the 29-byte archive header is as follows:

Byte 1:  1A Hex.
         This marks the start of an archive header.  If this byte is not found
         when expected, UNARC will scan forward in the file (up to 64K bytes)
         in an attempt to find it (followed by a valid compression version).
         If a valid header is found in this manner, a warning message is
         issued and archive file processing continues.  Otherwise, the file is
         assumed to be an invalid archive and processing is aborted.  (This is
         compatible with MS-DOS ARC version 5.12).  Note that a special
         exception is made at the beginning of an archive file, to accomodate
         "self-unpacking" archives (see below).

Byte 2:  Compression version, as follows:

         0 = end of file marker (remaining bytes not present)
         1 = unpacked (obsolete)
         2 = unpacked
         3 = packed
         4 = squeezed (after packing)
         5 = crunched (obsolete)
         6 = crunched (after packing) (obsolete)
         7 = crunched (after packing, using faster hash algorithm) (obsolete)
         8 = crunched (after packing, using dynamic LZW variations)

Bytes 3-15:  ASCII file name, nul-terminated.

(All of the following numeric values are stored low-byte first.)

Bytes 16-19:  Compressed file size in bytes.

Bytes 20-21:  File date, in 16-bit MS-DOS format:
              Bits 15:9 = year - 1980
              Bits  8:5 = month of year
              Bits  4:0 = day of month
              (All zero means no date.)

Bytes 22-23:  File time, in 16-bit MS-DOS format:
              Bits 15:11 = hour (24-hour clock)
              Bits 10:5  = minute
              Bits  4:0  = second/2 (not displayed by UNARC)

Bytes 24-25:  Cyclic redundancy check (CRC) value (see below).

Bytes 26-29:  Original (uncompressed) file length in bytes.
              (This field is not present for version 1 entries, byte 2 = 1.
              I.e., in this case the header is only 25 bytes long.  Because
              version 1 files are uncompressed, the value normally found in
              this field may be obtained from bytes 16-19.)


SELF-UNPACKING ARCHIVES
-----------------------

A "self-unpacking" archive is one which can be renamed to a .COM file
and executed as a program.  An example of such a file is the MS-DOS
program ARC512.COM, which is a standard archive file preceded by a
three-byte jump instruction.  The first entry in this file is a simple
"bootstrap" program in uncompressed form, which loads the subfile
ARC.EXE (also uncompressed) into memory and passes control to it.  In
anticipation of a similar scheme for future distribution of UNARC, the
program permits up to three bytes to precede the first header in an
archive file (with no error message).


CRC COMPUTATION
---------------

Archive files use a 16-bit cyclic redundancy check (CRC) for error
control.  The particular CRC polynomial used is x^16 + x^15 + x^2 + 1,
which is commonly known as "CRC-16" and is used in many data
transmission protocols (e.g. DEC DDCMP and IBM BSC), as well as by
most floppy disk controllers.  Note that this differs from the CCITT
polynomial (x^16 + x^12 + x^5 + 1), which is used by the XMODEM-CRC
protocol and the public domain CHEK program (although these do not
adhere strictly to the CCITT standard).  The MS-DOS ARC program does
perform a mathematically sound and accurate CRC calculation.  (We
mention this because it contrasts with some unfortunately popular
public domain programs we have witnessed, which from time immemorial
have based their calculation on an obscure magazine article which
contained a typographical error!)

Additional note (while we are on the subject of CRC's): The validity
of using a 16-bit CRC for checking an entire file is somewhat
questionable.  Many people quote the statistics related to these
functions (e.g. "all two-bit errors, all single burst errors of 16 or
fewer bits, 99.997% of all single 17-bit burst errors, etc."), without
realizing that these claims are valid only if the total number of bits
checked is less than 32767 (which is why they are used in small-packet
data transmission protocols).  I.e., for file sizes in excess of about
4K bytes, a 16-bit CRC is not really as good as what is often claimed.
This is not to say that it is bad, but there are more reliable methods
available (e.g. the 32-bit AUTODIN-II polynomial).  (End of lecture!)

                           Bob Freed
                           62 Miller Road
                           Newton Centre, MA  02159
                           Telephone [phone]
23-Sep-86 02:49:20-MDT,863;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 23 Sep 86 02:49:05-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a022851; 23 Sep 86 4:21 EDT
Received: from (SINGPANG)HLERUL5.BITNET by WISCVM.WISC.EDU on 09/23/86
  at 03:22:51 CDT
Date:     Tue, 23 Sep 86 10:10 N
From:        [e-mail]
MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
Subject:  CP/M+ USER GUIDE
To:  [e-mail]
X-Original-To:  [e-mail], SINGPANG

Can somebody tell me where I can order the following book:

"The CP/M Plus User Guide" from Digital Research Inc.

The title might be different, I can't recall it exactly.

Do you know any (good) books on CP/M+?

Thanks

Marc Chang Sing Pang

ARPANET: [e-mail]

BITNET : SINGPANG@HLERUL5

23-Sep-86 09:02:05-MDT,1566;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 23 Sep 86 09:01:51-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a028311; 23 Sep 86 10:09 EDT
Received: from USENET by SMOKE.BRL.ARPA id a017244; 23 Sep 86 9:42 EDT
From: Mark Dapoz <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Re: simtel20 archive access
Message-ID: <[e-mail]>
Date: 17 Sep 86 19:43:18 GMT
To:       [e-mail]

[munch, munch, mun

In article <[e-mail]> [e-mail] writes:
>Is the mail server that allows remote access to the SIMTEL20 PD archives
>working?
>
>I sent two requests for the info files, one about 10 days ago and the
>second about a week ago. I have gotten nothing back - not even an
>"addressee unknown" error message. Since I didn't get a message saying
>that it was undeliverable, I assume my message got thru to ARCHIVE-REQUEST.
>
>My only suspicion is that the server was not able to correctly extract
>a return address for me since the chain of VAX/VMS mail to CSNET phone
>mail to ARPANET can produce some bizarre address syntax.
>

I've had the same problem over here.  I was almost ready to give up on my
request when a reply from it came through.  The final turnaround
time was OVER 10 days.  I have yet to receive a reply from 3 other
requests I sent in only hours after I sent my first request.  Is the
network really this slow?????  The only advice I have is wait (thats
what I'm still doing).

   Mark Dapoz
23-Sep-86 10:20:23-MDT,808;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 23 Sep 86 10:20:17-MDT
Received: from ll.arpa by AMSAA.ARPA id a001066; 23 Sep 86 11:31 EDT
Date: Tue 23 Sep 1986 11:27:56 EDT
From: [e-mail]
MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
Subject: What is a Z System
To: [e-mail]
Cc: [e-mail]
Message-ID: <[e-mail]>

Z-System is the name of the CP/M-replacement operating system from
Echelon, Inc.  It uses Richard Conn's ZCPR3 for the command processor
and Dennis Wright's ZRDOS disk operating system (replaces the BDOS).  This
is the state-of-the-art operating system for Z80 (and NS800 and HD64180
and even 8080 or 8085) computers.  If you are not using it, you should
definitely look into it.


23-Sep-86 10:46:51-MDT,674;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 23 Sep 86 10:46:45-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a029470; 23 Sep 86 10:47 EDT
Received: from USENET by SMOKE.BRL.ARPA id a019291; 23 Sep 86 10:14 EDT
From: jenkins <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Re: A Z System ??
Message-ID: <[e-mail]>
Date: 18 Sep 86 00:46:11 GMT
To:       [e-mail]

In article <[e-mail]>, [e-mail] writes:
> Pardon me for asking this
> ::::::::
> What is a Z system ?
> ::::::::

Perhaps a Z80 based CP/M system??


                Colin  ([e-mail])
23-Sep-86 11:22:03-MDT,714;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 23 Sep 86 11:21:43-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a002136; 23 Sep 86 12:19 EDT
Received: from USENET by SMOKE.BRL.ARPA id a024834; 23 Sep 86 11:53 EDT
From: "William L. Rupp" <[e-mail]>
Newsgroups: net.micro.cpm
Subject: need kermit for cp/m system
Message-ID: <[e-mail]>
Date: 19 Sep 86 21:41:26 GMT
Keywords: kermit, QT,cp/m
To:       [e-mail]

A co-worker at has an S-100 QT Systems CP/M computer with 8"drives and
a 10 meg hard-disk.  He uses a Cobar 3132 as a terminal.  If anyone
knows of a Kermit which will run on this system, please let me know.
23-Sep-86 11:49:36-MDT,851;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 23 Sep 86 11:49:24-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a001535; 23 Sep 86 11:50 EDT
Received: from USENET by SMOKE.BRL.ARPA id a022698; 23 Sep 86 11:14 EDT
From: Bill Opalka <[e-mail]>
Newsgroups: net.micro.cpm
Subject: P2DOS again
Message-ID: <[e-mail]>
Date: 18 Sep 86 18:05:06 GMT
Sender: [e-mail]
To:       [e-mail]


    Recently, I saw someone asking for help in getting P2DOS to run on a
Heath-89 computer but I never  heard how it was finally resolved.  Can anyone
out there tell me how to get P2DOS to run on an H89?  Also, has anyone written
documentation for P2DOS?  More importantly, what all the files are that came
with it.


thanks in advance,


/bill

23-Sep-86 12:14:16-MDT,4542;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 23 Sep 86 12:13:51-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a002456; 23 Sep 86 12:34 EDT
Received: from USENET by SMOKE.BRL.ARPA id a025260; 23 Sep 86 12:05 EDT
From: [e-mail]
Newsgroups: net.micro.cpm
Subject: Re: AMPRO MULTIFMT utility
Message-ID: <4800015@uiucdcsb>
Date: 18 Sep 86 17:22:00 GMT
Nf-ID: #R:brl-smoke.ARPA:3795:uiucdcsb:4800015:000:3879
Nf-From: uiucdcsb.CS.UIUC.EDU!kenny    Sep 18 12:22:00 1986
To:       [e-mail]


Excuse me for posting this to the net, but NOSC says that mwilson is an
unknown user.

Date: Thu, 18 Sep 86 12:15:28 CDT
From: kenny (Kevin Kenny)
To: [e-mail]
Subject: Writing 48 tpi on 96 tpi drives
Cc: kenny

We've been through this several times before... and I am already seeing the
incorrect explanations of the compatibility problems between 48 tpi and
96 tpi drives flying.  Here's a legitimate, simplified explanation.
Please feel free to repost to the whole net if you see enough wrong
ones go by (I've only seen two so far).

The 96 tpi drives place two tracks in the space where a 48 tpi drive
puts one:

        48 TPI                96 TPI
------------------------------------------------------------------------

################################|################################
################################|################################
################################|
################################|################################
################################|################################
                                |
################################|################################
################################|################################
################################|
################################|################################
################################|################################

                etc.

A 96 TPI drive can easily read a 48 TPI disk.  The narrow head sits in
the wide track
######## like ##############################
######## this ##############################
############################################ or
################################ like ######
################################ this ######

and has no problems picking up the data.  The problem comes when a 96
tpi drive WRITES a 48 tpi disk.  If the disk is truly blank and
unformatted, the 96 TPI head will write its narrow track and the 48 TPI
can read it because there isn't anything else there to read:

############################## +----+
############################## |    |
                               |wide|
                               |head|
                               +----+

But, if there's ANY data on the disk (say, for example, that the disk
was formatted on a 48 TPI machine), then when the 96 TPI drive writes
it, we'll have something like
                                +----+
################################|head|$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
################################+----+$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$
######################################################################
######################################################################
######################################################################

so that two different streams of data appear in the area that the 48
TPI head will read.  When the 48 TPI disk reads the data, it'll see
some sort of bizarre average of the two and get read errors.  (Don't
flame, physicists and those who understand the recording format.  I
SAID this was a simplified explanation).

Reformatting the disk on either style of drive won't help.  Nor will
duplicating the data on both half-tracks; they won't be precisely in
sync.  The only thing that can be done to REwrite a 48tpi disc on a
96tpi drive is run the whole shebang through a bulk degausser so that
you again have a blank, truly blank disk.

The degaussing is recommended in any case, since discs received from
the manufacturer sometimes have test patterns left on them and aren't
truly blank.

Most 96tpi manufacturers don't want to contend with these issues, so
they simply specify that you can read, but not write.

 ()    /\   .-.-.   /\    Kevin Kenny
()()  <  >   \ /   (__)    University of Illinois at Urbana-Champaign
 /\    \/     V     /\    UUCP: {ihnp4,pur-ee,convex}!uiucdcs!kenny
"When in doubt,        CSNET: [e-mail]
    lead trumps."    ARPA: [e-mail] ([e-mail])
23-Sep-86 13:05:48-MDT,1239;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 23 Sep 86 13:05:23-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a003878; 23 Sep 86 13:16 EDT
Received: from USENET by SMOKE.BRL.ARPA id a027357; 23 Sep 86 12:50 EDT
From: Robert Dale <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Re: simtel20 archive access
Message-ID: <[e-mail]>
Date: 20 Sep 86 09:51:32 GMT
Posted: Sat Sep 20 11:51:32 1986
To:       [e-mail]


Like Bob Haar (article <[e-mail]>), I too sent a request for the
INFO files to the SIMTEL20 PD archives, and received nothing in response.
Any suggestions as to what happened and how to get around it would be
appreciated.  Am I correct in suspecting that there will be a large number
of people who have experienced this problem?  If there's a problem with
working out return addresses, then is it possible that most or all people
who request information from the UK will also have this problem?

--

Robert Dale    University of Edinburgh, Centre for Cognitive Science,
                2 Buccleuch Place, Edinburgh, EH8 9LW, Scotland.

UUCP:    ...!ukc!cstvax!epistemi!rda
JANET:    [e-mail]
23-Sep-86 21:09:58-MDT,608;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 23 Sep 86 21:09:32-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a012090; 23 Sep 86 22:41 EDT
Received: from (PFENNIGE)CGEUGE51.BITNET by WISCVM.WISC.EDU on 09/23/86
  at 10:05:06 CDT
Date: 23 SEP 86 16:41-N
From:  [e-mail]
To:  [e-mail]
Subj: Disk conversion for Apple format

Hi!

Does anyone know if a disk conversion program exists between
Apple format and any MS-DOS format?

Thanks for the tips,

Daniel Pfenniger, Geneva Observatory, Switzerland
23-Sep-86 23:29:06-MDT,3443;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 23 Sep 86 23:28:53-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a012407; 24 Sep 86 0:44 EDT
Date: Tue, 23 Sep 1986  21:43 MDT
Message-ID: <[e-mail]>
From: [e-mail]
To:   [e-mail]
Subject: Archive Server response

The Archive Server program looks for a Reply-To: line, and if it
exists, it extracts, as-is, an address to use for the To: line in its
replies.  If the Reply-To: line is not found, then it uses the From:
line, if it exists.  If the From: line is not found, it logs the event
and proceeds to the next request message.  This is exactly the same
mechanism used by the Reply command of many user mail handler
programs.  In any event, the extracted return address is
case-preserved and no address conversion whatsoever is done.  Our
mailer, on the other hand, will convert the host name on the right of
the atsign to the Official Host Name IN THE ENVELOPE, not the header,
if the host name is found to be an alias.  This conversion has not
been the source of any of the problems seen so far.

Most of the problems in getting the mail out of here stem from a
rather severe congestion problem on the ARPANET side of DDN which has
been going on for the past two weeks.  This has been impacting replies
to be sent through CSNET-RELAY and WISCVM in particular.

Our mailer tries to send a message immediately, and failing that first
try, puts the message in a queue.  Failures are typically "Cannot
connect to host," which may mean that the host is not up or the host
is up but does not respond to a connection request within the
two-minute timeout window.

The mailer then attempts to send each message in that queue once an
hour for the next three days.  Notices are sent to the sender (me in
this case) when the message has not been sent after the first 24 and
then 48 hours.  After 36 hourly attempts, the failed message is sent
back to the sender (me) and I discard it.

However, if the message gets out of here, then the next bottleneck
would be at the gateway host or some intermediate site on the other
side of that host.  Sometimes even those eventually come back as
undeliverable because some host in the return address didn't exist or
did not respond in the timeout window.  Those get tossed too.

That's the way it is; it probably isn't going to get any better, and
may get a lot worse.

Of course it didn't help matters any that we had a severe head crash
on our boot disk early Friday morning and did not come back up until
late Saturday afternoon.  Messages scheduled to be timeout in that
period had one more chance when we came back up and then were returned
to sender.  Lenthy outages such as that one are very rare and the
missed attempts an unfortunate side-effect.  But, timeouts are the
only way to maintain sanity in our queues.

As for the server process itself, it appears that I will have to place
a limit on how many requests will be honored in any one message.  I
didn't place one because I thought people would be reasonable - I was
wrong.  The limit will be five (5) request lines in any one request
message, with the remainder ignored, probably with an appropriate
message.  Also, processing of requests will be suspended during prime
time on Fridays while we run our full backups.

--Frank
24-Sep-86 04:17:35-MDT,991;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 24 Sep 86 04:17:28-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a012825; 24 Sep 86 5:42 EDT
Received: from USENET by SMOKE.BRL.ARPA id a014451; 24 Sep 86 5:41 EDT
From: Paul Skuce <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Help
Message-ID: <[e-mail]>
Date: 22 Sep 86 16:38:21 GMT
Posted: Mon Sep 22 18:38:21 1986
To:       [e-mail]


Please could someone mail me about the workings of this news group.
! have just got a NEWBRAIN(t.m.) 96k cpm system with twin 5.25" drives.
I should like to beable to get at P.D. and shareware software etc.
        Regards
            Paul Skuce
        Hatfield Polytechnic, School Information Science, P.O. box109
        College Lane, Hatfield, England, AL10 9AB
            comt-ps%hatfield.ac.uk%mcvax%seismo%.. from States
            comt-ps%hatfield.ac.uk%mcvax%..        From Eur
               He is coming back.
24-Sep-86 08:59:50-MDT,1680;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 24 Sep 86 08:59:39-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a019395; 24 Sep 86 9:59 EDT
Received: from (FISHER)RPICICGE.BITNET by WISCVM.WISC.EDU on 09/24/86
  at 09:00:45 CDT
Date: 24 September 86 09:38-EST
From:  [e-mail]
To:  [e-mail]
X-Acknowledge:
Subject: BITNET mail follows

Date: 24 September 1986, 09:25:11 EAS
From: FISHER at RPICICGE
To:   INFO-CPM at AMSAA.ARPA
Re:   Getting P2DOS running on H89

     The basic problem I had with P2DOS stems from an error in the
support utilities provided in the distribution.  Somewhere during the
steps to relocate the .REL file the resulting .COM file grows to be
larger than 0E00h bytes.  I was zapping zeroes on top of the BIOS
when trying to overlay the BDOS.  At any rate,  LOAD/SAVE 14 resolves
the problem by shrinking the .COM file to its correct size.

     There is one other problem I encountered that is specific to
the H89's BIOS implementation.  P2DOS, as distributed, uses 0040h
and following for its file search path table.  0040ff has been
reserved by DRI for BIOS, not BDOS usage.  The Heath BIOS uses
that area for its logical/physical drive map.  So, either disable
the feature in P2DOS, or move it somewhere else.  (There is room
in P2DOS itself for it.  When I get some time, I'm going to try
it there).

     At this time I have it running just fine with the path
feature disabled.  I'm using it with ZCPR (as in ZCPR1) so the
path feature is only partly missing.


Happy netting,
John Fisher             [e-mail]
24-Sep-86 18:00:38-MDT,860;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 24 Sep 86 18:00:08-MDT
Received: from lll-crg.arpa by AMSAA.ARPA id a004130; 24 Sep 86 19:25 EDT
Received: Wed, 24 Sep 86 16:26:37 pdt by lll-crg.ARPA (4.12/)
    id AA27932; Wed, 24 Sep 86 16:26:37 pdt
Received: by csustan.UUCP (5.31/4.7)
    id AA27157; Wed, 24 Sep 86 15:49:01 PDT
Received: by polyslo.UUCP (4.12/4.7)
    id AA02457; Wed, 24 Sep 86 15:27:52 pdt
Date: Wed, 24 Sep 86 15:27:52 pdt
From: Marcos Della <csustan!polyslo![e-mail]>
Message-Id: <[e-mail]>
To: csustan!lll-crg![e-mail]
Subject: Adding to the mailing list

Can I be added to the information mailing list? I managed to
loose the address of the manager of info-cpm.

Marcos Della

mdella@polyslo
..!lll-crg!csustan!polyslo!mdella

25-Sep-86 05:00:13-MDT,2828;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 25 Sep 86 04:59:56-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a005305; 25 Sep 86 5:44 EDT
Received: from USENET by SMOKE.BRL.ARPA id a011035; 25 Sep 86 5:34 EDT
From: Fred Bowen <[e-mail]>
Newsgroups: net.micro.cbm,net.micro.cpm
Subject: MFM on C1571
Message-ID: <[e-mail]>
Date: 24 Sep 86 16:41:10 GMT
To:       [e-mail]


        I have recieved several requests for  information  regarding
        the creation of MFM-formatted disks using the Commodore 1571
        disk drive.  Hopefully this is enough to get you started.  A
        new FORMAT.COM file for C128 CP/M 3.0  should  be  available
        pretty soon-  watch your favorite BBS for it.

        Please refer to the 1571 Disk Drive User's Guide, Appendix G,
        page 101, for a complete description of the FORMAT MFM  burst
        command. The table below contains the data required to create
        a particular MFM disk format.  MD  and SS are given as binary
        values; the rest are decimal:


                 FMT         MD         SS      IL   N    LT   NS

             Epson QX10   01100110   10000001   0    2    39   10

             Osborne DD   01000110   10000001   0    3    39   5

             Kaypro II    01000110   10000000   0    2    39   10

             Kaypro IV    01010110   10001010   0    2    39   10

             IBM SS       01000110   10000001   0    2    39   8

             IBM DS       01100110   10000001   0    2    39   8



                MD   is the Mode                      byte 2
                SS   is the Starting Sector number         3
                IL   is the Interleave                     4
                N    is the Sector Size                    5
                LT   is the Last Track number              6
                NS   is the Number of Sectors              7



        The following BASIC program  demonstrates  how  a  FORMAT MFM
        command can be sent to a 1571 drive:

     10 OPEN  15,8,15
     20 PRINT#15,"U0"+CHR$(102)+CHR$(129)+CHR$(0)+CHR$(2)+CHR$(39)+CHR$(10)
     30 CLOSE 15

        The example above formats the disk in unit #8 using the Epson
        parameters.  Of course, you must still install the  necessary
        boot and directory sectors to make your DOS (CP/M) happy. The
        higher-level 1571 DOS commands,  such as Load, Save, and Dir,
        will never be happy with non-Commodore formats,  needless  to
        say, right?
--
Fred Bowen            uucp:    {ihnp4|seismo|caip}!cbmvax!fred
                arpa:    cbmvax![e-mail]
                tele:    215 431-9100

Commodore Electronics, Ltd.,  1200 Wilson Drive,  West Chester,  PA,  19380
25-Sep-86 08:49:46-MDT,1064;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 25 Sep 86 08:49:39-MDT
Received: from mit-xx.arpa by AMSAA.ARPA id a011806; 25 Sep 86 9:56 EDT
Date: Thu, 25 Sep 1986  10:03 EDT
Message-ID: <[e-mail]>
From: [e-mail]
To:   [e-mail]
cc:   [e-mail]
Subject: TAC usage
In-reply-to: Msg of 31 Aug 1986  13:23-EDT from Keith Petersen <W8SDZ at SIMTEL20.ARPA>

a few months ago, I asked the list for a guide to doing XMODEM
transfers through a TAC from a TOPS-20 machine (the one at MIT-XX)
using MODEM.  The one concrete suggestion I got was to say SNQ instead
of S to do the download.  It didn't work.

I have no trouble downloading using MODEM on TOPS-20 to download when
I talk directly on a dial-up line to the TOPS-20 machine.

My problem is that when I attempt to download through the TAC, I get
the message "bad header in record 1", "bad header in record 2", etc
until my MODM700 program quits on me.

Any suggestions?

Thanks.

Herb
25-Sep-86 17:44:40-MDT,1471;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 25 Sep 86 17:44:29-MDT
Received: from nosc.arpa by AMSAA.ARPA id a026711; 25 Sep 86 18:56 EDT
Received: by bass.ARPA (5.31/4.7)
    id AA17574; Thu, 25 Sep 86 15:57:50 PDT
Message-Id: <[e-mail]>
Date: Thu, 25 Sep 86 15:38:01 PDT
From: Marc Wilson <crash!pnet01![e-mail]>
To: [e-mail]
Subject: Automatic disk logging

     I want to add automatic disk logging to my BDOS ( P2DOS ), but I'm not
sure about how to go about it. So far, I've produced some very wrird behavior
patterns from the BDOS, but no success.

     I think what needs to be done is for BDOS to check each drive's status
upon it's selection, and reset it if it is R/O.

     Any comments or help would be greatly appreciated.


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Marc Wilson

        ARPA: ...!crash!pnet01!mwilson@nosc             ( preferred )
              ...!crash!pnet01!pro-sol!mwilson@nosc

        UUCP: [ ihnp4 | cbosgd | sdcsvax | noscvax ]!crash!pnet01!mwilson@nosc

     "The difference between science and the fuzzy subjects is that science
      requires reasoning, while those other subjects merely require
      scholarship."

                                                      -Lazarus Long

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
25-Sep-86 21:28:46-MDT,799;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 25 Sep 86 21:28:36-MDT
Received: from bbnccv.arpa by AMSAA.ARPA id a027665; 25 Sep 86 22:02 EDT
To: [e-mail]
cc: [e-mail], [e-mail]
Subject: Re: TAC usage
In-reply-to: Your message of Thu, 25 Sep 1986  10:03 EDT.
         <[e-mail]>
Date: 25 Sep 86 18:50:05 EDT (Thu)
From: Mike Barker <[e-mail]>


sounds like the TAC is in 7-bit ASCII mode, rather than binary.  Have
you tried B I S and B O S (I think those are the commands)?  They should
cause the TAC to go into binary mode with eight-bit characters (the
complemented count in the header is 8-bits, even if everything else is
only 7 bits).

    Good luck
    mike
26-Sep-86 08:45:15-MDT,1857;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 26 Sep 86 08:45:05-MDT
Received: from simtel20.arpa by AMSAA.ARPA id a009038; 26 Sep 86 9:44 EDT
Date: Fri, 26 Sep 1986  07:46 MDT
Message-ID: <[e-mail]>
From: [e-mail]
To:   Mike Barker <[e-mail]>
Cc:   [e-mail], [e-mail]
Subject: TAC usage
In-reply-to: Msg of 25 Sep 1986  16:50-MDT from Mike Barker <mbarker at bbnccv.ARPA>

Both MODEM and the newer TMODEM have code for two methods of
negotiating network binary mode for the TAC user for the duration of
the file transfer on TOPS-20 systems.  One method assumes that the
monitor does not double the IAC character (FFH) and thus allows the
user program to send the appropriate sequences in-band to the TAC.
The other method assumes that the monitor always doubles the IAC
character and provides a particular monitor call to provide the
capability to do that negotiation.

The problem is that some monitors double the IAC character always, but
have no local mod to provide the capability to turn on network binary
mode.  Thus, as Mike says, the user must give the TAC commands:

@B O S
@B I S

in that order.  The side effect of the @B I S is that the user can no
longer give any more TAC commands for the remainder of the session
with that host.  (When the host closes the connection after the user
logs out, the TAC port is set back to normal.)

The situation is further complicated in that neither the MODEM nor
TMODEM program{ have compilation conditionals to allow for this third
case where the monitor does the IAC doubling, but does not provide for
a monitor call.  The solution in those cases is to send this message
to your system wizard and have them contact me to work out a fix.

--Frank
26-Sep-86 09:59:10-MDT,3087;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 26 Sep 86 09:58:35-MDT
Received: from ll.arpa by AMSAA.ARPA id a012173; 26 Sep 86 10:39 EDT
Date: Fri 26 Sep 1986 10:15:18 EDT
From: [e-mail]
MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
Subject: Automatic Disk Logging
To: [e-mail]
Message-ID: <[e-mail]>

I have not really thought through the question of how one would make
the disk operating system (DOS) perform automatic disk logging, but I do
not think that it is sufficient or necessary to simply check for which
disks are set to read-only status.  First of all, the user may have set
a disk to R/O status (using STAT or another utility), and that diskette
may not have been changed.  In fact, relogging that diskette would
defeat the purpose behind the user's setting it to R/O status, i.e., to
prevent any writing to that diskette.  Secondly, after a diskette is
swapped without resetting with a control-c, the diskette is not yet
marked as read-only.

I think that what has to be done is the following.  Whenever DOS is
asked to write to a disk, it must check the allocation table implied by
the directory on the diskette with the allocation table stored in the
BIOS.  If the diskette has not been swapped, the two tables will agree;
if they have been swapped chances are very high that they will not
agree.  The standard Digital Research BDOS does this, and if it finds
that the tables do not agree, it then sets the disk status to read-only,
which precipitates the "BDOS ERROR: DISK R/O" error message.  If you
want the DOS to log in the swapped disk, you must take a more complex
action at this point.

I am sure that the required actions to handle this situation are
more complex than meets the eye.  If you want to try hacking, have fun!
I would start by adding code to log in the new disk in such a way that
the write operation can then proceed.  Good luck.  If you simply want
this very nice capability in your system, I strongly recommend that you
look into purchasing ZRDOS from Echelon, Inc. (415-948-3820).  Although
ZRDOS is the DOS used with the Echelon Z operating system, ZRDOS can be
used as the DOS in a standard CP/M2.2 system as well (it does require a
Z80 or compatible microprocessor).  ZRDOS offers quite a few nice
features in addition to automatic disk logging, and I am sure that
Echelon will be happy to send you more detailed information.  As good as
ZRDOS is, by the way, it still cannot handle all disk-swap situations.
I believe that it has trouble, at least on some systems that support
automatic recognition of multiple disk formats, when the swapped
diskette has a different format, such as when you remove a Kaypro SSDD
diskette and put in an Ampro DSDD diskette.  I say all this as an
indication that automatic disk logging is not as easy as one might think
at first.  ZRDOS has gone through a lot of development to get to the
point it is at now.

                                      Jay Sage


26-Sep-86 17:59:43-MDT,997;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 26 Sep 86 17:59:31-MDT
Received: from nadc.arpa by AMSAA.ARPA id a020044; 26 Sep 86 15:10 EDT
Date: 26 Sep 1986 15:07:03-EDT
From: [e-mail]
To: [e-mail]
Subject: re: automatic disk logging

CP/M 3.0 (A.K.A. CP/M-Plus) does automatic disk logging as a matter of course.
It does this two ways - first by comparing the allocation tables of the disk
and BIOS, as suggested by Mr. Sage, and secondly, if operating with a drive
that can detect disk removal/insertion (by interruptions of the write-lock
photocell), by using that information.  And as Mr. Sage suggests, there are
some problems when swapping formats (this, on a C-128/1571 CP/M system), but
it largely works just fine.  C-128 CP/M 3.0 supports a virtual drive (E:), and
as expected, disk swaps to honor requests for the virtual drive do not trigger
the automatic logging.
Frank Prindle
[e-mail]
26-Sep-86 18:35:40-MDT,2830;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 26 Sep 86 18:35:22-MDT
Received: from rand-unix.arpa by AMSAA.ARPA id a000366; 26 Sep 86 19:49 EDT
Received: by rand-unix.ARPA; Fri, 26 Sep 86 15:12:22 pdt
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Automatic Disk Logging
Date: Fri, 26 Sep 86 15:12:12 PDT
From: [e-mail]

A slight correction to the discussion: the Digital Research CP/M 2.2
BDOS computes a checksum of each directory sector when it logs in a
new disk (unless cks=0 in the disk parameter block).  When a disk
directory sector is read, it is these stored checksums, not the
bitmap of allocated disk groups, that are compared with the values
computed from the (possibly changed) disk.

Writing to a file causes the allocation map (in memory) and the
user-supplied file control block to be updated, and causes the data
to be written to the disk sectors (when the bios flushes the host
buffer); it does not alter the disk directory.  The directory
information -- which groups are allocated to which files -- is only
updated on the disk when a file (or one extent of a file) is closed.

Auto-logging DOS's usually can't totally prevent trashing a disk.
Suppose that a program creates a file and writes to it, leaving it
open, and the user then swaps in a different disk.  The dos won't
detect the change until the program causes a directory access.  So,
if the program continues to write to the file, the data will go onto
the new disk, overwriting whatever is in those groups; the R/O error
will occur at the close (or other directory operation).

Perhaps the original question -- "auto-logging of disks" -- was
really a query about a BIOS operation (as Jay has suggested).  A
well-designed bios will do a media-determination check whenever
SELDSK is called with bit 0 of register E RESET (e.g. E = 0 or 2) and
will set the dph and associated dpb accordingly for
sides/density/format ...  CP/M 2.2 calls SELDSK with E bit 0 reset
after a ^C and when next selecting a disk that has been logged off.

Of course, only some of the 100+ 5 1/4" formats can be distinguished
by their format pattern.  Bioses that support "foreign" formats may
do so automatically (within the supported subset); others may simply
provide a different logical drive and require the user to install the
dpb/dph information before using it.  For example, it is possible to
set the Advent/Plu*Perfect Systems Turborom on a Kaypro so that the
bios automatically distinguishes Kaypro DSDD 512 format from Ampro
DSDD 512.

*BIOS-level* auto-disk format determination should be compatible with
any cp/m 2.2-type dos, requiring only ^C, reset, or logoff/logon at
the dos level.

--bridger mitchell


27-Sep-86 16:10:12-MDT,1551;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 27 Sep 86 16:10:05-MDT
Received: from brl-smoke.arpa by AMSAA.ARPA id a002553; 27 Sep 86 17:33 EDT
Received: from USENET by SMOKE.BRL.ARPA id a005612; 27 Sep 86 17:31 EDT
From: Victor O'Rear <[e-mail]>
Newsgroups: net.micro.cpm
Subject: Re: Disk conversion for Apple format
Message-ID: <[e-mail]>
Date: 26 Sep 86 07:08:07 GMT
Keywords: Softsectored Format Problems
To:       [e-mail]

In article <[e-mail]> [e-mail] writes:
>Hi!
>
>Does anyone know if a disk conversion program exists between
>Apple format and any MS-DOS format?
>

I have it on good authority that none exists.  Apple used such a hardware
dependent system that the best way to read an Apple disk, is to use an Apple
Z80 system and pip it over.

What appled did was put the alignment marks on the disk as written bytes,
and so the controller has to track those codes to read the disk.
I suppose it could be done, but I been told it's VERY hard.



--
Victor O'Rear {ihnp4, akgua, sdcsvax, cbosgd, sdamos, bang}!crash!victoro
ARPA: crash!victoro@[ucsd,nosc]
BIX:  victoro
Proline: ...!{pro-sol,pro-mercury}!victoro
People-Net: ....!crash!Pnet#01!victoro
Fandom: S.T.A.R. - San Diego
Location: 32 47N / 116 56W

[A Feasablity study is now being done on a new discalmer]
[Old Disclaimer]:
"Our forefathers told us never to drank anything that would make us week
or silly."
28-Sep-86 19:07:54-MDT,1178;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 28 Sep 86 19:07:46-MDT
Received: from wiscvm.arpa by AMSAA.ARPA id a005765; 28 Sep 86 20:32 EDT
Received: from (MAILER)OREGON1.BITNET by WISCVM.WISC.EDU on 09/28/86 at
  19:34:56 CDT
Received: by OREGON1 (Mailer X1.23b) id 2506; Sun, 28 Sep 86 17:27:08
  PST
Date:         Sun, 28 Sep 86 17:19:08 PST
From:           Eric Swanson <[e-mail]>
Subject:      Re: Disk conversion for Apple format
To:  [e-mail]
MMDF-Warning:  Parse error in preceding line at AMSAA.ARPA
In-Reply-To:  Your message of 26 Sep 86 07:08:07 GMT

I know there is someone making an expansion card for the IBMPC that
allows it to read Apple formats.  I don't remember the name of the
company, but it's one of the "regular" IBM expansion card makers.
Since neither the PC nor the Apple are up my alley, I probably wouldn't
normally remember this, but there's a business here in town that does
a brisk trade in translating disks via one of these cards.

Eric Swanson, aka Cygnus.

             [e-mail]
or c/o       andrewjp%uo-vax1%uoregon.csnet
28-Sep-86 20:58:37-MDT,860;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 28 Sep 86 20:58:31-MDT
Received: from nosc.arpa by AMSAA.ARPA id a006004; 28 Sep 86 22:25 EDT
Received: by bass.ARPA (5.31/4.7)
    id AA09692; Sun, 28 Sep 86 19:28:02 PDT
Message-Id: <[e-mail]>
Date: Sun, 28 Sep 86 18:43:43 PDT
From: Matt Smiley <crash!pnet01![e-mail]>
To: [e-mail]
Subject: MEX overlays

I would like some information on customizing MEX 114 to work better on my
Kaypro 1 and Hayes Compat. modem. I used the 'mixed' overlay that came with
the library, but now hear that one can use separate modem and machine
overlays. What overlays do I need and how might I get them out of SIMTEL20?

Matt Smiley
ucbvax!sdcsvax!crash!pnet01
noscvax!crash!pnet01!msmiley

(Sorry, no message editor here!)
30-Sep-86 16:41:18-MDT,725;000000000000
Return-Path: <[e-mail]>
Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 30 Sep 86 16:40:38-MDT
Received: from nosc.arpa by AMSAA.ARPA id a016183; 30 Sep 86 17:52 EDT
Received: by bass.ARPA (5.31/4.7)
    id AA24549; Tue, 30 Sep 86 14:54:57 PDT
Message-Id: <[e-mail]>
Date: Tue, 30 Sep 86 13:46:20 PDT
From: Marc Wilson <crash!pnet01![e-mail]>
To: [e-mail]
Subject: Modem overlays for Avatex modem

     Not too long ago, someone posted to Info-CPM some modifications to several
different overlays. I would appreciate it if whoever did it could re-post it,
or send it to me direct. I just bought one of the little beasties... and it
works just great!