1-Sep-86 13:09:55-MDT,2017;000000000000 Return-Path: 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 cc: info-cpm@AMSAA.ARPA cc: young@uci-icsc.ARPA Subject: Re: kaypro 10 schematics In-reply-to: Your message of 29 Aug 86 20:49:58 GMT. <268@killer.UUCP> Date: Mon, 01 Sep 86 11:42:45 -0800 From: Michal Young 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: (503) 382-5060 (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 young@ics.uci.edu 1-Sep-86 14:37:20-MDT,46496;000000000000 Return-Path: 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: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA 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.CRCLST on SIMTEL20 (the file listing all the filenames, sizes and CRCs of the PD: 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 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 '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: 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: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA, Info-Micro@BRL-VGR.ARPA 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 , who added them into the posting by Glenn Tenney. Filename Type Bytes CRC Directory PD: PRIVCY2.BILL.1 ASCII 75835 4E46H For those who can handle binary FTP transfers and unsqueeze: Directory PD: 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: W8SDZ@SIMTEL20.ARPA 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: 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: INFO-CPM@AMSAA.ARPA From: UZ32112%SG2.BITNET@wiscvm.ARPA Subject: NOTE from UZ32112 Date: 2 September 1986, 13:57:59 ULG From: Andre PIRARD +32 (41) 520180(449) UZ32112 at BLIULG12 SEGI - Universite de Liege 15, av. des Tilleuls B4000 LIEGE (Belgique) UZ32112%BLIULG12.BITNET@WISCVM.WISC.EDU 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: 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: mek%UMass.BITNET@wiscvm.ARPA Subject: BYE510/C128/1670? To: info-cpm@AMSAA.ARPA 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, mek%UMass.BITNET@wiscvm.ARPA 2-Sep-86 13:06:42-MDT,602;000000000000 Return-Path: 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: <8609021817.AA08308@bass.ARPA> Date: Tue, 2 Sep 86 11:00:28 PDT From: Marc Wilson To: info-cpm@AMSAA.ARPA 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: 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: SINGPANG%HLERUL5.BITNET@wiscvm.ARPA MMDF-Warning: Parse error in preceding line at AMSAA.ARPA Subject: BITNET mail follows To: info-cpm@AMSAA.ARPA X-Original-To: info-cpm@amsaa.arpa, 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: SINGPANG%HLERUL5.BITNET@WISCVM.ARPA 3-Sep-86 05:25:17-MDT,1442;000000000000 Return-Path: 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 " Newsgroups: net.micro.cpm Subject: Date: Message-ID: <3506@brl-smoke.ARPA> Date: 3 Sep 86 10:48:33 GMT To: info-cpm@AMSAA.ARPA From: SINGPANG%HLERUL5.BITNET@wiscvm.ARPA MMDF-Warning: Parse error in preceding line at AMSAA.ARPA Subject: BITNET mail follows To: info-cpm@AMSAA.ARPA X-Original-To: info-cpm@amsaa.arpa, 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: SINGPANG%HLERUL5.BITNET@WISCVM.ARPA 3-Sep-86 06:29:30-MDT,1041;000000000000 Return-Path: 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 Subject: Bondwell machine To: Info-CPM@AMSAA.ARPA Message-ID: <12235962180.13.CENT.MBECK@OZ.AI.MIT.EDU> 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: 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: prindle@nadc.ARPA To: info-cpm@AMSAA.ARPA Subject: C128 info Cc: singpang@hlerul5.bitnet, wiscvm@nadc.ARPA 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 microcomputer.cbm@rutgers.arpa. 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 Prindle@NADC.arpa 3-Sep-86 21:45:09-MDT,767;000000000000 Return-Path: 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: mek%UMass.BITNET@wiscvm.ARPA Subject: Mailing list for C128 To: info-cpm@AMSAA.ARPA Yes, there is a general Commodore mailing list on the network. Its address is: CBMList%UMass.BITNET@wiscvm.ARPA All requests to be added to or deleted from the mailing list should be sent to: MKimmel%UMass.BITNET@wiscvm.ARPA -Matt Kimmel, CBMList coordinator. mek%UMass.BITNET@wiscvm.ARPA 4-Sep-86 04:33:02-MDT,3189;000000000000 Return-Path: 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 Newsgroups: net.micro.cpm Subject: Re: Bondwell machine Message-ID: <119@triada.UUCP> Date: 4 Sep 86 00:55:37 GMT To: info-cpm@AMSAA.ARPA In article <3508@brl-smoke.ARPA>, Cent.Mbeck%OZ.AI.MIT.EDU@mit-xx.ARPA (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: (408) 734-9720 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: 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: <8609041019.AA27292@bass.ARPA> Date: Thu, 4 Sep 86 02:53:54 PDT From: Matt Smiley To: info-cpm@AMSAA.ARPA 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: 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: SEA%UNBMVS1.BITNET@wiscvm.ARPA MMDF-Warning: Parse error in preceding line at AMSAA.ARPA To: INFO-CPM@AMSAA.ARPA Message-ID: Date/Time: 86/09/04 10:45 AST From: Steve Allain, University of New Brunswick, Canada SEA@UNBMVS1.BITNET 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: 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" Subject: New Service Available! To: INFO-CPM@AMSAA.ARPA Message-ID: <12236258673.9.WANCHO@SIMTEL20.ARPA> 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: being considered the best and most recent, the MSDOS archives are also in the process of being similarly organized in PD:, 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:. Now those generic subdirectories in PD:, PD:, and PD: 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: ARCHIVE-REQUEST@SIMTEL20.ARPA, 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:file.type.generation "device:" is usually PD:, and the combination of PD: 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: 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: SAGE@LL.ARPA MMDF-Warning: Parse error in preceding line at AMSAA.ARPA Subject: Peter Kendell's Address To: INFO-CPM@AMSAA.ARPA Cc: sage@ll.ARPA Message-ID: 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: 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 Newsgroups: net.micro.apple,net.micro.cpm Subject: Re: Home Accounting? Message-ID: <171@lpi.UUCP> Date: 3 Sep 86 18:49:03 GMT To: info-cpm@AMSAA.ARPA In article <2fcfc504.46@apollo.uucp>, nazgul@apollo.uucp (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: 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 Newsgroups: net.lang.f77,net.micro.pc,net.micro.cpm Subject: Fortran compiler quality query Message-ID: <107@atelabs.UUCP> Date: 2 Sep 86 20:36:47 GMT To: info-cpm@AMSAA.ARPA 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 (503) 690-2000 5-Sep-86 06:47:18-MDT,1276;000000000000 Return-Path: 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: Received: from localhost by ernie.mitre.org (2.2/SMI-2.2) id AA13566; Fri, 5 Sep 86 08:19:43 edt Message-Id: <8609051219.AA13566@ernie.mitre.org> To: jdc%lpi.uucp@BRL.ARPA Cc: info-cpm@AMSAA.ARPA Subject: Re: Home Accounting? In-Reply-To: Your message of 3 Sep 86 18:49:03 GMT. <171@lpi.UUCP> Date: Fri, 05 Sep 86 08:19:21 -0500 From: edelheit@MITRE.ARPA 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 (edelheit@mitre.arpa) The MITRE Corporation, 1820 Dolley Madison Blvd. McLean, VA 22102 (703) 883-7586 5-Sep-86 09:21:21-MDT,1331;000000000000 Return-Path: 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: FISHER%RPICICGE.BITNET@wiscvm.ARPA To: INFO-CPM@AMSAA.ARPA 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 " 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 FISHER@RPICICGE.BITNET 5-Sep-86 19:48:11-MDT,830;000000000000 Return-Path: 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: Larry_Shilkoff.ElSegundo@xerox.ARPA Date: 5 Sep 86 13:02:13 PDT (Friday) Subject: Re: C128 info From: Larry_Shilkoff.ElSegundo@xerox.ARPA To: prindle@NADC.ARPA cc: Larry_Shilkoff.ElSegundo@xerox.ARPA, info-cpm@AMSAA.ARPA, singpang%hlerul5.BITNET@wiscvm.ARPA, wiscvm@NADC.ARPA 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: 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: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: Assembling SYSLIB with ZAS and Z80ASM (SLR) Reply-To: SAGE@LL.ARPA 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: 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 Subject: Some data on ZCPR 3.3 To: info-cpm@AMSAA.ARPA cc: sage@LL.ARPA Message-ID: <12236834507.7.RCONN@SIMTEL20.ARPA> 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: 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 Subject: Response to Sage's comments To: info-cpm@AMSAA.ARPA cc: sage@LL.ARPA Message-ID: <12236834351.7.RCONN@SIMTEL20.ARPA> 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: 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 Subject: New files in ZSYS To: info-Cpm@AMSAA.ARPA Message-ID: <12236839562.7.RCONN@SIMTEL20.ARPA> Thanks to Keith for uploading most of them. PD: Bytes(SZ) AUTOZINS.CCP.1 1420(7) -- also in PD: DU312.LBR.1 64896(8) -- also in PD: PPAL.DOC.1 11755(7) -- also in PD: VF41.IQF.1 11008(8) -- also in PD: VF41H.LBR.1 27776(8) -- also in PD: ZAS-SLR.DOC.1 7613(7) -- also in PD: ZAS-STD.DOC.1 5564(7) -- also in PD: ZHELPR16.RQS.1 2688(8) -- also in PD: ZSTD.DOC.1 7484(7) -- also in PD: 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: 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 Subject: New file in ZSYS To: info-cpm@AMSAA.ARPA Message-ID: <12236845735.7.RCONN@SIMTEL20.ARPA> Sorry if this is a repeat ... PD: Bytes(SZ) AUTOZINS.CCP.1 1420(7) -- also in PD: DU312.LBR.1 64896(8) -- also in PD: PPAL.DOC.1 11755(7) -- also in PD: VF41.IQF.1 11008(8) -- also in PD: VF41H.LBR.1 27776(8) -- also in PD: ZAS-SLR.DOC.1 7613(7) -- also in PD: ZAS-STD.DOC.1 5564(7) -- also in PD: ZHELPR16.RQS.1 2688(8) -- also in PD: ZSTD.DOC.1 7484(7) -- also in PD: 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: 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 Subject: Some info on PPAL To: info-cpm@AMSAA.ARPA cc: sage@LL.ARPA Message-ID: <12236834960.7.RCONN@SIMTEL20.ARPA> 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: 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 Newsgroups: net.micro.cpm Subject: New shareware compiler Message-ID: <266@myrias.UUCP> Date: 4 Sep 86 19:08:44 GMT Posted: Thu Sep 4 15:08:44 1986 To: info-cpm@AMSAA.ARPA 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: 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 Subject: Z-NEWS.509 Available To: info-cpm@AMSAA.ARPA Message-ID: <12237050513.12.RCONN@SIMTEL20.ARPA> In PD: are Z-NEWS.509 and 5Q9. In PD: is Z-NEWS.5Q9. Thanks to Keith for the upload. Rick ------- 7-Sep-86 12:24:40-MDT,1273;000000000000 Return-Path: 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: prindle@nadc.ARPA To: info-cpm@AMSAA.ARPA Subject: c128 cp/m disk formats Cc: microcomputer.cbm@rutgers.ARPA 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 Prindle@NADC.arpa 7-Sep-86 16:39:55-MDT,950;000000000000 Return-Path: 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) To: Rick Conn cc: info-cpm@AMSAA.ARPA, sage@LL.ARPA 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: 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: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: New CP/M files on SIMTEL20 31-July to 7-September The following is a list of new files added to SIMTEL20's directories between 31-Jul-86 and 7-Sept-86. For a complete list of all files, get PD:CPM.CRCLST. Filename Type Bytes CRC PD: 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: 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: MBPRE-12.LBR.1 BINARY 17536 907BH <--MBASIC pre-processor [ Note: non-CP/M lists have been moved to PD: ] PD: 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: BDOSFUNC.DQC.1 BINARY 4608 EAB0H <--explains BDOS calls PD: 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: 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: CCP104P.LBR.1 BINARY 84608 B7EAH <--CP/M-Plus ZCPR-like CCP CPMMAKE.ARC.1 BINARY 46443 E455H <--Unix-like MAKE util. PD: COM.68K.1 BINARY 23808 A4F5H <--CP/M-80 emulator COM.LBR.1 BINARY 50560 6A51H <--sources for above PD: 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: CHEFREC.5Q.1 BINARY 25856 531EH <--more recipies for CHEF db PD: SEARCH.LBR.1 BINARY 36352 BFA0H <--search for key strings PD: 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:> SAP49.WRN.1 ASCII 1192 71F7H <--warning on bad program SAP50.LBR.1 BINARY 40704 2C6AH <--update, good version PD: BWFMT.LBR.1 BINARY 5376 C98EH <--format pgms for Bondwell PD: MDLPLNE2.LBR.1 BINARY 35456 2C05H <--model plane design PD: SEPBEST2.LQT.1 BINARY 29440 C50BH <--best of CP/M pd programs PD: GOVTPUBS.TQT.1 BINARY 14720 67E9H <--gov't publications list PD: 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: UUDECODE.HEX.1 ASCII 25555 50F5H <--uudecode for CP/M UUENCODE.HEX.1 ASCII 24939 4228H <--uuencode for CP/M PD: 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: 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: PMASTER.LBR.1 BINARY 116736 5DFAH <--dot matrix printer util. PD: 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: ROYALOAK.ARC.1 BINARY 65293 6B5BH <--RCP/M Royal Oak directory PD: PC-PSUIT.LBR.1 BINARY 15872 3741H <--PC Pursuit info PD:> FAST.TQT.1 BINARY 11648 B7FDH <--FAST protocol proposal WXMODEM.DQC.1 BINARY 32256 4C78H <--windowed XMODEM " PD:> M7H8-2-1.AQM.1 BINARY 8320 01DCH <--Heath H89 overlay PD: 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:> 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: (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: AVATEXSM.TQT.1 BINARY 2816 5111H <--using Avatex modem MB-KMD11.LBR.1 BINARY 139776 D5F2H <--MBYE KMD or stand-alone PD: NEW-SYS.OPS.2 ASCII 5875 9637H <--registering your RCP/M PD: PRIVCY2.BQL.1 BINARY 45056 D16DH <--updated Privacy Bill PD: CRUNCH20.LBR.1 BINARY 50304 75F5H <--file cruncher, Z80 only USQFST20.LBR.1 BINARY 27520 E993H <--fast unsqueezer PD: 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: COMDEMO.ARC.1 BINARY 18179 7E70H <--communications demo UUECPM.ARC.1 BINARY 48862 3700H <--uuencode/uudecode PD: FOGINDEX.LBR.1 BINARY 12288 BD13H <--grade level of text files REPLACE.LBR.1 BINARY 23040 A9E0H <--find and replace util. PD: VMSSWEEP.FOR.3 ASCII 50461 92E5H <--LBR/SQ/USQ/CRUNCH/UNCRUNCH PD: 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: WSPATCH.TQL.1 BINARY 14208 52BBH <--WordStar patch table XEROX-WS.LBR.1 BINARY 4480 DD6CH <--Xerox computer WS enhance PD: (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: 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 Subject: New PPAL.DOC To: info-cpm@AMSAA.ARPA Message-ID: <12237140765.22.RCONN@SIMTEL20.ARPA> In PD: and PD: 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: 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: Maron@LLL-MFE.ARPA Subject: Remove me. To: info-cpm@BRL.ARPA Message-ID: <8609071940.aa03480@VGR.BRL.ARPA> 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: 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 Subject: Re: Response to Sage's comments To: towson@AMSAA.ARPA cc: info-cpm@AMSAA.ARPA, sage@LL.ARPA In-Reply-To: Message from "David Towson (SECAD) " of Sun 7 Sep 86 16:08:28-MDT Message-ID: <12237142396.22.RCONN@SIMTEL20.ARPA> The original ZCPR 3.0 SYSLIB is in PD:. It is also in PD: in the proper volume (as referenced by the article). The new libraries will be released when ZCPR 3.3 is released. In PD: 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: 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 Subject: ZSYS Snapshot To: info-cpm@AMSAA.ARPA cc: sage@LL.ARPA Message-ID: <12237143400.22.RCONN@SIMTEL20.ARPA> 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: 0 | 217676 PD: 547920 | 166166 PD: 93213 | 47632 PD: 653184 | 41655 PD: 27733 | 20408 PD: 0 | 540916 PD: 229015 | 24171 PD: 1502072 | 351300 PD: 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: 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: OP4%psuvma.bitnet@BRL.ARPA 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: info-cpm@AMSAA.ARPA 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 OP4@PSUVMA.BITNET 8-Sep-86 04:01:48-MDT,2148;000000000000 Return-Path: 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 Newsgroups: net.micro.cpm Subject: CP/M system info wanted Message-ID: <1066@spice.cs.cmu.edu> Date: 6 Sep 86 17:52:19 GMT Posted: Sat Sep 6 13:52:19 1986 Keywords: To: info-cpm@AMSAA.ARPA 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: mjp@spice.cs.cmu.edu (preferred), mp1u@td.cc.cmu.edu | | 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: 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: prindle@nadc.ARPA To: info-cpm@AMSAA.ARPA, op4@psuvma.bitnet, brl@nadc.ARPA 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 Prindle@NADC.arpa 8-Sep-86 10:21:33-MDT,399;000000000000 Return-Path: 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) To: Rick Conn cc: info-cpm@AMSAA.ARPA, sage@LL.ARPA 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: 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: Sender: mek%UMass.BITNET@wiscvm.ARPA From: mek%UMass.BITNET@wiscvm.ARPA To: w8sdz@SIMTEL20.ARPA Subject: Commodore C128 printer program update ReSent-From: KPETERSEN@SIMTEL20.ARPA ReSent-To: Info-Cpm@AMSAA.ARPA 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: 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: MKimmel%UMass.BITNET@wiscvm.ARPA and on BITNet as: MKimmel@UMass.BITNET 9-Sep-86 01:25:22-MDT,605;000000000000 Return-Path: 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 To: info-cpm@AMSAA.ARPA cc: BUDDENBERGRA@usc-isi.ARPA 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: 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 Newsgroups: net.micro.pc,net.micro.cpm,net.wanted.sources Subject: need z80 cross assembler and disassembler Message-ID: <116@atelabs.UUCP> Date: 5 Sep 86 16:20:15 GMT To: info-cpm@AMSAA.ARPA 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 (503) 690-2000 9-Sep-86 06:58:42-MDT,1474;000000000000 Return-Path: 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: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA 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: 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: FISHER%RPICICGE.BITNET@wiscvm.ARPA To: INFO-CPM@AMSAA.ARPA 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 FISHER@RPICICGE.BITNET 9-Sep-86 09:18:48-MDT,828;000000000000 Return-Path: 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 Subject: Re: Kermit <--> TAC problems In-Reply-To: Your message of 8 Sep 1986 22:08:10 EDT To: Rex Buddenberg Cc: info-cpm@AMSAA.ARPA, jshaver@APG-3.ARPA 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: 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 To: info-cpm@BRL.ARPA cc: IAIPS-DCAS@usc-isif.ARPA Message-ID: <8609091222.aa15776@VGR.BRL.ARPA> 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: 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 Message-Id: <8609092022.AA17767@clover.ucdavis.edu> To: ucdavis!info-cpm@AMSAA.ARPA 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: hildum%clover%ucdavis.uucp@ucbvax.arpa hildum%clover%ucdavis.uucp@ucbvax.berkeley.edu ucdavis!clover!hildum@ucbvax.arpa ucdavis!clover!hildum@ucbvax.berkeley.edu Otherwise: hildum@ucd.csnet hildum%ucd@csnet-relay.arpa hildum%ucd@relay.cs.net 9-Sep-86 18:47:45-MDT,671;000000000000 Return-Path: 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 Subject: SLR To: info-cpm@AMSAA.ARPA Message-ID: <12237666838.18.RCONN@SIMTEL20.ARPA> 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: 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: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: FISHER%RPICICGE.BITNET@wiscvm.ARPA Cc: Info-Cpm@AMSAA.ARPA 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:COMPRESS.TXT <--explains compressed files PD:LU300.DQC <--explains CP/M "LU" program PD:LU310.COM <--the LU program itself PD:LU310.HLP <--and a help file for it PD:SQ111.COM <--CP/M-80 file squeezer PD:SQUEEZE.TXT <--explains squeezed files PD:UNARC.COM-Z80 <--extracts files from ARCs (Z80 only) PD:UNARCA.COM-8080 <--ditto, for 8080 PD:USQ120.COM <--CP/M-80 file unsqueezer PD:USQ120.DOC <--how to use it PD:UUDECODE.COM <--uudecode for CP/M-80 PD:UUENCODE.COM <--uuencode for CP/M-80 MS/PCDOS files: PD:ARC51.COM <--when run makes ARC512.EXE and DOC PD:ARCE120.COM <--fast ARC file extractor PD:ARCE120.DOC <--how it works PD:ARCV106.COM <--ARC directory lister PD:ARCV106.MSG <--how it works PD:LUE220.COM <--extracts files from LBR's PD:LUE220.DOC <--how it works PD:LUU208.LBR <--adds files to LBR's PD:NUSQ110.COM <--file UnSQueezer PD:NUSQ110.DOC <--how it works PD:SQDATE.DOC <--how dates are put into squeezed files PD:SQPC129.DOC <--how SQPC12A works PD:SQPC12A.COM <--file SQueezer PD:UUDECODE.BAS <--decodes uuencoded files (BASIC) (slow) PD:UUDECODE.EXE <--decodes uuencoded files PD:UUDECODE.PAS <--decodes uuencoded files (Turbo Pascal) PD:UUENCDEC.DOC <--notes on uuencode/uudecode EXE for MSDOS PD:UUENCODE.EXE <--makes uuencoded files, see DOC file note PD:UUENCODE.PAS <--makes uuencoded files (Turbo Pascal) 9-Sep-86 21:02:02-MDT,794;000000000000 Return-Path: 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: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Eric Hildum Cc: Info-Cpm@AMSAA.ARPA Subject: MAC compatible assembler In-reply-to: Msg of 9 Sep 1986 14:22-MDT from Eric Hildum 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: Z80MR.LBR.1 BINARY 41344 B0D0H --Keith 9-Sep-86 23:18:05-MDT,1366;000000000000 Return-Path: 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: CSNET%UKANVAX.BITNET@wiscvm.ARPA MMDF-Warning: Parse error in preceding line at AMSAA.ARPA Subject: archive-request Catch-22 To: INFO-CPM@AMSAA.ARPA X-Original-To: INFO-CPM@AMSAA.ARPA, 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 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: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: CSNET@UKANVAX.BITNET CSNET: long@csvax.ukans.edu 9-Sep-86 23:20:04-MDT,4037;000000000000 Return-Path: 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: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-XMODEM@SIMTEL20.ARPA Cc: Info-Cpm@AMSAA.ARPA, Info-Micro@BRL.ARPA, Telecom@mit-xx.ARPA 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 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 (813) 791-1454 modem 300/1200/2400 {eof} 10-Sep-86 02:53:24-MDT,1054;000000000000 Return-Path: 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: From: WANCHO@SIMTEL20.ARPA To: CSNET%UKANVAX.BITNET@wiscvm.ARPA Cc: WANCHO@SIMTEL20.ARPA, INFO-CPM@AMSAA.ARPA 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: 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: 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: info-cpm@AMSAA.ARPA From: IFF095%DJUKFA11.BITNET@wiscvm.ARPA Subject: NOTE from IFF095 Date: 10 September 1986, 10:24:32 MEZ From: Joachim K. Anlauf (02461) 614519 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: 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: info-cpm@AMSAA.ARPA From: IFF095%DJUKFA11.BITNET@wiscvm.ARPA Subject: NOTE from IFF095 Date: 10 September 1986, 11:31:20 MEZ From: Joachim K. Anlauf (02461) 614519 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: 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: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA 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: 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: W8SDZ@SIMTEL20.ARPA 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: 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: Received: from unido.UUCP by seismo.CSS.GOV with UUCP; Thu, 11 Sep 86 05:00:04 EDT From: Nixdorf UUCP Message-Id: <8609110930.AA00745@unido.uucp> 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: info-cpm@AMSAA.ARPA 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: 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 Newsgroups: net.micro.cpm Subject: Re: Re: C128 info Message-ID: <712@cbmvax.cbmvax.cbm.UUCP> Date: 9 Sep 86 19:55:14 GMT To: info-cpm@AMSAA.ARPA > > 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: 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 Newsgroups: net.micro.cbm,net.micro.cpm Subject: Re: Z80 Cartridge for C64... HELP!!! Message-ID: <713@cbmvax.cbmvax.cbm.UUCP> Date: 9 Sep 86 19:58:31 GMT To: info-cpm@AMSAA.ARPA > 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 > OP4@PSUVMA.BITNET > 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: 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: grayson@uiucuxc.ARPA 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: info-cpm@AMSAA.ARPA 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: grayson@uiucuxc.UUCP old uucp: {ihnp4,pur-ee}!uiucdcs!uiucuxc!grayson internet: grayson@uiucuxc.cso.uiuc.edu telex: 5101011969 UI TELCOM URUD --> Dan Grayson, Altgeld Hall. us mail: Dan Grayson, Math Dept, Univ of Ill, Urbana 61801 phone: 217-367-6384 home 217-333-6209 office 11-Sep-86 10:38:05-MDT,795;000000000000 Return-Path: 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: mek%UMass.BITNET@wiscvm.ARPA Subject: ARC format To: info-cpm@AMSAA.ARPA cc: info-ibmpc@USC-ISIB.ARPA 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, mek%UMass.BITNET@wiscvm.ARPA \ 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: 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: SECRIST%OAK.SAINET.MFENET@LLL-MFE.ARPA Subject: Kudos for Frank, Keith, et.al. re Archive-Server To: INFO-CPM@AMSAA.ARPA From: (Richard C. Secrist) Date: Thu, 11-SEP-1986 13:14 EST To: INFO-CPM@AMSAA.ARPA 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) SECRIST%OAK.SAInet.MFEnet@LLL-MFE.Arpa 13-Sep-86 06:17:01-MDT,1085;000000000000 Return-Path: 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 Newsgroups: net.micro.cpm Subject: Cheap S-100 memory? Message-ID: <2275@hammer.UUCP> Date: 11 Sep 86 16:57:12 GMT To: info-cpm@AMSAA.ARPA 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: 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: mek%UMass.BITNET@wiscvm.ARPA Subject: UUENCODING To: info-cpm@AMSAA.ARPA cc: info-unix@BRL.ARPA, unix-sources@BRL.ARPA 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, mek%UMass.BITNET@wiscvm.ARPA Pi is secretly rational! 13-Sep-86 13:54:01-MDT,2115;000000000000 Return-Path: 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: From: WANCHO@SIMTEL20.ARPA To: INFO-CPM@AMSAA.ARPA 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: 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: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: Quick reference list of SIMTEL20 CP/M directories Quick reference list of SIMTEL20's PD: 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: 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: <8609142141.AA12739@bass.ARPA> Date: Sun, 14 Sep 86 14:21:36 PDT From: Marc Wilson To: info-cpm@AMSAA.ARPA 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: 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 To: info-cpm@AMSAA.ARPA Subject: Unsqueezing files Message-ID: 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 MKATZ@UMD2.UMD.EDU or MKATZ@UMD2.BITNET (I am somewhat confused about where this node fits into the scheme of things) or KATZM@UMDD.BITNET 15-Sep-86 14:34:20-MDT,1116;000000000000 Return-Path: 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 To: info-cpm@AMSAA.ARPA 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: 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: Voorheis.es@xerox.ARPA Subject: Re: AMPRO MULTIFMT utility In-reply-to: <8609142141.AA12739@bass.ARPA> To: Marc Wilson cc: info-cpm@AMSAA.ARPA 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: 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: <8609152331.AA01319@bass.ARPA> Date: Mon, 15 Sep 86 15:20:12 PDT From: Marc Wilson To: info-cpm@AMSAA.ARPA 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: 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: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: More on ZAS and SLR assemblers Reply-To: SAGE@LL.ARPA I just received the following file on my RCP/M. --Keith Petersen Arpa: W8SDZ@SIMTEL20.ARPA 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: 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: jay%garfield.uucp@BRL.ARPA Newsgroups: net.micro.cpm Subject: A Z System ?? Message-ID: <2069@garfield.UUCP> Date: 10 Sep 86 13:49:26 GMT Sender: perry%garfield.uucp@BRL.ARPA To: info-cpm@AMSAA.ARPA Pardon me for asking this :::::::: What is a Z system ? :::::::: 16-Sep-86 17:24:58-MDT,744;000000000000 Return-Path: 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 Subject: Re:AMPRO MULTIFMT utility To: info-cpm@AMSAA.ARPA Desires:"gag me with a Valley girl" (ohmigod!) Message-ID: <12239443092.24.MEAD@USC-ECLC.ARPA> 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: 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) To: info-cpm@AMSAA.ARPA 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: 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 Message-Id: <8609170040.AA14896@nprdc.arpa> Date: 16 September 1986 1740-PDT (Tuesday) To: info-cpm-request@AMSAA.ARPA Subject: Re: Let's "mellow out" a bit! Cc: info-cpm@AMSAA.ARPA, melmoy@NPRDC.ARPA 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: 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 Subject: New files in ZSYS To: info-cpm@AMSAA.ARPA Message-ID: <12239537514.28.RCONN@SIMTEL20.ARPA> I've placed Jay Sage's recent diatribe and the responses to it that I received today in PD: and 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: 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 Subject: Re: AMPRO MULTIFMT utility To: crash!pnet01!mwilson@NOSC.ARPA cc: info-cpm@AMSAA.ARPA In-Reply-To: <8609142141.AA12739@bass.ARPA> Phone: (714)961-3393; Mail:Beckman Instruments, Inc. Mail-addr: 2500 Harbor Blvd., X-11, Fullerton CA 92634 Message-ID: <12239723807.18.BEC.SHAPIN@USC-ECL.ARPA> Ampro has their own BBS at (408) 258-8128. Try asking them. ------- 18-Sep-86 12:26:11-MDT,824;000000000000 Return-Path: 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 Newsgroups: net.micro.cpm Subject: MIDI for Otrona Attache Message-ID: <803@aicchi.UUCP> Date: 15 Sep 86 15:28:55 GMT To: info-cpm@AMSAA.ARPA 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: 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" Newsgroups: net.micro.cpm Subject: Re: Kudos for Frank, Keith, et.al. re Archive-Server Message-ID: <15687@ucbvax.BERKELEY.EDU> Date: 16 Sep 86 18:27:18 GMT Sender: usenet@ucb-vax.ARPA To: info-cpm@AMSAA.ARPA In article <3728@brl-smoke.ARPA> SECRIST%OAK.SAINET.MFENET@LLL-MFE.ARPA 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) >SECRIST%OAK.SAInet.MFEnet@LLL-MFE.Arpa 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, samples@kim.berkeley.edu 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: 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 Newsgroups: net.micro.cpm Subject: RE: Kudos for Frank, Keith, etc. Message-ID: <770@oakhill.UUCP> Date: 16 Sep 86 18:15:28 GMT To: info-cpm@AMSAA.ARPA >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) >SECRIST%OAK.SAInet.MFEnet@LLL-MFE.Arpa 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: 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: From: WANCHO@SIMTEL20.ARPA To: INFO-CPM@AMSAA.ARPA 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: 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 Subject: My final reply To: info-cpm@AMSAA.ARPA Message-ID: <12240089626.14.RCONN@SIMTEL20.ARPA> ... to Jay Sage's messages is in PD: and 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: 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: Dusel.Wbst@xerox.ARPA Date: 19 Sep 86 8:24:48 EDT Subject: Re: MIDI for Otrona Attache In-reply-to: mdb%aicchi.uucp@BRL.ARPA's message of 15 Sep 86 15:28:55 GMT, <803@aicchi.UUCP> To: Blackwell cc: info-cpm@AMSAA.ARPA 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: 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: SECRIST%OAK.SAINET.MFENET@LLL-MFE.ARPA Subject: RUNOFF woes To: INFO-CPM@AMSAA.ARPA From: (Richard C. Secrist) Date: Sat, 20-SEP-1986 12:08 EST To: INFO-CPM@AMSAA.ARPA 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: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 SECRIST%OAK.SAInet.MFEnet@LLL-MFE.Arpa 21-Sep-86 11:18:36-MDT,6156;000000000000 Return-Path: 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: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA, Info-Micro@BRL.ARPA 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 (617) 332-3533 23-Sep-86 02:49:20-MDT,863;000000000000 Return-Path: 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: SINGPANG%HLERUL5.BITNET@wiscvm.ARPA MMDF-Warning: Parse error in preceding line at AMSAA.ARPA Subject: CP/M+ USER GUIDE To: info-cpm@AMSAA.ARPA X-Original-To: info-cpm@amsaa.arpa, 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: SINGPANG%HLERUL5.BITNET@WISCVM.ARPA BITNET : SINGPANG@HLERUL5 23-Sep-86 09:02:05-MDT,1566;000000000000 Return-Path: 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 Newsgroups: net.micro.cpm Subject: Re: simtel20 archive access Message-ID: <8144@watrose.UUCP> Date: 17 Sep 86 19:43:18 GMT To: info-cpm@AMSAA.ARPA [munch, munch, mun In article <3820@brl-smoke.ARPA> HAAR%RCSRLH%gmr.com@CSNET-RELAY.ARPA 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: 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: SAGE@LL.ARPA MMDF-Warning: Parse error in preceding line at AMSAA.ARPA Subject: What is a Z System To: INFO-CPM@AMSAA.ARPA Cc: sage@ll.ARPA Message-ID: 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: 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 Newsgroups: net.micro.cpm Subject: Re: A Z System ?? Message-ID: <1468@k.cc.purdue.edu> Date: 18 Sep 86 00:46:11 GMT To: info-cpm@AMSAA.ARPA In article <2069@garfield.UUCP>, jay@garfield.UUCP writes: > Pardon me for asking this > :::::::: > What is a Z system ? > :::::::: Perhaps a Z80 based CP/M system?? Colin (ag0@k.cc.purdue.edu) 23-Sep-86 11:22:03-MDT,714;000000000000 Return-Path: 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" Newsgroups: net.micro.cpm Subject: need kermit for cp/m system Message-ID: <140@cod.UUCP> Date: 19 Sep 86 21:41:26 GMT Keywords: kermit, QT,cp/m To: info-cpm@AMSAA.ARPA 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: 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 Newsgroups: net.micro.cpm Subject: P2DOS again Message-ID: <5428@decwrl.DEC.COM> Date: 18 Sep 86 18:05:06 GMT Sender: daemon@dec.ARPA To: info-cpm@AMSAA.ARPA 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: 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: kenny@uiucdcsb.ARPA 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: info-cpm@AMSAA.ARPA 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: mwilson@NOSC.ARPA 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: kenny@UIUC.CSNET lead trumps." ARPA: kenny@B.CS.UIUC.EDU (kenny@UIUC.ARPA) 23-Sep-86 13:05:48-MDT,1239;000000000000 Return-Path: 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 Newsgroups: net.micro.cpm Subject: Re: simtel20 archive access Message-ID: <1165@epistemi.UUCP> Date: 20 Sep 86 09:51:32 GMT Posted: Sat Sep 20 11:51:32 1986 To: info-cpm@AMSAA.ARPA Like Bob Haar (article <3820@brl-smoke.ARPA>), 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: rda@uk.ac.ed.epistemi 23-Sep-86 21:09:58-MDT,608;000000000000 Return-Path: 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: PFENNIGER%CGEUGE51.BITNET@wiscvm.ARPA To: INFO-CPM@AMSAA.ARPA 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: 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: From: WANCHO@SIMTEL20.ARPA To: INFO-CPM@AMSAA.ARPA 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: 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 Newsgroups: net.micro.cpm Subject: Help Message-ID: <415@infsc1.hatfield.ac.uk> Date: 22 Sep 86 16:38:21 GMT Posted: Mon Sep 22 18:38:21 1986 To: info-cpm@AMSAA.ARPA 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: 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: FISHER%RPICICGE.BITNET@wiscvm.ARPA To: INFO-CPM@AMSAA.ARPA 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 FISHER@RPICICGE.BITNET 24-Sep-86 18:00:38-MDT,860;000000000000 Return-Path: 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 Message-Id: <8609242227.AA02457@polyslo.UUCP> To: csustan!lll-crg!info-cpm@AMSAA.ARPA 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: 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 Newsgroups: net.micro.cbm,net.micro.cpm Subject: MFM on C1571 Message-ID: <775@cbmvax.cbmvax.cbm.UUCP> Date: 24 Sep 86 16:41:10 GMT To: info-cpm@AMSAA.ARPA 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!fred@seismo.CSS.GOV 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: 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: From: LIN@mit-xx.ARPA To: info-cpm@AMSAA.ARPA cc: lin@mit-xx.ARPA Subject: TAC usage In-reply-to: Msg of 31 Aug 1986 13:23-EDT from Keith Petersen 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: 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: <8609252257.AA17574@bass.ARPA> Date: Thu, 25 Sep 86 15:38:01 PDT From: Marc Wilson To: info-cpm@AMSAA.ARPA 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: 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: LIN@mit-xx.ARPA cc: info-cpm@AMSAA.ARPA, mbarker@bbnccv.ARPA Subject: Re: TAC usage In-reply-to: Your message of Thu, 25 Sep 1986 10:03 EDT. Date: 25 Sep 86 18:50:05 EDT (Thu) From: Mike Barker 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: 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: From: WANCHO@SIMTEL20.ARPA To: Mike Barker Cc: LIN@mit-xx.ARPA, INFO-CPM@AMSAA.ARPA Subject: TAC usage In-reply-to: Msg of 25 Sep 1986 16:50-MDT from Mike Barker 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: 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: SAGE@LL.ARPA MMDF-Warning: Parse error in preceding line at AMSAA.ARPA Subject: Automatic Disk Logging To: info-cpm@AMSAA.ARPA Message-ID: 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: 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: prindle@nadc.ARPA To: info-cpm@AMSAA.ARPA 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 Prindle@NADC.arpa 26-Sep-86 18:35:40-MDT,2830;000000000000 Return-Path: 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: <8609262212.AA29224@rand-unix.ARPA> To: info-cpm@AMSAA.ARPA Subject: Automatic Disk Logging Date: Fri, 26 Sep 86 15:12:12 PDT From: bridger@RAND-UNIX.ARPA 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: 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 Newsgroups: net.micro.cpm Subject: Re: Disk conversion for Apple format Message-ID: <296@crash.UUCP> Date: 26 Sep 86 07:08:07 GMT Keywords: Softsectored Format Problems To: info-cpm@AMSAA.ARPA In article <4078@brl-smoke.ARPA> PFENNIGER%CGEUGE51.BITNET@wiscvm.ARPA 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: 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 <212%OREGON1.BITNET@wiscvm.ARPA> Subject: Re: Disk conversion for Apple format To: info-cpm@AMSAA.ARPA 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. 212@OREGON1.BITNET or c/o andrewjp%uo-vax1%uoregon.csnet 28-Sep-86 20:58:37-MDT,860;000000000000 Return-Path: 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: <8609290228.AA09692@bass.ARPA> Date: Sun, 28 Sep 86 18:43:43 PDT From: Matt Smiley To: info-cpm@AMSAA.ARPA 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: 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: <8609302154.AA24549@bass.ARPA> Date: Tue, 30 Sep 86 13:46:20 PDT From: Marc Wilson To: info-cpm@AMSAA.ARPA 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!