17-Dec-84 08:31:44-MST,3638;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 17 Dec 84 08:31:29-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 17 Dec 84 9:54 EST Date: 17 Dec 1984 07:54 MST (Mon) Message-ID: Sender: KPETERSEN@Simtel20.ARPA From: Keith Petersen To: Info-Cpm@Amsaa.ARPA Subject: Forth-83 version 2 for PCDOS/MSDOS available Filename Type Bytes CRC Simtel20 directory MICRO: F83V2-MS.LBR.1 COM 228736 9FFEH is an (untested) version of Forth-83 V2 for PCDOS /MSDOS - see announcement from Ted Shapin : F83V2-MS.LBR contains F83.COM, a public domain implementation of FORTH-83 that is ready to run. It also contains source files in squeezed format. I have squeezed them using the public domain utility NSQ and you can unsqueeze them with the NUSQ utility. Squeezed files have a Q in the file type. The original Laxen-Perry distribution had these files squeezed with a program that took hours (!) to run to unsqueeze. AUSQ will run in minutes and the squeezed files take up less space than the original distribution disk. Make B: (or C:) your default drive. Have plenty of room on your default drive and then type A:AUSQ A:filename.BQK to make filename.BLK on your default drive. CRCK4 or CRCK is a hash checksum program to help you tell if you have good copies of the files. Type CRCK4 *.* (or CRCK *.*) and see if what you have agrees with the values listed below. This should assure you that you have a good copy of the disk. F83.COM is the ready to run FORTH system. The MS-DOS version is set up to use the IBM-PC cursor positioning codes. This won't work on other MS-DOS machines such as the TI Professional. To fix this, start F83, then type EDITOR DUMB and you can use the editor commands as though you have a dumb terminal. The VIEW word expects certain source blocks to be on drive A: and certain source files to be on drive B:. If you have a hard disk system, you can follow the directions in README.PC to recompile your system with all of the source blocks on your hard disk and the VIEW file numbers will be set up correctly. CRCK ver 4.2B (MS DOS VERSION ) Here are the files on the MS-DOS disk: CTL-S pauses, CTL-C aborts --> FILE: F83 .COM CRC = D3 3E FORTH system compiled. --> FILE: README .1ST CRC = This file --> FILE: NUSQ .COM CRC = DD 00 The unsqueeze program --> FILE: NSQ .EXE CRC = 23 CA The squeeze program --> FILE: README .PQ CRC = 2D F6 Original F83 instructions --> FILE: F83-FIXS.TQT CRC = 24 CD Changes from F83 v.1.0 These "blocks" are the F83 sources squeezed --> FILE: KERNEL86.BQK CRC = 2B 60 Kernel source --> FILE: META86 .BQK CRC = 5B BE Metacompiler source --> FILE: CPU8086 .BQK CRC = 4D 6E 8086 dependent code --> FILE: EXTEND86.BQK CRC = F5 C0 Extensions source --> FILE: UTILITY .BQK CRC = ED 3E The UTILITY source These blocks are applications --> FILE: HUFFMAN .BQK CRC = 7C B7 A VERY slow compression program --> FILE: CLOCK .BQK CRC = 47 A2 Source for a calendar example --> FILE: EXPAND86.BQK CRC = 3F F6 Original source to expand .HUF --> FILE: BASIC .BQK CRC = 37 E6 A BASIC compiler in FORTH-83 Ted Shapin. July 31, 1984. 17-Dec-84 08:49:27-MST,3325;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 17 Dec 84 08:49:14-MST Received: From csnet-pdn-gw.ARPA by AMSAA via smtp; 17 Dec 84 10:07 EST Received: from gmr by csnet-relay.csnet id a003264; 17 Dec 84 10:09 EST Date: Mon, 17 Dec 84 09:52 EST From: haar%gmr.csnet@csnet-relay.arpa MMDF-Warning: Parse error in preceding line at CSNET-RELAY.ARPA To: info-cpm@AMSAA.ARPA Subject: ideal CP/M environment There was message on INFO-CPM last week from Chuck (last name?) suggesting and ideal CP/M environment. His selection did not agree with my own preferences so I thought a counter-suggestion might be useful. How about a general discussion of pros & cons of particular choices? 1) I use CP/M Plus in preference over CP/M 2.2 or ZCPR. It is a big improvement in speed over 2.2 in a floppy-only environment and should run like a bandit with a RAM disk. The RSX capability of CP/M Plus provides expansion possibilities that have not been touched yet. The only advantage I see in ZCPR is the named directories. TURBODOS is a good alternative in a multi-processor system. 2) For my money, the MAC/RMAC/LINK/SID(or ZSID) combination is hard to beat for assemby language development. I haven't used the SLR Systems package so I cannot comment about it. Anyone care to enlighten me? 3) PASCAL and Modula 2 - I don't use them so don't have a choice. 4) The BDS C compiler is one of the best around - close to UNIX C as well as being fast and cheap. It doesn't have FLOATs built in but an optional library package does provide this if you want it. 5) I use VEDIT for program editting and like it quite well. I haven't used MINCE but if it is a reasonable subset of EMACS, it should be a good choice also. For word processing editting, I use WORDSTAR. The only improvement I would ask for would be a capability for displaying italics, proportional spacing, etc. (if your display system can handle it) without generating a print version. There were a couple of categories missing in the previous message: 6) a spelling checker - SPELLSTAR is a reasonable one to work with WORDSTAR 7) Database ? anything better than DBASE II ? 8) spreadsheet? CALCSTAR is no great shakes but is adequate. 9) For modem control, terminal emulation, and file transfer, I use MEX. I have used MODEM7, MDMxxx, TERM II, and some others, but MEX is by far the best - very reliable and it has a powerful command language. The new version (MEX 2.0) should be even better. The only other contender might be KERMIT, but I haven't tried it on a micro. 10) MicroShell was a neat product for the CP/M 2.2 environment but its capabilties have been for the most part included in CPM Plus. Is anyone working on a window-based replacement for the CCP ? 11) How about graphics utilities ? any suggestions ? DRI appears to have dropped GSX-80 as a product. One thing to notice in all this is the large amount of good software available in the public domain. This is what makes me think that CP/M is a fantastic environment. Bob Haar G.M. Research Labs [opinions expressed here are not necessarily those of G.M., etc.] 17-Dec-84 15:06:11-MST,976;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 17 Dec 84 15:06:06-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 17 Dec 84 16:31 EST Received: from mit-mc.arpa by BRL-AOS.ARPA id a001058; 17 Dec 84 16:33 EST Received: from a.ARPA by LANL.ARPA (4.12/4.7) id AA16475; Mon, 17 Dec 84 14:16:01 mst Received: by a.ARPA (4.12/4.7) id AA19488; Mon, 17 Dec 84 14:16:15 mst Date: Mon, 17 Dec 84 14:16:15 mst From: Richard Thomsen Message-Id: <8412172116.AA19488@a.ARPA> Subject: Request for MACRO-80 assembler information Newsgroups: ar.info-cpm Distribution: na To: INFO-CPM@mit-mc.ARPA Hi, I got a copy of the Small-C compiler, but it produces assembly language in MACRO-80. Is MACRO-80 in the public domain? If so, does anyone have a copy of the assembler (source, but if it is written in MACRO-80, then the HEX version also)? Thanks in advance. Richard Thomsen 17-Dec-84 18:26:15-MST,2264;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 17 Dec 84 18:25:58-MST Received: From usc-ecl.arpa.ARPA by AMSAA via smtp; 17 Dec 84 19:57 EST Date: Mon 17 Dec 84 14:39:36-PST From: Ted Shapin Subject: Sources for FORTH-83 Public Domain To: info-cpm@AMSAA.ARPA, info-ibmpc@USC-ISIB.ARPA, info-apple@BRL-TGR.ARPA Postal-address: Beckman Instruments, Inc. Postal-address: 2500 Harbor X-11, Fullerton, CA 92634 Phone: (714)961-3393 Version 2 of the public domain implementation of the FORTH-83 standard known as F83 is available on the Arpanet in versions for CP/M-80, CP/M-68K, and MS-DOS. F83 is largely the work of Henry Laxen and Mike Perry with some assistance from many members of the FORTH Interest Group. The system contains many utilities, an editor, an assembler, and a meta-compiler that makes recompilation of the system, or porting to a new system possible. I have uploaded the systems as three large library files. You will need a library utility such as LU or LUPC to extract individual members. The files are on SIMTEL20 in MICRO: and are: F83V2-80.LBR for CP/M 8080 F83V2-68.LBR for CP/M 8086 F83V2-MS.LBR for MS-DOS 8088 For those who are unable to FTP files from the Arpanet, I have submitted the first 2 versions to SIG/M and the MS-DOS version to PC-BLUE. These can be addressed at Box 97, Iselin NJ 08830 and should be available as soon as they can be added to their catalog. No Visible Support Software Box 1344 2000 Center St. Berekeley, CA. 94706. can supply 8080 CP/M on 8" single-sided single density 8086 CP/M on 8" single-sided single density 68000 CP/M on 8" single-sided single density 8088 PC-DOS on 5.25" double-sided double density for $25 each. (These are the versions I squeezed and made into .LBR files). A somewhat similar version known as F83X for the Apple IIE is available from Wil Baden, Orange County FIG, 339 Princeton Circle, Costa Mesa, CA. 92626 for $25 payable to Orange County FIG. This has extensions that are not in the Laxen-Perry model. Ted Shapin. Dec. 17, 1984 ------- 18-Dec-84 08:08:51-MST,630;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 08:08:45-MST Received: From almsa-1.arpa.ARPA by AMSAA via smtp; 18 Dec 84 9:30 EST Date: Tue, 18 Dec 84 8:15:24 CST From: Crede Edens To: INFO-CPM@amsaa.arpa cc: edens@ALMSA-1.ARPA Subject: Need a BREAK key. I noticed someone made a request for information about a "break" key the other day. I also need this on my NEC APC. I haven't found a work around for it and would appreciate any information from you experts out there. thanks in advance Crede Edens 18-Dec-84 08:42:50-MST,1302;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 08:42:43-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 18 Dec 84 10:07 EST Date: Tue 18 Dec 84 08:03:18-MST From: Rick Conn Subject: Writing ZCPR3 Programs To: info-cpm@AMSAA.ARPA There has been a recent increase in interest by people to write ZCPR3 programs, and I would like to encourage this. One thing that Echelon and I and really pushing in this regard is the idea that ZCPR3 programs are CONSISTENT with each other in a variety of ways -- how the options are invoked, how online help is obtained, etc. It is this consistency that adds to the value of the ZCPR3 system; in particular, the classic problems found under so many CP/M programs, such a "what options are available" and "how do I invoke the options", are not encountered. I really recommend that those wanting to write ZCPR3 programs consider this and read the Echelon newsletters. One of the newsletters, in particular, outlines all the major facets that enhance the consistency of the toolset. In general, the newsletters serve to answer the common questions and provide much insight into the operational and user-interface aspects of the system. Rick ------- 18-Dec-84 09:44:43-MST,2488;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 09:44:35-MST Date: Tue, 18 Dec 84 11:06:54 EST From: Dave Towson (info-cpm-request) To: info-cpm-arpa@Amsaa.ARPA Subject: Addition to archive blurb. Fellow CP/Mers - Earl Boebert at HI-MULTICS has suggested that since there will be greater use of CP/M library (LBR) files in order to conserve space on the MICRO: disk-pack at SIMTEL20, it would be helpful to include in the blurb a description of these files. I heartily agree. Thanks for the suggestion, Earl. Here is the addition. It goes in the FILE TYPES section, and I have included some of the surrounding text, so that those who care to do so can insert it into their copies of the blurb. ------------------------------------------------------------------------------ as a binary file, and then unsqueezed. The unsqueezing can be done on a CP/M system using USQ-20.COM (or whatever is the current version from directory ), or there are several host-based unsqueezers in the and archives (see for example, directories and ). CP/M library files, which can be identified by their ".LBR" extensions, combine several regular CP/M files into a single binary file which contains an internal directory of its contents. They are created using the CP/M library utility, LUxxx.COM (where "xxx" is three digits giving the current version number), or some other compatible utility. Because these are binary files, they are stored in ITS binary format, and they must be retrieved using the special procedures described elsewhere in this message. LUxxx and a newer compatible program called NULUxx (where "xx" is the version) can be found in directory MICRO:. C-language source code for a compatible UNIX utility called LAR (library archiver) is in directory MICRO:. Although the type of storage used for a particular file can usually be inferred from the file-name, this is not always true. It is a good idea to check the appropriate "crclst" file to ascertain the storage format used for each file of interest. This applies to all of the archives except and , where ALL files are presently stored in ASCII. Now, and for the ------------------------------------------------------------------------------ Dave Towson info-cpm-request@amsaa.arpa 18-Dec-84 14:19:06-MST,1395;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 14:19:00-MST Received: From mit-mc.arpa.ARPA by AMSAA via smtp; 18 Dec 84 15:29 EST Date: Mon, 17 Dec 1984 20:58 EST Message-ID: From: "Robert L. Krawitz" To: info-cpm@AMSAA.ARPA Subject: procedure calls in Z-80 or CP/M-based systems cc: rlk%MIT-OZ@MIT-MC.ARPA reply-to: rlk@Mit-Mc.ARPA I'm doing a term paper on the procedure call, and I'm trying to gather information on how procedure calls are performed in various implementations of various languages. I'd be most grateful if anyone either knows something about specific cases or can point me to literature on such. I would be particularly interested in information about how various versions of C do this, as there are a large number and can form a good database for a comparative study. Most useful would be notes from the companies selling such software or articles from the trade press, and pointers to such. Note that by procedure call I am referring to a C or Lisp style procedure, not a subroutine such as Basic. Please reply to me directly. I am on the list but will be going home for two weeks beginning Friday, and will temporarily remove myself from the list at that time. Thanks in advance for any help. Robert^Z 18-Dec-84 16:01:36-MST,1043;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 16:01:26-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 18 Dec 84 17:31 EST Received: from mit-multics.arpa by BRL-AOS.ARPA id a010589; 18 Dec 84 17:29 EST Date: Tue, 18 Dec 84 17:25 EST From: "Paul E. Woodie" Subject: Break key To: info-cpm@BRL.ARPA Message-ID: <841218222547.083887@MIT-MULTICS.ARPA> I in the past have used the rather crude method of switching to a slower line speed and sending a few characters then switching back to the original line speed. This worked with GTE Telenet, but I don't know about other systems. I know this is rather crude, but being rather crude is better than suffering through many lines (or pages) of unwanted information. The only other solution that I know of is using some hardware-specific feature of the particular computer that you happen to be using. There is no implementation of a break key in regular CP/M. --Paul Woodie 18-Dec-84 22:03:02-MST,598;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 22:02:58-MST Received: From ucla-locus.arpa.ARPA by AMSAA via smtp; 18 Dec 84 23:32 EST Date: Tue, 18 Dec 84 13:22 CST From: "Jeff M. Gibson" Subject: archive blurb To: INFO-CPM@Amsaa.ARPA would you please send me a copy of 'archive blurb'. CP/M-80 prefered. thanks in advance, Jeff Gibson UUCP: {cepu,ihnp4,noao,uiucdcs}!bradley!jmg Bradley University ARPA: cepu!bradley!jmg@UCLA-LOCUS Peoria, IL 61625 PH: (309) 692-9069 18-Dec-84 22:13:05-MST,1909;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 22:12:59-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 18 Dec 84 23:45 EST Received: from usenet by BRL-TGR.ARPA id a007462; 18 Dec 84 23:42 EST From: ken Newsgroups: net.micro.cpm Subject: Warning: RIPOFF from GDL Message-ID: <14900004@hp-pcd.UUCP> Date: 16 Dec 84 00:56:00 GMT Nf-ID: #N:hpcvlo:14900004:000:1331 Nf-From: hpcvlo!ken Dec 15 16:56:00 1984 To: info-cpm@AMSAA.ARPA Warning : Potential Rip-Off !!!!!!!!!!!!!!!!! Have you had any contact with Graphics Development Laboratories 2832 Ninth Street Berkeley CA. 94710 (415) 644-3551 A Prof. at Oregon State University with the Dept. of Forest Science tried to purchase one of their graphics boards for S100 bus and has been having a very difficult time. Unfortunately he sent them a check for about $2000 after reviewing their literature, ads in BYTE, and other similar products. They acknowledge having got the $$ in September of '84. However they have not produced any equipment, graphics board, or refund. He has called them numerous times trying to get some satisfaction. Alas over the phone they continually give him dead end responses. If any of you have any suggestions for how to deal with this company, I'd appreciate the suggestions, which I will pass on to my friend at OSU. Also I highly suggest that if you are connsidering dealing with this company that you also consider throwing your money down a hole first. You may get better results. All Responses welcome, especially from people in the Berkeley area, or from anyone associated with this company. I will quickly post any results that may serve to clear the badly tarnished reputation of GDL. -Ken Bronstein hp-pcd!ken (503) 757-2000 X4133 18-Dec-84 22:14:55-MST,1086;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 22:14:50-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 18 Dec 84 23:45 EST Received: from usenet by BRL-TGR.ARPA id a007379; 18 Dec 84 23:40 EST From: craig Newsgroups: net.micro.cpm Subject: EPROM burner wanted Message-ID: <14900003@hp-pcd.UUCP> Date: 14 Dec 84 15:47:00 GMT Nf-ID: #N:hpcvlo:14900003:000:524 Nf-From: hpcvlo!craig Dec 14 07:47:00 1984 To: info-cpm@AMSAA.ARPA I'm looking for an EPROM burner to hang off my S-100 CPM system. It can be plug in or RS-232, etc just so it can program lots of different size proms (1k, 2k, 4k, etc). If it is internal, I would prefer it to use I/O addresses rather than take up memory space. Anyone have any exerience to pass on?? (by the way, I have only seen ads for the SDS and SSM units). Does anyone know know where I can get card guides for my Vector Graphics Vector 1? Is VG still around? Thanks, Craig Durland ...!hp-pcd!craig 18-Dec-84 23:39:51-MST,1360;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 18 Dec 84 23:39:44-MST Received: From rice-gateway.ARPA by AMSAA via smtp; 19 Dec 84 1:10 EST Received: by rice.ARPA (AA00839); Wed, 19 Dec 84 00:05:54 CST Date: Tue, 18 Dec 84 23:26:55 CST From: Paul Milazzo Subject: Kaypro floppy format? To: INFO-CPM@AMSAA.ARPA Message-Id: <1984.12.18.23.26.56.230.00231@Dione.rice> I want to exchange data on 5 1/4" floppies with someone who has a Kaypro II running CP/M 2.2, but I can't figure out the Kaypro's disk format. If someone could describe the format in sufficient detail that I could add a new Disk Parameter Block template to my BIOS, I'd be home free. Thus, I need to know the density, sides, TPI, sector size, skew factor, number of reserved tracks, allocation block size, etc. Any information someone could supply would be a big help. If it matters, I have an H89 running CP/M 3 with a Magnolia 77316 floppy controller. Please reply directly to me, and spare the List these boring details. I'd be happy to summarize should anyone express interest. Many Thanks, Paul G. Milazzo Dept. of Computer Science Rice University, Houston, TX ARPA: milazzo@rice.ARPA UUCP: {cbosgd,convex,cornell,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzo 19-Dec-84 11:39:49-MST,1389;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 19 Dec 84 11:39:42-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 19 Dec 84 12:56 EST Received: from usenet by BRL-TGR.ARPA id a020907; 19 Dec 84 12:40 EST From: greenber%acf4.uucp@BRL-TGR.ARPA Newsgroups: net.micro.cpm Subject: Re: EPROM burner wanted Message-ID: <10000016@acf4.UUCP> Date: 19 Dec 84 14:23:00 GMT Nf-ID: #R:hpcvlo:14900003:acf4:10000016:000:799 Nf-From: acf4!greenber Dec 19 09:23:00 1984 To: info-cpm@AMSAA.ARPA <> I use a really nice EPROM burner: Programmer 4+ Periphco 1659 Scott Blvd #1 Santa Clara, CA 95050 (408)-244-5214 It costs about $200. Features: - Programs 2716, 2732, 2764, 27128's - RS232 - Selectable as Data set or terminal - All Dc is generated on board (you do have to buy you're own transformer!) - Handles the "A"'s too: 21/25 VDC - ZIF on board - Software is pretty good: Program, Read, Verify. Dumps in ASCII and HEX - CP/M and other os's It does not come in a pretty box, it is pretty slow, it isn't as nice as the $5000 DataIo I use sometimes, but it meets my "home/hobby/business" purposes. I'm not attached to Periphco, except at the wrist and ankles. Call them and ask for the spec sheet. Ross M. Greenberg @ NYU ----> allegra!cmcl2!acf4!greenber <---- 19-Dec-84 15:45:12-MST,836;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 19 Dec 84 15:45:05-MST Received: From ucb-vax.arpa.ARPA by AMSAA via smtp; 19 Dec 84 17:22 EST Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.24/4.40) id AA04673; Wed, 19 Dec 84 14:22:56 pst Received: by ucbarpa.ARPA (4.24/4.40) id AA01905; Wed, 19 Dec 84 14:23:29 pst Date: Wed, 19 Dec 84 14:23:29 pst Message-Id: <8412192223.AA01905@ucbarpa.ARPA> From: Phil Lapsley To: info-cpm@amsaa.ARPA Subject: S-100 Byte CPU card data Does anyone know where I might obtain a manual on the old S-100 Byte Indutries 8080 CPU board? I have one, and a schematic for it, but I'd be interested in getting more information on it. Thanks. Phil Lapsley (phil@Berkeley.ARPA, ...!ucbvax!phil) 19-Dec-84 22:53:16-MST,630;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 19 Dec 84 22:53:11-MST Received: From mit-mc.arpa.ARPA by AMSAA via smtp; 20 Dec 84 0:33 EST Date: 20 December 1984 00:32-EST From: Jerry E. Pournelle Subject: Warning: RIPOFF from GDL To: ken%hp-pcd.uucp@Brl-Tgr.ARPA cc: info-cpm@Amsaa.ARPA In-reply-to: Msg of 16 Dec 84 00:56:00 GMT from ken please have your friend send me a letter with the details at BYTE, (and send them a carbon of the letter to me). That may or may not help but it won't cost much. JEP 20-Dec-84 03:10:18-MST,1141;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 03:10:13-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 20 Dec 84 4:46 EST Received: from usenet by BRL-TGR.ARPA id a003345; 20 Dec 84 4:40 EST From: Shields Newsgroups: net.general,net.wanted,net.micro.cpm Subject: Mattel Intellivoice info wanted Message-ID: <2448@pur-ee.UUCP> Date: 18 Dec 84 02:42:02 GMT To: info-cpm@AMSAA.ARPA Recently we found a bargain at the local J.C. Penney store - they were liqui- dating their stock of Mattel Intellivoice modules for $5 each - used to be $75-100 a year ago. Inside is a General Instruments SP-0256 speech processor chip and what appears to be a programmable sound generator chip, as well as filters, pre-amp, etc. We were interested in interfacing one of these modules to a micro, but don't have any documentation. Does anyone out there in netland have a schematic and/or any other documentation for the Intellivoice module? Thanks in advance. Jeff Shields (pur-ee!shields) Tim Miller (pur-ee!miller) 20-Dec-84 07:25:46-MST,4932;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 07:25:12-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 20 Dec 84 8:51 EST Date: 20 Dec 1984 06:52 MST (Thu) Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@Amsaa.ARPA, Telecom@Mit-Mc.ARPA Subject: 2400 baud modems This is file 2400BAUD.TXT - relayed from the RCPM circuit: --Keith From: Wayne Masters, Potpourri sysop (408) 378-7474 300/1200/2400 baud San Jose, Ca. Subject: New 2400 baud modems 8/19/84 Many of you have asked technical questions about the 2400 baud modems now on the market (and more being introduced monthly). As most of you know by now Irv Hoff and I have been beta testing 2400 baud for several months. The test results are amazing to say the least. Running controlled tests on standard dial-up phone lines with random "noisy connections", the number of "hits" on a given file transfer is less by a factor of 10 using 2400 baud vs 1200 baud. So it is concluded that 2400 baud technology is working and will soon be available on most commercial and private dial-up systems. Now, what is a "standard" 2400 baud modem? You will no doubt see various technical descriptions of a given 2400 baud modem touting it's features. Be sure the modem you choose has this specification: CCITT recommendation for a V.22 bis modem communicating at 2400 bps. Further explanation of this CCITT standard: Frequency- Bell 212A Encoding modulation- 16 level psk (quadrature AM or QAM) This sounds a lot like the Bell 212A standard for 1200 baud--and it is. The difference is in the encoding or modulation scheme. Bell 212A 1200 baud uses 4 level psk and 2400 baud uses 16 level psk. If you "listen" to the 2400 baud carrier it will sound exactly like the familiar 1200/212A- like "static" or a scratchy noise. Features to look for in your search for the "right" 2400 baud modem: 1. Does it retain 300 baud bell 103 capability? (most offer 1200 baud as a "fallback") 2. Is it "smart"--a biggy if you intend to call other systems a lot. 3. Does it offer autoanswer--a biggy if you run a remote system. 4. Price--a real biggy So far, none of the modems on the market offer all these features in a "standalone" modem. That is one big reason why Irv Hoff and I have been involved with Racal-Vadic--not only beta testing to prove 2400 baud technology...but to get the features most users prefer designed into the modem. Others may follow some day but Racal Vadic will introduce their "standalone" modem in time for Christmas 84 with the following features: 1. Smart-autodialing. It will recognize both the Hayes and Vadic commands. 2. 0-300 baud at both Bell 103 and Vadic protocols 3. 1200 baud at both Bell 212A and Vadic protocols 4. 2400 baud CCITT V.22 bis 5. Price is expected to be $695.00 retail The first release will be an external RS-232 model. Early 1985 will see the single card slot version for IBM PC's and compatiables. In order for 2400 baud to be in "great demand" there must be systems available for the users to access. I am working with Racal-Vadic to identify RCP/M and RBBS systems where 2400 baud modems could be placed to generate public interest in 2400 baud. Sysop's should contact Potpourri at 408-378-7474 if interested in participating. Now about software to support 2400 baud. Both MDM7 and MEX will support 2400 baud if the user modifies his port overlay to setup his port for 2400 baud. For sysops who use BYE3, the problem is different. Most implementations of BYE rely on the hardware's Data Available signal (DAV) to trigger a check-for-carriage-return sequence at different baud rates. If most hardware is like mine (Z80 SIO), if the hardware is set to look at 300 baud and the modem answers at 2400 baud the DAV is never set and you are in an endless loop. Same thing happens if you set the hardware to 2400 and the modem answers at 300. I modified BYE3 (version 26 and up) to handle TSTBAUD differently. I chose to look at each baud rate in 2 second windows, 300 first, then 1200 and 2400, and loop thru this sequence until a C/R or L/F is detected. The caller is never more than 4 seconds away from his calling speed but must continue to issue c/r's until the familiar message "Nulls, if needed" is displayed. Sysop's who choose to use BYE3 need only add the "SET2400" code into their port insert. Well, enough for now. Feel free to contact me if you are more confused now than you were before reading this. -wayne masters, Potpourri sysop- 408-378-7474 20-Dec-84 08:45:30-MST,1121;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 08:45:24-MST Date: Thu, 20 Dec 84 10:18:50 EST From: David Towson (SECAD) To: Paul Milazzo cc: INFO-CPM@AMSAA.ARPA Subject: Re: Kaypro floppy format? Paul and other list members - I would like to take this opportunity to poll the readership: Paul has asked an interesting question concerning the format used for Kaypro disks, and he has asked for replies to be sent directly to him in order to spare the list "the boring details". I have seen this sort of plea several times recently, and I would like to know whether our readers really find this sort of thing boring. Certainly, I don't find it boring. It seems to me that this is the sort of thing the list is for - an exchange of useful information concerning CP/M and its many implementations. In fact, I feel that the list will die if such an exchange ever stops. So how do you all feel about this? All views are solicited. Dave info-cpm-request@amsaa.arpa 20-Dec-84 08:47:03-MST,733;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 08:46:59-MST Date: Thu, 20 Dec 84 10:00:06 EST From: David Towson (SECAD) To: Jeff M. Gibson cc: INFO-CPM@Amsaa.ARPA Subject: Re: archive blurb Jeff - Before I send you over 20-thousand characters of archive blurb, I want you to know that it appears from your address that you cannot do FTP file transfers from SIMTEL20. Therefore, reading the archive blurb may do you little good. However, if you still want a copy, send your reply to info-cpm-request@amsaa.arpa and I'll send you one. Dave Towson info-cpm-request@amsaa.arpa 20-Dec-84 09:53:01-MST,907;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 09:52:52-MST Received: From mit-mc.arpa.ARPA by AMSAA via smtp; 20 Dec 84 11:14 EST Date: Thu, 20 Dec 1984 11:18 EST Message-ID: From: SR.KROHN@mit-speech To: David Towson (SECAD) Cc: Paul Milazzo , INFO-CPM@AMSAA.ARPA Subject: Kaypro floppy format? In-reply-to: Msg of 20 Dec 1984 10:18-EST from David Towson (SECAD) I fully agree. Much of the interest presented by the INFO-CPM list consists in learning how specific implementation problems have been or are suggested to be resolved. What IS truely boring is reading a lot of questions to which one never sees the answer. Ken Krohn KBK%MIT-SPEECH@MIT-MC.ARPA 20-Dec-84 12:12:34-MST,689;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 12:12:29-MST Received: From nosc-tecr.arpa.ARPA by AMSAA via smtp; 20 Dec 84 13:39 EST Date: 20 Dec 1984 1027-PST From: Pawka Subject: Perfect Writer Installation To: INFO-CPM@AMSAA.ARPA Reply-To: PAWKA@Nosc-Tecr.ARPA I'm trying to install Perfect Writer on a Z-80 based system with a TVI 970 terminal which is supposed to emulate a VT-100. Although PW claims it knows about a VT-100, it doesn't. Has anyone gone thru the drill of changing the terminal definition strings? I'd appreciate any help. Mike PAWKA@NOSC-TECR.ARPA ------ 20-Dec-84 12:32:28-MST,2355;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 12:32:12-MST Received: From rice-gateway.ARPA by AMSAA via smtp; 20 Dec 84 13:42 EST Received: by rice.ARPA (AA13164); Thu, 20 Dec 84 12:33:16 CST Date: Thu, 20 Dec 84 11:26:42 CST From: Paul Milazzo Subject: Re: Kaypro floppy format? [appropriateness] To: David Towson (SECAD) Cc: INFO-CPM@AMSAA.ARPA Message-Id: <1984.12.20.11.26.43.860.12518@Dione.rice> In-Reply-To: a message from David Towson dated Thu, 20 Dec 84 10:18:50 EST Dave: I'm glad you found my question "interesting", since I was a bit unsure that I had addressed it to the correct audience. I believe that the exchange of such technical information is of great value to those in need, and of some interest to those who, like me, are blessed (?) with an insatiable appetite for technical detail. Still, the readership of this List, like that of most others, has a broad range of needs, interests, and technical experience. This disparity is actually a blessing, because the novices have an opportunity to learn from the discussions of wizards, and the dedicated CP/M hackers get to hear what the rest of us *really* want. Thus, I would hate to be the cause of a mass exodus of INFO-CPM readers who cannot tolerate even one more letter about faster DMA on someone's SuperZippy XYZ-4999 computer. It seems to be the nature of electronic mail that an individual's tolerance for irrelevant messages is primarily a function of his terminal line speed and his mail or BBoard system's facility in skipping unwanted information. In deference to those readers stuck with /bin/mail at 300 baud, I therefore offered to summarize the responses to my question, possibly in a single message to the List. While this means more work for me, it still provides everyone with the information, eliminates redundant messages, and allows those uninterested to leap over the entire discussion in a single keystroke. Comments? Paul G. Milazzo Dept. of Computer Science Rice University, Houston, TX P.S. I take the sentiment recently expressed to mean that if nothing else, I should certainly send in a summary of responses (should any ever appear :-). 20-Dec-84 13:15:08-MST,1479;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 13:14:58-MST Received: From utexas-20.arpa.ARPA by AMSAA via smtp; 20 Dec 84 14:40 EST Date: Thu 20 Dec 84 13:40:23-CST From: John Otken Subject: Suggestion.. To: info-cpm@AMSAA.ARPA Since the current policy is going in the direction of LBRs might I suggest that you LBR the ZCPR3 files... Right now there are so many that it would take massive typing to down load. Or people are going to do what I am about to do which is to whip out an old SNOBOL program to turn directory listings into submit files and down load them one at a time.. Another interesting idea I had not too long ago dealt with the problem of HEX files. You could create a special mail box where people could send requests for converting COM files to HEX files. A program could read the mail and auto- matically do the conversions. Of course the problem with this idea is that like all ideas it would take somebody to do it. I would volunteer but I am not going to be working at UT much longer (Friday is my last "real" day) so I guess this one can go in the bit bucket. I not sure of my near future status but I would like to let you guys know I appreciate all the work you have put into the maintenance of info-cpm & MICRO:. BTW, don't kill my subscription yet, I will let you know when my UT account is going to die. John Otken ------- 20-Dec-84 13:42:42-MST,929;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 13:42:33-MST Received: From mitre.arpa.ARPA by AMSAA via smtp; 20 Dec 84 15:12 EST Date: 20 Dec 1984 15:04:51 EST (Thursday) From: Jeffrey Edelheit Subject: Re: Kaypro floppy format? In-Reply-to: Your message of 20 Dec 1984 10:18:50 EST To: David Towson (SECAD) Cc: info-cpm@Amsaa.ARPA Dave - Several of the other interest groups take the digest approach. While it's nice to have the msgs in a concise digest, it lacks the spontaneity of info-cpm. I don't think that having one person summarizing all of the responses to his/her question is all that bad; it certainly reduces the communications cost for all of those folks forced to use uucp at 300/1200 bps. Any other comments from our fellow info-cpmer's is welcome. Jeff Edelheit (edelheit@mitre) 20-Dec-84 13:43:49-MST,729;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 13:43:44-MST Date: Thu, 20 Dec 84 15:03:28 EST From: David Towson (SECAD) To: John Otken cc: info-cpm@AMSAA.ARPA Subject: Re: Suggestion.. John - I think the idea of librarying the ZCPR3 files makes a lot of sense. How about it, Rick? I just updated my local copy of these files using an automatic FTP script. There are now 231 files! Next, I plan to write a UNIX shell script to combine them into several libraries, each of which will fit on one microcomputer disk, before I tackle the long download. Dave towson@amsaa.arpa 20-Dec-84 14:25:07-MST,2944;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 14:24:53-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 20 Dec 84 15:49 EST Received: from usenet by BRL-TGR.ARPA id a012655; 20 Dec 84 15:40 EST From: greenber%acf4.uucp@BRL-TGR.ARPA Newsgroups: net.micro.cpm Subject: Re: EPROM burner wanted Message-ID: <10000017@acf4.UUCP> Date: 20 Dec 84 14:59:00 GMT Nf-ID: #R:hpcvlo:14900003:acf4:10000017:000:2319 Nf-From: acf4!greenber Dec 20 09:59:00 1984 To: info-cpm@AMSAA.ARPA <> Looks like my last posting didn't get off the groud....so here it is again(I moved the header to EOF...take a look you guys at tgr!): ==================================================================== <> I use a really nice EPROM burner: Programmer 4+ Periphco 1659 Scott Blvd #1 Santa Clara, CA 95050 (408)-244-5214 It costs about $200. Features: - Programs 2716, 2732, 2764, 27128's - RS232 - Selectable as Data set or terminal - All Dc is generated on board (you do have to buy your own transformer!) - Handles the "A"'s too: 21/25 VDC - ZIF on board - Software is pretty good: Program, Read, Verify. Dumps in ASCII and HEX - CP/M and other os's It does not come in a pretty box, it is pretty slow, it isn't as nice as the $5000 DataIo I use sometimes, but it meets my "home/hobby/business" purposes. I'm not attached to Periphco, except at the wrist and ankles. Call them and ask for the spec sheet. Ross M. Greenberg @ NYU ----> allegra!cmcl2!acf4!greenber <---- ============================================================================ Here's what caused the problem with this message. What's up tgr??? From seismo!postmaster@AEROSPACE.ARPA Thu Dec 20 01:55:58 1984 Received: from NYU-CMCL2.ARPA by NYU-ACF4.ARPA; Thu, 20 Dec 84 01:55:55 est Received: by NYU-CMCL2.ARPA; Thu, 20 Dec 84 01:51:19 est Received: from BRL-TGR (brl-tgr.ARPA) by seismo.ARPA with SMTP; Thu, 20 Dec 84 01:45:58 EST Message-Id: <8412200645.AA04716@seismo.ARPA> Received: from aerospace.arpa by BRL-TGR.ARPA id a000744; 20 Dec 84 1:43 EST Date: Wed, 19 Dec 84 10:16:53 PST From: The System Postmaster Subject: Undeliverable mail In-Reply-To: <10000016@acf4.UUCP> To: greenber%acf4.uucp@BRL-TGR.ARPA Status: R ===== POSTMAN output follows ===== "bond": not delivered (unknown user) ===== unsent message follows ===== Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 19 Dec 84 12:56 EST Received: from usenet by BRL-TGR.ARPA id a020907; 19 Dec 84 12:40 EST From: greenber%acf4.uucp@BRL-TGR.ARPA Newsgroups: net.micro.cpm Subject: Re: EPROM burner wanted Message-ID: <10000016@acf4.UUCP> Date: 19 Dec 84 14:23:00 GMT Nf-ID: #R:hpcvlo:14900003:acf4:10000016:000:799 Nf-From: acf4!greenber Dec 19 09:23:00 1984 To: info-cpm@AMSAA.ARPA 20-Dec-84 14:30:15-MST,623;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 14:30:11-MST Received: From wsmr08.arpa.ARPA by AMSAA via smtp; 20 Dec 84 15:45 EST Date: Thu, 20 Dec 84 13:44:33 MST From: John Gilbert CD Subject: Re: Kaypro floppy format? [appropriateness] In-Reply-To: Your message of Thu, 20 Dec 84 11:26:42 CST To: Paul Milazzo Cc: David Towson (SECAD) , INFO-CPM@AMSAA.ARPA Paul, I like your suggestion. If you ask a question, you incur an obligation to summarize the responses. John Gilbert 20-Dec-84 14:31:30-MST,717;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 14:31:18-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 20 Dec 84 15:49 EST Received: from usenet by BRL-TGR.ARPA id a012659; 20 Dec 84 15:40 EST From: greenber%acf4.uucp@BRL-TGR.ARPA Newsgroups: net.micro.cpm Subject: Re: Warning: RIPOFF from GDL Message-ID: <10000018@acf4.UUCP> Date: 20 Dec 84 15:26:00 GMT Nf-ID: #R:Mit-Mc:-667000:acf4:10000018:000:147 Nf-From: acf4!greenber Dec 20 10:26:00 1984 To: info-cpm@AMSAA.ARPA <> Jerry: We can't arpa outa here...please mail me your uucp address.... Ross M. Greenberg @ NYU ----> allegra!cmcl2!acf4!greenber <---- 20-Dec-84 15:18:13-MST,872;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 15:18:08-MST Received: From ddn1.arpa.ARPA by AMSAA via smtp; 20 Dec 84 16:20 EST Date: 20 Dec 84 15:48:45 EST From: dbrothers@DDN1.ARPA Subject: COM to HEX conversion To: info-cpm@amsaa.arpa CC: CC.Otken@utexas-20.arpa You may be interested to know that the following UNIX shell will convert any file into hex format. od -bh $1 | awk '/^.0/{print substr($1,2,2) substr($2,2,2) substr($3,2,2) substr($4,2,2) substr($5,2,2) substr($6,2,2) substr($7,2,2) substr($8,2,2)}' | dd conv=ucase Use 'CHMOD u+x conv' to make the shell (which I named conv) executable. The shell is invoked as follows: conv file.con (The result will be sent to the terminal) conv file.con >file.hex (the reult will be sent to the file called file.hex) Doug 20-Dec-84 18:20:34-MST,1385;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 18:20:03-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 20 Dec 84 19:53 EST Received: from usenet by BRL-TGR.ARPA id a015682; 20 Dec 84 19:41 EST From: Michael Cooper Newsgroups: net.micro,net.micro.cpm,net.micro.zx Subject: Info on OmegaByte (Northstar) Z-80A wanted Message-ID: <762@reed.UUCP> Date: 18 Dec 84 22:51:01 GMT To: info-cpm@AMSAA.ARPA [ The Sleeper has awakened! ] I am looking for info on the above mention system that the Electronics Department at my school has just aquired. We know almost nothing about what it ran/runs. It was donated by a Law Firm that used it for word proccessing and some accounting. It is believed to have run some version of CP/M. We don't have any software or even a bootable disk for it. Would someone who has had some experience with or has any idea of where I can find some info on this beast? Michael Cooper ______________________________________________________________________________ {decvax, ucbvax, pur-ee, uw-beaver, masscomp, cbosg, mit-ems, psu-cs, uoregon, orstcs, ihnp4, uf-cgrl}!tektronix \ +---!reed!mikec {teneron, ogcvax, muddcs, cadic, oresoft, grpwre, / psu-cs, omen, isonvax, nsc-pdc}---+ 20-Dec-84 20:36:47-MST,1048;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 20 Dec 84 20:36:37-MST Received: From utexas-20.arpa.ARPA by AMSAA via smtp; 18 Dec 84 22:54 EST Date: Tue 18 Dec 84 21:57:13-CST From: Douglas Good Subject: Kaypro BIOS To: info-cpm-request@AMSAA.ARPA Resent-Date: Thu, 20 Dec 84 22:12:50 EST Resent-From: cpmlist@AMSAA.ARPA Resent-To: info-cpm@AMSAA.ARPA I'm almost positive that this answer has been answered before but I didn't catch it the first time around because I wasn't using ZCPR then. The problem I think I've encountered in the Kaypro's BIOS is that the Warm Boot routine calls part of the Cold Boot routine which causes ZCPR to rewrite the maximum disk and maximum user number. Does this sound at all familiar? Actually I'm using NZCPR which is only a little different than ZCPR. I'm keeping the maximum user area in 3F, maximum disk in 3D, and wheel byte in 3E. Any help is appreciated. --Doug ------- 21-Dec-84 08:52:08-MST,511;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 21 Dec 84 08:52:04-MST Received: From hi-multics.arpa.ARPA by AMSAA via smtp; 21 Dec 84 10:15 EST Date: Fri, 21 Dec 84 09:13 CST From: Boebert@HI-MULTICS.ARPA Subject: .REL format To: info-cpm@AMSAA.ARPA Message-ID: <841221151358.266584@HI-MULTICS.ARPA> Does there exist a document (underground or otherwise) which describes the internal form of .REL files? Thanx, Earl (Boebert -at HI-Multics) 21-Dec-84 09:15:55-MST,522;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 21 Dec 84 09:15:50-MST Received: From hi-multics.arpa.ARPA by AMSAA via smtp; 21 Dec 84 10:15 EST Date: Fri, 21 Dec 84 09:12 CST From: Boebert@HI-MULTICS.ARPA Subject: James E. Hendrix's net address To: info-cpm@AMSAA.ARPA Message-ID: <841221151224.106120@HI-MULTICS.ARPA> Does anyone know if James E. Hendrix, the author of Small C V2, is reachable from the arpanet? Thanx, Earl (Boebert -at HI-Multics) 21-Dec-84 09:41:12-MST,1159;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 21 Dec 84 09:41:06-MST Received: From office-2.arpa.ARPA by AMSAA via smtp; 21 Dec 84 11:08 EST Date: 21-Dec-84 08:08 PST From: ACB.TYM@OFFICE-2.ARPA Subject: Technical trivia To: info-cpm@amsaa.arpa Message-ID: (everybody else puts a dummy line here. Why not?) Speaking of technical data! I just spent most of a day discovering that BDS C uses the interrupt vector at location x'30' (RST 6). I have often thought of using RST instructions for linkages in self relocating code BUT... I fear the impact on some unsuspecting user with some hardware interrupt configuration or some special storage locations (Some code uses the high end of interrupt vector 7 (DDT's RST location) already. I read both CP/M documentation and BDS C documentation and find that in the CP/M documentation RST 6 locations are reserved and RST 7 is used by DDT. I was a tad surprised to find that BDS C used RST 6. Of course that is because I was using it (caught in the act!) although the use was unintentional (a bug!). 21-Dec-84 12:48:52-MST,1161;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 21 Dec 84 12:48:31-MST Received: From isi-uci-gw.ARPA by AMSAA via smtp; 21 Dec 84 14:17 EST Date: 21 Dec 84 10:05:02 PST (Fri) Message-ID: <280.472500302@uci-icse> To: ACB.TYM%OFFICE-2.ARPA@Uci-750a.ARPA cc: info-cpm%amsaa.arpa@Uci-750a.ARPA, jsweet@Uci-Icse.ARPA Subject: Re: Technical trivia In-reply-to: Your message of 21-Dec-84 08:08 PST. From: Jerry Sweet Received: from Localhost by UCI-ICSE for jsweet; 21 Dec 84 10:05:47 PST (Fri) Received: from Uci-Icse by UCI-750a; 21 Dec 84 11:17:40 PST (Fri) Some errata for the BDS C version 1.50a explains how to reconfigure the runtime to use a different RST address. In general, it is unsafe to use the RST locations unless your software can be reconfigured as well. The Z80 can arrange for hardware interrupt vectors to be placed elsewhere in memory, but (a) not everyone has a Z80, (b) not everyone uses the extended scheme, and (c) that still doesn't help when using software that may already occupy the RST vectors. -jns 21-Dec-84 21:33:29-MST,590;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 21 Dec 84 21:33:24-MST Received: From mit-multics.arpa.ARPA by AMSAA via smtp; 21 Dec 84 23:08 EST Date: Fri, 21 Dec 84 23:09 EST From: AALevy@MIT-MULTICS.ARPA Subject: ZCPRZCPR3 on Apple 2e To: Info-CPM@AMSAA.ARPA, Info-Apple@BRL.ARPA Message-ID: <841222040936.550198@MIT-MULTICS.ARPA> Has anyone implemented ZCPR3 on a 2e? The only implementation I know about uses addresses that screw up a 2e. Also has anyone implemented I/O redirection on an Apple? Thanks, Allan 22-Dec-84 04:52:04-MST,676;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 04:51:57-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 22 Dec 84 6:02 EST Received: from usenet by BRL-TGR.ARPA id a006656; 22 Dec 84 5:50 EST From: bob%zeppo.uucp@BRL-TGR.ARPA Newsgroups: net.micro.cpm Subject: 128k/192k Applicards Message-ID: <1125@zeppo.UUCP> Date: 21 Dec 84 14:54:03 GMT Sender: bob%zeppo.uucp@BRL-TGR.ARPA Nf-ID: #N:zeppo:24100001:000:110 Nf-From: zeppo!bob Dec 21 09:53:00 1984 To: info-cpm@AMSAA.ARPA Has anyone had experience with the 128K or 192K expansions for the PCPI Applicard used for CPM in Apple 2's? 22-Dec-84 08:58:10-MST,921;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 08:58:03-MST Received: From hi-multics.arpa.ARPA by AMSAA via smtp; 22 Dec 84 10:37 EST Date: Sat, 22 Dec 84 09:32 CST From: Boebert@HI-MULTICS.ARPA Subject: Re: 128k/192k Applicards To: info-cpm@AMSAA.ARPA Message-ID: <841222153241.261279@HI-MULTICS.ARPA> I have a 192k Applicard on a ][+ and I think it's great. I definitely advise getting the 192k for use with text editors; Mince runs like stink at 6mhz, swapping off the "silicon disk." It is extremely fast and convenient to have your program set for a given application on the silicon disk and be able to use both floppies for data. PCPI documentation is a little sparse, and I would definitely supplement it with Cortesi's "Inside CP/M," but their technical assistance over the phone is first-rate. Earl (Boebert -at HI-Multics) 22-Dec-84 10:37:29-MST,6137;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 10:37:10-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 22 Dec 84 12:02 EST Date: Sunday, 16 December 1984 20:39-MST Message-ID: Sender: decvax!ihnp4!mgnetp!we53!busch!wuphys!scott@Ucb-Vax.ARPA From: decvax!ihnp4!mgnetp!we53!busch!wuphys!scott@Ucb-Vax.ARPA To: Info-Micro@Brl.ARPA Subject: summary of s-100 9-track cntrlr query ReSent-From: KPETERSEN@Simtel20.ARPA ReSent-To: Info-Cpm@Amsaa.ARPA, Info-Micro@Brl.ARPA ReSent-Date: Sat 22 Dec 1984 09:53-MST Here are the responses I got from my request for s-100 tape drive controllers. My apologies for the long delay. It turns out that we are going to use a "general purpose parrallel interface" to hook the Kennedy 9100 to the s-100 Compupro. The device is called "Interfacer 2" and is made by Vector Electronic Co. (POB 4336, Sylar CA 91432, phone 818-365-9661). It is triple parallel, single rs232serial I/O board. I should say that I am not directly connected with the group that is doing the work and cannot explain why it is they chose to go this route. They are wiring it up and writing the code to manipulate the parallel in/out registers on the interface to do al the functions of a standard tape drive controller. The last word with the principles on the project indicated that they were able to read and write 800bpi tapes, but were having troubles checking the CRC and LRC bytes. This problem was only on the Compupro end, as they could read perfectly s-100 written tapes on the PDP11/34-EmulexTC11-Kennedy9100 system. I have not asked these respondants for a release to forward this information (it's hard to see why they would object), but if you contact them you may catch them unawares. Go accordingly. I have edited out the headers; the bodies are intact. Thanks for all your replies and I hope this is usefull to others. Scott ihnp4!wuphys!scott "I am a child of the unixverse." ----------------------------original request------------------------------- I am looking for a manufacture(s) of S-100 bus controllers for 9-track tape drives (industry std interface - Pertec; Kennedy 9100 to be exact). I realize this is a little odd and is why I am having trouble locating a seller. Any pointers to even potential manufactures would be much appreciated. ihnp4!wuphys!scott Thanks. Scott Barthelmy, Washington U., Physics Dept., St. Louis, MO. -----------------------------------reply------------------------------- From: Subject: Re: S-100 controller for 9-track mt wanted There was a company that used to have a small ad in the back of Byte every month -- but I can't remember the name. You might try: Ibex Computer Corp. 20741 Marilla St. Chatsworth CA 91311 (213) 709-8100 Bert Johnston I know they have IBM PC, maybe S-100 too? David DiGiacomo, BRAG Systems Inc., San Mateo CA (415) 342-3963 (...decvax!ucbvax!hplabs!bragvax!david) -----------------------------------reply------------------------------- From: ihnp4!utcsrgv!mason It seems to me there have been some ads in BYTE about tape drive/controllers for IBM-PC & their ilk...you might try talking to one of them...or Pertec. Dave -----------------------------------reply------------------------------- From: There are 2 S-100 controller manufactures that I am aware of. Konan Corp. in Phoenix AZ has a microprocessor based system but has a limited block size of up to 8k. It transfers data into internal ram, and then you use programmed I/O to read the data. The board also contains a centronics printer port. I have used this one and would highly recomend it. Price is around $1,000. The other I know of, I have a data sheet somewhere is I beleave Overland Data Systems (or something like it) in El Cajon, CA (I think). It uses DMA and can have block sizes of up to 64k. I don't remember the price. If the you need to contact them and can't find them from the above info, mail me a message and I'll try to find the data sheet. Good luck. [Row, row, row your bits, gently down the stream...] Mike Lesher Burroughs ASG, San Diego, CA. (..!bmcg!mikel) -----------------------------------reply------------------------------- From: ihnp4!uw-beaver!uw-june!entropy!dataio!weil (Steve Weil) I don't work there anymore, but when I left, Dual Systems was putting the finishing touches on a 9-track controller. My impression is that we (they) have the highest quality boards available on the S-100 bus. (They decided to make their own because there were no others that were reliable.) They are: Dual Systems Corp. 2530 San Pablo Ave. Berkeley, Ca. 94710 (415) 549-3854 Steve Weil Data I/O ucbvax!lbl-unix!uw-beaver!teltone!dataio!weil unisoft!teltone!dataio!weil entropy!dataio!weil -----------------------------------reply------------------------------- From: (unknown) Subject: 9tr on S100 Great news! SUch things DO exist. Contaact DUAL Systems, 2530 San Pablo Ave, Berkeley CA. Phone 415-549-3854. They have a board called TCON which drives industry-standard 9tr drives (several particular drives `qualified' for their support; others may work) up to 100 ips. Ian Darwin, Toronto {ihnp4|decvax}!utcs!ian -----------------------------------reply------------------------------- From: ihnp4!seismo!hadron!tsp-agv (T. Scott Pyne (AGV)) Subject: Re: 9-track on S-100 This may be a solved problem by now for you. if not, a company called Konan Systems makes one, along with other "large machine" peripheral controllers for S-100 (like SMD drives). They claim "strict compliance with IEEE 696 standard", but who doesn't these days. I don't have their address/phone in front of me, but they advertise most months in Microsystems. If you can't find an ad write back to me and I'll dig it up from a back issue. Hope this helps. Scott seismo!hadron!tsp 22-Dec-84 10:47:51-MST,2110;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 10:47:43-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 22 Dec 84 12:17 EST Date: Tuesday, 18 December 1984 13:57-MST Message-ID: Sender: decvax!ihnp4!ihuxe!klotz@Ucb-Vax.ARPA From: decvax!ihnp4!ihuxe!klotz@Ucb-Vax.ARPA To: Info-Micro@Brl.ARPA Subject: S-100 div./696 corp ReSent-From: KPETERSEN@Simtel20.ARPA ReSent-To: Info-Micro@Brl.ARPA, Info-Cpm@Amsaa.ARPA ReSent-Date: Sat 22 Dec 1984 10:01-MST As many of you probably know, pixel corporatoin offered some winchester disk drives at remarkable prices. Well a friend bought one and we started to look for an interface/controller for the beast. We called these people, s-100 , and asked if they had an interface card and they recommended that we buy their DISK 2 controller from Compupro. They assured us that this card was the proper interface for the SA1004. We order the card and at the same time order the manual from Shugart. The card came in about a month ago and the manual came last week. After careful investigation it became apparent that the two did not go together. We called the company and talked to the Technical Manager. He insists that there is only one standard for 8 inch Winchester disk. He has never heard of the SA1000 standard and refused to take the card back since we have had it for over 30 days. We tried to assure him that the card had not be used, in fact it is still in the original wrappers. So we have to eat his mistake. For those of you who may not know, SA1000 is considered by Western digital and Xebec to be the most popular standard for the 8 inch drives, and the DISK 2 is for the Fujitsu drive and the SA4000, which we could neither find the drives of the documentation. The bottom line is that we suggest that no one buy from these people. Meanwhile we are going to collect documentation for the owner of the company to enlighten him/her to the actual standard and the ignorance of the "Technical Manager". 22-Dec-84 11:11:30-MST,1922;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 11:11:24-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 22 Dec 84 12:39 EST Date: 22 Dec 1984 10:41 MST (Sat) Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@Amsaa.ARPA Subject: Revised Simtel20 CP/M directories quick reference list Quick reference list to SIMTEL20's MICRO: directories as of Dec. 22, 1984 (where 'x' is one of the names below): 22RSX CPM3 FORTH-83 MODEM2 SQUSQ 6502 CPM86 GENASM MODEM7 STARTER-KIT AMETHYST CPMLIB GENCOM MODEM903 SUBMIT APPLE CPR86 GENDOC MSOFT SYSLIB ASMUTL CUG HAMMING NEWS SYSLIB3 ATARI DBASEII HAMRADIO NSTAR SYSUTL BASIC DEBUG HDUTL OSBORN TERM BDOS DIRUTL HEATH PACKET TOPS-20 BDSC-1 DISASM HELP PASCAL TRS-80 BDSC-2 DISKPLOT HEX PCDOS TURBODOS BDSC-3 DSKBUF IBM-PC PILOT80 TXTUTL BDSC-4 DSKUTL INSIDCPM PLOT33 V2CMAC BSTAM EDITC80 KAYPRO PPSPEL VAXVMS BYE3 EDITOR LIST PUBKEY VOICE C80 EPSON MACLIB PUBPATCH WSTAR CATLOG EZCPR MATH RBBS XCCP CB80 FAST2 MEMTEST RBBS4 YAM CBIOS FIDO MEX RCPM Z3LIBS CCP FILCPY MICNET SMALLC2 ZCPR COBOL FILUTL MISC SORT ZCPR2 COMMODORE FORTH MODEM SPELL ZCPR3 22-Dec-84 14:35:27-MST,1808;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 14:35:22-MST Received: From mit-mc.arpa.ARPA by AMSAA via smtp; 22 Dec 84 16:07 EST Date: 22 December 1984 16:06-EST From: Leor Zolman Subject: RST 6 To: info-cpm@Amsaa.ARPA Some early versions of BDS C v1.5 did indeed use RST 6, but as soon as I realized this was wiping out console I/O vectors left and right I stopped distributing it that way. The usage of a RST vector is solely connected with the CDB (C symbolic debugger) mechanism...when you do not intend to use CDB on a program, there is no reason for any RST locations to be clobbered. The reason I originally had the run-time package write into RST 6 was for the case where someone creates a COM file intended for use under CDB (and thus filled with RST 6 calls), then tries to run it standalone. It would bomb if CDB were not there to intercept the RST 6 calls. So, I had the run-time package put a little "no-op" subroutine at location 30h. Bad idea. The way it works NOW is: the mechanism for writing the dummy subroutine is still there, but it is not enabled until you go in and change some EQU's and reassemble the run-time package. Apologies to those of you who have wasted time puzzling over bombing BDS C programs because of this. One more note: the phenomena where BDS C-coded utilities refuse to put out characters until the keyboard is hit can be fixed by recompiling the programs under v1.5. Eariler versions of the library did indeed do the wrong thing when looking at the return value from "check consle status". This problem is likely to keep popping up and biting people until the binary versions of programs like SQ-USQ are updated with more current libraries. -leor 22-Dec-84 15:09:04-MST,2373;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 15:08:56-MST Received: From xerox.arpa.ARPA by AMSAA via smtp; 22 Dec 84 16:46 EST Received: from Flora.ms by ArpaGateway.ms ; 21 DEC 84 22:43:44 PST From: NBaheti.es@XEROX.ARPA Date: 21 Dec 84 22:43:42 PST Subject: Basic "MBOOT" program To: info-cpm@AMSAA.ARPA cc: NBaheti.es@XEROX.ARPA, T.Moore%Mit-Eecs@MIT-MC.ARPA Andrew: I think that this program will do what you are looking for. Let me know how it truns out... -------------------- 80 REM It will work with the Xerox as well as the Kaypro 90 REM FOR THE KAYPRO 100 GOTO 280 110 X=(INP(STATUS)AND RMASK):RETURN 120 Y=INP(MODEM):RETURN 130 X=(INP(STATUS)AND SMASK):RETURN 140 OUT MODEM,Y:RETURN 150 GOSUB 130:IF X THEN 140 ELSE 150 160 GOSUB 110:IF X THEN 120 ELSE 160 170 GOSUB 110:IF X THEN GOSUB 120:PRINT CHR$(Y);:GOTO 170 180 Y$="":Y$=INKEY$:IF Y$=""THEN 170 190 IF Y$=T$ THEN Y$=DC3$ ELSE IF Y$=ESC$ THEN Y$=ETX$ 200 IF Y$<>E$ THEN Y=ASC(Y$):GOSUB 140:GOTO 170 210 INPUT "ENTER FILE NAME TO RECEIVE? ",F$:OPEN "R",1,F$ 220 FIELD 1,128 AS A$:Y=NAK:GOSUB 150:FOR I=1 TO 1E+06:PRINT I;CHR$(13); 230 C=0:GOSUB 160:IF Y=EOT THEN Y=ACK:GOSUB 150:CLOSE 1:PRINT CHR$(7):GOTO 170 240 GOSUB 160:J=Y:GOSUB 160:IF J+Y<>255 THEN C=13 250 FOR J=1 TO 128:GOSUB 160:MID$(B$,J,1)=CHR$(Y):C=C+Y:NEXT 260 GOSUB 160:C=(C AND 255):IF C<>Y THEN Y=NAK:GOSUB 150:GOTO 230 270 LSET A$=B$:PUT 1,I:Y=ACK:GOSUB 150:NEXT 280 MODEM=&H04:STATUS=&H06:RMASK=1:SMASK=4 290 B$=STRING$(128,0):ACK=6:NAK=21:E$=CHR$(5):WIDTH 255:EOT=4 300 ESC$=CHR$(27):ETX$=CHR$(3):DC3$=CHR$(19):T$="~":GOTO 170 -------------------- BMODEM.DOC THIS IS A VERY BASIC MODEM PROGRAM FOR THOSE WHO DON'T HAVE THE PATIENCE FOR DEALING WITH MBOOT3. THE ONLY LINE THAT NEEDS ALTERING IS 280 IN WHICH YOU PUT MODEM PORTS IN (HEX OR DEC) AND THE RECIEVE & SEND BIT MASKS. When you run the program it will act like a very dumb terminal Use it to log on and setup XMODEM to send you a better modem program or USQ. CTRL E asks you for the filename to be received. An ESC will transmit CTRL C to the remote machine. A tilde will transmit a CTRL S. To dial the Hayes modem enter ATDT Altered for the Xerox 820,820-II, and 16/8 on 12/07/84 -Arun Baheti [NBaheti.es@Xerox.Arpa] 22-Dec-84 17:22:02-MST,4141;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 22 Dec 84 17:21:48-MST Received: From xerox.arpa.ARPA by AMSAA via smtp; 22 Dec 84 18:42 EST Received: from Flora.ms by ArpaGateway.ms ; 22 DEC 84 15:40:14 PST From: NBaheti.es@XEROX.ARPA Date: 22 Dec 84 15:40:00 PST Subject: Mogur case To: Info-Cpm@AMSAA.ARPA cc: Arun Baheti The following text file was taken off of a local bulletin board. It looks as if Tom may be loosing some of his support. I am sorry if you have already seen the file... ----------------------------------- Southern California Sysops Pull the Plug on Tcimpidis by David Brown 10/19/84 The tide of public opinion seems to be turning against Southern California Bulletin Board operator Tom Tcimpidis, following revelation that the pilfered credit card number found on his system was that of Tcimpidis' former employer. Even though most regard John Dvorak a "Smug Twit," his discovery has prompted many Southern California Bulletin Board System operators -- some of whom shut down or altered their own systems in support of Tcimpidis' defense -- to change their minds about this matter. They find highly suspicious the coincidence that the number belonged to Tcimpidis' former employer. More incriminating, they say, is the fact that Tcimpidis never mentioned it to anyone in the local BBS community. Tcimpidis claims the number was placed on his board by a caller using an assumed name. He also claims he did not know the number in question belonged to a former employer. ...And we all thought Tom was a pretty smart guy. Dvorak, who says he employed the cunning investigative reporter's technique of ACTUALLY CALLING THE TELEPHONE NUMBER, revealed in a copyrighted article in the Sunday, Oct. 7, San Francisco Examiner that the credit card was owned by a television producer who once employed Tcimpidis. Now we all know that Dvorak was tipped to this by an attorney from the phone company. But I guess we've all got to try to preserve a little credibility, John. Although local Sysops had stuck up for Tcimpidis from the beginning, their dedication was at least in part based on a feeling that "any of us could be next." As one Sysop told me: "All some turkey has to do is stick a bogus credit card number on your system and you're up shit creek!" But operators now feel this latest revelation indicates that Pacific Bell's intentions in pressing the case against Tcimpidis are not an effort to intimidate local bulletin board operators. "This shows they're not going after Sysops," one operator said, "they're going after crooks!" But even before the recent discovery, local Sysops had confided to this writer that Tcimpidis was, at least, "very careless." One operator described Tcimpidis' system as the "Pimple Butt BBS." "There wasn't one worthwhile P.D. (Public Domain) program on that system," he said, "just a bunch of adolescents passing dirty notes...." In all fairness, I HAVE downloaded some worthwhile programs from his massive Heath system. But I also have seen plenty of inane ramblings from local Pimple-Poppers who have nothing better to do with their computers. By the way, Smug John, all agree with you that the ultimate solution to this problem is "a sincere effort at self-policing these boards by the people who run them." But you are DEAD WRONG when you say "Unfortunately, there has been NO real movement in that direction." Local Sysops would like to know why the hell YOU haven't talked with them? To sum up, Southern California Sysops are ready to pull the plug on their support of Tcimpidis and let the telephone company have its way with him. Hope he doesn't lose his mouse! -End- ----------------------------------- Arun Baheti NBaheti.es@Xerox.Arpa 23-Dec-84 02:03:25-MST,1155;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 23 Dec 84 02:03:19-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 23 Dec 84 3:40 EST Received: from usenet by BRL-TGR.ARPA id a015274; 23 Dec 84 3:40 EST From: greenber%acf4.uucp@BRL-TGR.ARPA Newsgroups: net.micro.cpm Subject: Re: RST 6 Message-ID: <10000019@acf4.UUCP> Date: 23 Dec 84 00:02:00 GMT Nf-ID: #R:Mit-Mc:-674500:acf4:10000019:000:598 Nf-From: acf4!greenber Dec 22 19:02:00 1984 To: info-cpm@AMSAA.ARPA <> While we have you on the line.....do you think that you could put the infamous "printf" problem in your documentation. Took me about two days to figure out what was going on (For those who don't know: BDS C can handle lines of only MAXLINE in length. Printf goes out to lunch, even with 'printf("%20.20s", string);' if string is longer than MAXLINE). For those who haven't experienced yet --- I'll bet you a dollar that you do. But you only experience it once!!! ------------------------------------------------------ Ross M. Greenberg @ NYU ----> allegra!cmcl2!acf4!greenber <---- 23-Dec-84 21:12:56-MST,791;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 23 Dec 84 21:12:52-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 23 Dec 84 22:44 EST Received: from usenet by BRL-TGR.ARPA id a024076; 23 Dec 84 22:44 EST From: Andrew Klossner Newsgroups: net.micro.cpm Subject: Re: .REL format Message-ID: <1266@orca.UUCP> Date: 23 Dec 84 10:03:55 GMT To: info-cpm@AMSAA.ARPA "Does there exist a document (underground or otherwise) which describes the internal form of .REL files?" Look in the MACRO-80 manual, in the chapter which describes the loader. -- Andrew Klossner (decvax!tektronix!orca!andrew) [UUCP] (orca!andrew.tektronix@csnet-relay) [ARPA] 24-Dec-84 11:07:45-MST,1095;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 24 Dec 84 11:07:28-MST Received: From lll-mfe.arpa.ARPA by AMSAA via smtp; 24 Dec 84 12:20 EST Date: Mon, 24 Dec 84 09:21 PST From: "Webb Mike"@LLL-MFE.ARPA Subject: ADDING A HARD DISK ? To: INFO-CPM@AMSAA.ARPA DOES ANYONE OUT THERE HAVE ANY EXPERIENCE ADDING A WINCHESTER INTERFACE TO A Z80 BASED CP/M 2.2 SYSTEM,WHICH DOSE NOT HAVE THE LOGIC TO TALK TO A WINCHESTER CONTROLLER. I HAVE HAD SEVERAL PEOPLE TELL ME ABOUT ADDING THE LOGIC TO A CPU WHICH INVOLVES 'PIGGY-BACKING' A BOARD BETWEEN THE Z80 CHIP AND IT'S SOCKET. THIS SOUNDS LIKE A NEAT IDEA,BUT IF IT WAS SO GREAT AN IDEA WHY AREN'T THERE A ZILLION GUY'S OUT THERE SELLING THIS BETTER MOUSE TRAP??? I WOULD LIKE TO HEAR FROM ANYONE WITH EXPERIENCE IN DOING THIS. IS IT COST EFFECTIVE (AM I GOING TO END UP BUYING ANOTHER COMPUTER ANYHOW),WHO BUILDS/ SELLS THE MODULE IF THERE IS ONE,ANY HORROR STORIES ETC. AS RECENTLY DISCUSED I WILL POST A SUMMARY IF THERE ARE ANY ANSWERS. MIKE WEBB WEBB@LLL-MFE.ARPA 25-Dec-84 00:11:46-MST,1294;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 25 Dec 84 00:11:41-MST Received: From mit-mc.arpa.ARPA by AMSAA via smtp; 25 Dec 84 1:42 EST Date: 25 December 1984 01:43-EST From: Jerry E. Pournelle Subject: Mogur case To: NBaheti.es@Xerox.ARPA cc: Info-Cpm@Amsaa.ARPA In-reply-to: Msg of 22 Dec 84 15:40:00 PST from NBaheti.es at XEROX.ARPA Not everyone has abandoned Tom; Peggy Watt continues to believe in him. It is unfortunate that the case is no longer so clean and clear cut as it was. If Tcimpidis did actually put that humber up, or knew it was there, then we're in a different ball game than if things are as he says. On the other hand, it isn't all that clear that Tcimpidas had any real motive to put the number up; and, after all, it's not beyond the bounds of credibility that some third party who knew the one knew the other; even that some other former or current employee posted the number. Is it at all possible that whoever did it MET Tcimpidas while Tcimpidas was employed with the number's owner? And so forth. I do wish it had stayed clean, thouhg. Query--did Dvorak REALLY get the info from the phone company? Do you KNOW this? I'd love to have proof of that... 25-Dec-84 00:12:11-MST,528;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 25 Dec 84 00:12:07-MST Received: From mit-mc.arpa.ARPA by AMSAA via smtp; 25 Dec 84 1:48 EST Date: 25 December 1984 01:49-EST From: Jerry E. Pournelle Subject: 128k/192k Applicards To: Boebert@Hi-Multics.ARPA cc: info-cpm@Amsaa.ARPA In-reply-to: Msg of Sat 22 Dec 84 09:32 CST from Boebert at HI-MULTICS.ARPA I can second Applicard as a good item; we've had one for years in thge kids' apple ][ 25-Dec-84 00:45:59-MST,558;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 25 Dec 84 00:45:56-MST Received: From mit-mc.arpa.ARPA by AMSAA via smtp; 25 Dec 84 2:24 EST Date: 25 December 1984 02:25-EST From: Jerry E. Pournelle Subject: Warning: RIPOFF from GDL To: greenber%acf4.uucp@Brl-Tgr.ARPA cc: info-cpm@Amsaa.ARPA In-reply-to: Msg of 20 Dec 84 15:26:00 GMT from greenber%acf4.uucp at BRL-TGR.ARPA uucp address? dinna ken uucp J E Pournelle BYTE 70 Main St Peterborough New hampshire 03458 25-Dec-84 12:45:41-MST,660;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 25 Dec 84 12:45:37-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 25 Dec 84 14:06 EST Received: from mit-mc.arpa by BRL-AOS.ARPA id a015648; 25 Dec 84 14:02 EST Date: 25 December 1984 14:01-EST From: "Michael C. Adler" Subject: cp/m+ incompatibility To: info-cpm@brl.ARPA I have heard that my spelling checker, SPELL, does not work on the Osborne Executive running CP/M+. Has anybody used SPELL successfully on CP/M+? SPELL makes heavy use of random file I/O. Is there any incompatibility there? Thanks, -Michael 25-Dec-84 15:23:31-MST,1116;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 25 Dec 84 15:23:26-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 25 Dec 84 16:59 EST Date: 25 Dec 1984 15:01 MST (Tue) Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: "Michael C. Adler" Cc: Info-Cpm@Amsaa.ARPA Subject: cp/m+ incompatibility In-reply-to: Msg of 25 Dec 1984 12:01-MST from Michael C. Adler The Osborne Executive destroys some of the Z80 alternate registers in the CBIOS. This could be the problem if your spelling checker program uses them and does not save the registers when calling BDOS or CBIOS. There is a fix for the Osborne Exec. users: Filename Type Bytes CRC Directory MICRO: TPATCH.LBR.1 COM 1664 9126H This is a program that patches the Osborne Exec. CBIOS so it preserves the Z80 alternate registers. It is run once when cold booting and remains thereafter until the next cold boot. --Keith 25-Dec-84 21:08:28-MST,1329;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 25 Dec 84 21:08:22-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 25 Dec 84 22:37 EST Received: from mit-mc.arpa by BRL-AOS.ARPA id a015962; 25 Dec 84 22:32 EST Date: 25 December 1984 22:31-EST From: "Robert L. Plouffe" Subject: Patches for MODM700 To: INFO-CPM@mit-mc.ARPA cc: PLOUFF@mit-mc.ARPA There is now a patch file at SIMTEL20 in the CPM.MODEM7 archive that allows patching of MODM700 for the following features: 1. Allow rubout to go to console and optionally eliminate the control character feature. 2. The UNDO-J option that restores terminal mode as the default at the calling end and command mode at the called end after completion of file transfers. Yhis is how Ward originally wrote it and the preferred mode by many. 3. Corrected error that caused the wrong file to be erased (in some instances) when overwiting files in batch mode. This patch was in PAT730Vx.ASM but did not make it into MODM700. 4. Allows for optional MAXWAIT times in the protocol to improve operation when operating with satellite communication links or with packet switched networks that can sometimes throttle and give excessive and variable packet delays. 26-Dec-84 07:02:19-MST,692;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 26 Dec 84 07:02:14-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 26 Dec 84 8:39 EST Date: 26 Dec 1984 06:40 MST (Wed) Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@Amsaa.ARPA Subject: Patches for MODM700 In-reply-to: Msg of 25 Dec 1984 20:31-MST from Robert L. Plouffe The patch file for MODM700 announced by Bob Plouffe is: Filename Type Bytes CRC Simtel20 directory MICRO: PAT700V1.ASM.1 ASCII 3292 9C76H --Keith 27-Dec-84 07:48:34-MST,6387;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 27 Dec 84 07:48:12-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 27 Dec 84 9:05 EST Date: Wednesday, 5 December 1984 16:27-MST Message-ID: Sender: Bruce Factor From: Bruce Factor Subject: 2400 baud modems ReSent-From: KPETERSEN@Simtel20.ARPA ReSent-To: Info-Cpm@Amsaa.ARPA, Info-Micro@Brl.ARPA ReSent-Date: Thu 27 Dec 1984 07:03-MST For those of you in the market to buy 2400 baud modems I want to inform you of a great deal. I would like to state that I am not affiliated with ANY of these companies, and I am not receiving and benefits by posting this information! After spending a few days pricing modems I have compiled the following information (saving the best for last). If anyone has any additional information I would greatly appreciate it. We were interested in rack mounting them so most of the prices given are for cards that would plug into a rack. "box" refers to a stand alone modem. DEC 1 - (800) 962 - 3244 now DF112-AM 300/1200 card $ 506 now DF126-AM 2400 only card $ 634 Racal Vadic 1 - (800) 482 - 3427 now VA212PAR 300/1200 card $ 445 3/85 VA4224 1200/2400 card $ 740 now VA1681 houses 16 rack $ not priced yet Concord Data Systems (617) 890 - 1394 Q10-24 now CDS224 AA/ORG 1200/2400 box/card$ 845 $ 825 now CDS224 Autodial 1200/2400 " $ 995 $ 975 now CDS224 ARQ 1200/2400 " $1295 now CDS224 ARQ Auto 1200/2400 " $1395 now CDS224 Super 1200/2400 " $1695 now CDSRM-07A houses 7 rack $ 750 Hayes 1 - (800) 241 - 6492 now Hayes1200 300/1200 box/card$ 499 2/85 Hayes2400 300/1200/2400 box/card$ none now 08-00056 houses 6 rack $ 766 Quantity Discounts are minimal. Micom 1 - (800) 527 - 0204 Q >16 now M3012 300/1200 box $ 495 now M3012 plus 300/1200 box $ 595 1/85 M3024 1200/2400 box $ 795 1/85 M3024 plus 1200/2400 box $ 895 $ 805 " " " card $ 845 $ 760 now M3200 houses 16 rack $ 750 General Datacomm (203) 574 - 1118 Q 10 - 19 now DC211AL 300/1200 box $ 675 $ 595 " " " card $ 585 $ 520 1/85 DC2412 1200/2400 box $1195 $1050 " " " card $1105 $ 790 " DS1 houses 16 rack $ 795 Paradyne 1 - (800) 482 - 3333 or 1 - (800) 342 - 3532 now DTU1200D 300/1200 $ now 1200/2400 $ 900 NEC 1 - (800) 538 - 8166 Q 11 -20 now N212BRL 300/1200 box $ 795 $ 669 " " " card $ 725 $ 606 " DSP2430 1200/2400 box $1095 $ 976 " " " card $ 965 $ 855 " N4083 houses 8 - 1200 rack $ 625 " SR0801 houses 8 - 2400 rack $ 900 QUADRAM (404) 923 - 6666 Q > 3 now QM10000 300/1200 $ 695 $ 625 not available ?/2400 $ NO Rack mounting. Ven-Tel 1 - (800) 538 - 5121 Will Call me back. 300/1200 $ ?/2400 $ Promethus (415) 490 - 2370 (check 800) Distributor: Will call me back. 300/1200 $ ?/2400 $ Fujitsu (408) 946 - 8777 ext 576 not available 300/1200 $ now F1935B 1200/2400 $ 895 ------------------------------- CTS Datacomm (203) 743 - 3681 Pete Coccaro Distributor: Professional Network Services Harvey Schlesinger (617) 449 - 6460 Model: CTS2424AD These people had by far the best deal. The list price for the Stand Alone (box) modem is $ 795 The list price for the (rack) mounted modem is ~$ 700. Besides starting off $ 200 less than everyone else their quantity discounts are very good. The Stand Alone modem will be available starting January, and their rack mount modem should be available February. Here is a Quantity discount price list. Quantity %dicount S.A. rack ======== ======== ==== ==== 1 list $795 $700 2-5 10 % 716 630 6-10 20 % 636 560 11-25 25 % 596 525 25- 30 % 556 490 For all of you usenet sites that are still running 1200 (or possibly even 300) the modems will pay for themselves very quickly. From all of the literature that I have recieved here are a few of the advantages of this modem above the others: 1) works at 300 or 1200 or 2400 asyn (others only 1200/2400) 1200 or 2400 sync 2) Stores 10 numbers (40 chars each) (others only 1) 3) For tone dialing it dials ALL 12 (others only can generate tones including (* and #) numbers 0-9) This last one caused a nasty problem when we needed to generate the extra tones because some of the sites we talk to have switching systems that require them (Gandalf). 4) Will automatically change the speed (some of the others needed to the other modem. a manual intervention). --------------- usenet: {philabs, allegra}!sbcs!bruce Bruce Factor 27-Dec-84 08:27:44-MST,570;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 27 Dec 84 08:27:40-MST Received: From mitre.arpa.ARPA by AMSAA via smtp; 27 Dec 84 9:58 EST Date: 27 Dec 1984 9:59:46 EST (Thursday) From: Jeffrey Edelheit Subject: Mailing Label program To: info-cpm@Amsaa.ARPA Cc: edelheit@Mitre.ARPA Does anyone know if there is a mailing label program written in BASIC that is kept in the SIMTEL20 archives? Any directory/file name pointers would be appreciated. Jeff Edelheit (edelheit@mitre) 27-Dec-84 18:01:33-MST,530;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 27 Dec 84 18:01:29-MST Received: From xerox.arpa.ARPA by AMSAA via smtp; 27 Dec 84 19:35 EST Received: from CheninBlanc.ms by ArpaGateway.ms ; 27 DEC 84 10:40:22 PST Date: Thu, 27 Dec 84 10:39 PST From: BILLHOLLAND.ES@XEROX.ARPA Subject: Re: Mattel Intellivoice info wanted In-reply-to: <2448@pur-ee.UUCP> To: Shields cc: info-cpm@AMSAA.ARPA PLEASE COPY ME IN ON ALL ANSWERS. BILL 27-Dec-84 19:14:33-MST,899;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 27 Dec 84 19:14:26-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 27 Dec 84 20:44 EST Date: 27 Dec 1984 18:39 MST (Thu) Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@Amsaa.ARPA Subject: RCPM-057.LQT list of all known RCPMs updated The latest list of all known RCPM (Remote CP/M) systems is now available from SIMTEL20. If you cannot FTP and you are not already on the list to automatically receive updates of RCPM-xx.LST, please send a note to me and I'll add you to the mailing list. Filename Type Bytes CRC Directory MICRO: RCPM-057.LQT.1 COM 36864 72DAH --Keith Usenet: ...decvax!brl-bmd!w8sdz or ...seismo!brl-tgr!w8sdz 27-Dec-84 22:15:12-MST,675;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 27 Dec 84 22:15:07-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 27 Dec 84 23:50 EST Received: from usenet by BRL-TGR.ARPA id a007323; 27 Dec 84 23:40 EST From: "David Herron, NPR Lover" Newsgroups: net.micro.cpm Subject: Re: Need a BREAK key. Message-ID: <425@ukma.UUCP> Date: 24 Dec 84 07:38:20 GMT To: info-cpm@AMSAA.ARPA You could do what the 4.2 tip program does. For break it lowers the baud rate to like 50 baud and sends characters out. Gauranteed to make framing errors on the receiver. And it works too. 28-Dec-84 10:11:40-MST,738;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 28 Dec 84 10:11:31-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 28 Dec 84 11:40 EST Date: 28 Dec 1984 07:55 MST (Fri) Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@Amsaa.ARPA Cc: Info-Modem7@SIMTEL20.ARPA Subject: PAT700V2.ASM revised patches for MODM700 PAT700V1.ASM patches for MODM700, previously announced, had some errors in patch addresses. A revised patch file is now available from Simtel20: Filename Type Bytes CRC Directory MICRO: PAT700V2.ASM.1 ASCII 3104 CFC6H --Keith 28-Dec-84 10:13:49-MST,1873;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 28 Dec 84 10:13:38-MST Received: From mit-mc.arpa.ARPA by AMSAA via smtp; 28 Dec 84 11:40 EST Date: 28 December 1984 11:42-EST From: Herb Lin Subject: report on macro-tech board (80286/z80) - of interest to 8085/8088 users To: info-cpm@Amsaa.ARPA cc: LIN@Mit-Mc.ARPA, PLUKEL@Mit-Mc.ARPA a report to netland about the Macrotech dual processor board, (with an 80286 (10 MHz) and a Z-80 (8 MHz) advertised as a "drop in replacement" for the Compupro dual processor board (8085/8088). It isn't. No doubt it does adequately with certain configurations, but with mine, it does not. The symptom of difficulty is that when I boot my system (a Compupro System 8/16 C) running MPM 8-16 (Gifford Computer Systems), the system does not boot properly (but only intermittently). It sometimes takes me a few pushes of the reset button to even start the system; then, sometimes, the system seems unable to find the right INIT files. Sometimes, it finds the files, but then branches off into some strange part of the code. It has never entirely failed to work, and these troubles seem to happen only when I am doing my boot. Once the system has booted properly, it appears to operate properly after that. The problem has been diagnosed as an interaction problem between the processor board and my hard disk controller board, a Morrow HDCA, that probably results from timing problems. Gifford has offered to refund in full the cost of the dual processor board; they have also suggested that I upgrade my hard disk controller to a COMPUPRO Disk 2 board. They have explicitly refused to develop a fix to my problem. Since I would really like Z-80 capability for my 8 bit processor, can anyone make suggestions to me? tnx. 28-Dec-84 10:19:09-MST,1617;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 28 Dec 84 10:18:58-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 28 Dec 84 11:41 EST Date: 28 Dec 1984 07:02 MST (Fri) Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: "Robert L. Plouffe" Cc: Info-Cpm@Amsaa.ARPA, Info-Modem7@SIMTEL20.ARPA Subject: PAT700V1.ASM bugs? In-reply-to: Msg of 27 Dec 1984 23:16-MST from Robert L. Plouffe Date: Thursday, 27 December 1984 23:16-MST From: Robert L. Plouffe To: KPETERSEN at SIMTEL20 Re: PAT700V1.ASM bugs? Thanks for checking out that patch file. Indeed, the copy of MODM700 that I had (dated as of 11/04/84 - same date as current file) was different and was off by 5 bytes in a number of locations. I have fixed up the file and it should be now correct as PAT700V2.ASM. It will be in GUEST1 at MC as usual. This one contains the correct addresses to match the MODM700 at SIMTEL20. I thought that we were done with different releases under the same release number. There have been no changes to MODM700.AQM or MODM700.LBR since its release on November 4, 1984. Where did you get your copy? The one on Simtel20 hasn't been touched, according to WDIR's display of the creation date. Filename Type Bytes CRC Directory MICRO: MODM700.AQM.1 COM 104320 8B0AH MODM700.LBR.1 COM 71936 0477H --Keith 28-Dec-84 10:55:56-MST,1676;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 28 Dec 84 10:55:49-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 28 Dec 84 11:54 EST Received: from usenet by BRL-TGR.ARPA id a002312; 28 Dec 84 11:48 EST From: Jim Gutman Newsgroups: net.micro.cpm Subject: Kaypro DSDD Message-ID: <1003@opus.UUCP> Date: 27 Dec 84 19:33:03 GMT To: info-cpm@AMSAA.ARPA Hi. I've got a *new* Kaypro II. The one with double density single sided drives. Well, it turns out that Kaypro goofed and provided me with double sided drives. Great! But, without a double sided rom (format program also), the drives can only be used as single sided. Does anyone out there know of the patches that need to be made to the BIOS and format to allow double sided? Or, does anyone out there know of a place to buy a rom, at a reasonable price? Please keep in mind that this is a *new* verison Kaypro. It has the same motherboard as the Kaypro 10's. I know that there are roms available to convert to double sided for the older Kaypro's. Can anyone help??? I hate to either disassemble the BIOS and format program or not use double sided. Thanks in advance, Jim. -- The more I live, Jim Gutman the more I learn. NBI, Inc Boulder, CO The more I learn, the more I realize, (303) 444-5710 the less I know. Path ---> (ucbvax,allegra,hao)!nbires!jim :) 28-Dec-84 12:07:35-MST,1109;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 28 Dec 84 12:07:16-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 28 Dec 84 13:34 EST Received: from usenet by BRL-TGR.ARPA id a005255; 28 Dec 84 13:18 EST From: "Mark A. Ryding" Newsgroups: net.micro.cpm Subject: BIOS Source Wanted Message-ID: <1203@trwrba.UUCP> Date: 28 Dec 84 04:17:07 GMT To: info-cpm@AMSAA.ARPA I am looking for the source for the BIOS for a Vector Graphic Vector 3 micro. I have been trying to use RAID (a debugger of course) to dis-assemble the one I've got, but there are alot of things that I don't understand going on. Any help, hints, leads, tips, suggestions, or copies will be greatly appreciated. I will even pay for a copy, but donations are much cheaper. E-mail: ..!trwrb!trwrba!ryding or U. S. Snail-mail: Mark Ryding 4515 Harrison Blvd #23 Ogden, UT 84403 'I don't mind not knowing the answers, but do they have to keep changing the questions?' 28-Dec-84 13:24:17-MST,3808;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 28 Dec 84 13:24:03-MST Received: From brl-gateway2.ARPA by AMSAA via smtp; 28 Dec 84 14:35 EST Received: from mit-mc.arpa by BRL-AOS.ARPA id a006118; 28 Dec 84 8:23 EST Date: 28 December 1984 08:21-EST From: "Robert L. Plouffe" Subject: modm700 patches To: INFO-CPM@mit-mc.ARPA The following corrected file replaces the one announced previously. It will be in SIMTEL20 at micro:. DO NOT USE THE ONE PREVIOUSLY ANNOUNCED. THE ADDRESSES WERE OFF BY 5 BYTES IN SEVERAL PLACES BECAUSE I HAD AN EARLY COPY OF MODM700 THAT DID NOT MATCH THE ONE AT SIMTEL20. ; PAT700V2.ASM ;These patches should be made to MODM700 to obtain the results ;described. They were previously described as patches to MDM730 ;in the file PAT730V8.ASM and were not done in the source code ;for MODM700. It appears that all of the other patches in PAT730 ;were included properly. The object code addresses may have changed ;from MDM730 to MODM700 so use those given below only for MODM700. ; .... Bob Plouffe 12/28/84 TRUE EQU 0FFH FALSE EQU 0 MAXWAIT EQU 16 ;USE AT LEAST A '5' HERE. RUB EQU 7FH TERM EQU 1618H MENU EQU 32EDH RUBCON EQU TRUE ;want rubout to go to console? UNDO$J EQU TRUE ;set to TRUE to restore the 'T' ;option so that remote end doesn't ;automatically come up in terminal ;mode at the end of a file transfer ;************************************************************* ; ;This restores the feature that allows the RUBOUT character to ;go to the console if you desire it. Code was added in MDM730 ;that prevented rubout being sent to console in terminal mode. ; ;In the routine TERML ORG 1F0FH IF RUBCON DB 0,0,0,0,0 ;deletes rubout filter ENDIF IF NOT RUBCON CPI RUB JZ TERM ENDIF ;*********************************************************** ;THIS ONE CONTRIBUTED ANONYMOUSLY AS undo-j.asm AND INCLUDED ;HERE AS AN ADDITIONAL OPTION. ;To undo the 'J' option and restore the 'T' option as it has ;always been. Set UNDO$J to TRUE to enjoy this option. Irv ;never did change the help screens to describe his 'J' option ;anyhow. The 'T' option is still the one described there. ;The following code is in the DONETC routine: ORG 2AFBH IF UNDO$J JNZ MENU ENDIF ; IF NOT UNDO$J JZ MENU ENDIF ; and at the following storage locations near the end of the file. ORG 4952H IF UNDO$J DB 'T' ENDIF ; IF NOT UNDO$J DB 'J' ENDIF ORG 495FH IF UNDO$J DB 'T' ENDIF ; IF NOT UNDO$J DB 'J' ENDIF ; ;******************************************************************* ;This patch fixes a bug found by Ron Fowler that causes the wrong ;file to be erased in the directory when overwriting existing files ;in batch mode. ;..in the routine at CKCPM2: ORG 2238H NOP ;These 2 bytes replace 'CPI 0FFH' INR A ;******************************************************************* ;This patch makes the program MUCH more tolerant of network or ;transmission delays such as found in packet switched nets (ARPANET) ;as well as on satellite communication links. Do not use a value for ;MAXWAIT less than 5 (5 seconds) and even as high as 16 seconds is ok ;which will then tolerate some of the large throttling delays often ;encountered. ORG 1B8FH MVI B,MAXWAIT ORG 1BF3H MVI B,MAXWAIT ORG 1C0CH MVI B,MAXWAIT ORG 1CA0H MVI B,MAXWAIT ORG 1D03H MVI B,MAXWAIT ORG 240AH MVI B,MAXWAIT ORG 2413H MVI B,MAXWAIT ORG 245EH MVI B,MAXWAIT ORG 2477H MVI B,MAXWAIT ORG 2496H MVI B,MAXWAIT ;******************************************************************* ;the END 29-Dec-84 04:42:57-MST,976;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 29 Dec 84 04:42:52-MST Received: From cmu-cs-c.arpa.ARPA by AMSAA via smtp; 29 Dec 84 6:16 EST Received: ID ; Sat 29 Dec 84 06:17:09-EST Date: Sat 29 Dec 84 06:17:01-EST From: Penny Anderson Subject: Problem with ZCPR3 MENU.COM To: Rconn@SIMTEL20.ARPA cc: info-cpm@AMSAA.ARPA, apa@CMU-CS-C.ARPA Rick, I'm using version 3.2 of MENU.COM and running into a glitch that might be nasty for those trying to run a secure ZCPR3 with menus: on a menu with the 'exit to CP/M' option disabled, a control-C followed by a CR moves on to the next menu, even if a system menu ($) follows the current menu. I've heard a rumor that there is a new version of MENU.COM and .MAC. Do the fixes address this problem? Is this a real problem, can anyone else duplicate it? Don Shields c/o APA@CMU-C ------- 29-Dec-84 06:34:40-MST,1352;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 29 Dec 84 06:34:35-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 29 Dec 84 8:11 EST Received: from usenet by BRL-TGR.ARPA id a017417; 29 Dec 84 7:54 EST From: "M.GALE" Newsgroups: net.micro.cpm Subject: Re: 2400 baud modems Message-ID: <809@ariel.UUCP> Date: 28 Dec 84 14:20:51 GMT To: info-cpm@AMSAA.ARPA Please note at the beginning that this is coming from an account on an AT&T computer. Just wanted to point out that in the recent summeries of modems available people seem to be missing a major manufacturer of modems -- A T & T. Check it out with an A T & T - I S sales rep. They've got 1200/2400 standalone and rackmount systems. And you don't call it the Bell 212 standard for nothing. Please note that I do not work in that department and know only the basics concerning such hardware i.e. it exists. I am not an employee nor an authorized representative of any part of AT&T, I only help solve problems for them on a contract basis. To think that my opinions are those of the company is ludicrous. Michael D. Gale "I just like blinking lights-the DECsystem 10 operator's panel is a work of art" blink-blink-blink-burnout-blink 29-Dec-84 12:30:04-MST,1244;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 29 Dec 84 12:29:59-MST Received: From brl.arpa.ARPA by AMSAA via smtp; 29 Dec 84 14:05 EST Received: from simtel20.arpa by BRL-AOS.ARPA id a003060; 29 Dec 84 13:59 EST Date: 29 Dec 1984 11:58 MST (Sat) Message-ID: From: CSTROM@SIMTEL20.ARPA To: Herb Lin CC: Info-CPM@brl.ARPA, CSTROM@simtel20.ARPA, PLUKEL@mit-mc.ARPA Subject: report on macro-tech board (80286/z80) - of interest to 8085/8088 users In-reply-to: Msg of 28 Dec 1984 09:42-MST from Herb Lin Have you spoken to the people at Macrotech? It is possible that the hard disk controller you have is incompatible because of timing problems, but I cannot say for sure. I don't recall hearing of the MI-286 operating with the Morrow controller, but it does indeed operate with the Konan and CompuPro controllers. The technical suppoert people at Macrotech are _very_ cooperative and will go out of their way to try to assist you. The MI-286 board buys much more than 8-bit Z80 operation - the speed improvement over the 8085/88 board is impressive. Don't give up just yet! -Charlie 30-Dec-84 11:50:20-MST,757;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 30 Dec 84 11:50:15-MST Received: From brl.arpa.ARPA by AMSAA via smtp; 30 Dec 84 12:41 EST Received: from mit-mc.arpa by BRL-AOS.ARPA id a000152; 30 Dec 84 12:41 EST Date: 30 December 1984 04:54-EST From: "Jerry E. Pournelle" Subject: report on macro-tech board (80286/z80) - of interest to 8085/8088 users To: CSTROM@simtel20.ARPA cc: LIN@mit-mc.ARPA, PLUKEL@mit-mc.ARPA, Info-CPM@brl.ARPA In-reply-to: Msg of 29 Dec 1984 11:58 MST (Sat) from CSTROM at SIMTEL20.ARPA see my report on Macrotech board in January BYTE. It is a very good board. Now all I need is a BIOS that lets me use my memory-map video with it. JEP 30-Dec-84 11:51:32-MST,1626;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 30 Dec 84 11:51:27-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 30 Dec 84 12:45 EST Received: from usenet by BRL-TGR.ARPA id a001580; 30 Dec 84 12:00 EST From: jwc%ucla-cs.uucp@BRL-TGR.ARPA Newsgroups: net.micro.cpm Subject: Re: Apple & Applicard with ram extenders Message-ID: <2978@ucla-cs.ARPA> Date: 28 Dec 84 08:43:27 GMT To: info-cpm@AMSAA.ARPA ------------------------------------------- [Re: inquiry by Bob@zeppo & reply from Boebert@HI-Multics.] It may not be widely known that two extenders can be piggybacked for up to 256K extra ram or a 223K ramdisk under PCPI version 2 software (version 2 has a number of enhancements and improved documentation); the ramdisk can be declared to be drive A and files can be automatically pipped to it on bootup, giving convenience in startups and very impressive speed when overlays are in the ramdisk -- at 6 MHz, applications like Wordstar or Dbase II zip along with instant screen updates from the user viewpoint. With two extenders, the Applicard is thick at the Apple keyboard end, but can be installed in slot 7 to get it out of the way of other long cards. I have this setup in an Apple //e and am pleased with it; I agree with the comment that telephone support from PCPI is good. Question: Does anyone else with a two-extender setup have any comment regarding heat generation in the closely-spaced ram board areas? I have not had problems so far in this respect myself, but that region obviously does warm itself up. 30-Dec-84 11:52:52-MST,683;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 30 Dec 84 11:52:49-MST Received: From brl-tgr.arpa.ARPA by AMSAA via smtp; 30 Dec 84 12:45 EST Received: from usenet by BRL-TGR.ARPA id a001614; 30 Dec 84 12:01 EST From: Art Zemon Newsgroups: net.micro.cpm Subject: Re: Kaypro floppy format? Message-ID: <1376@fritz.UUCP> Date: 28 Dec 84 16:09:30 GMT To: info-cpm@AMSAA.ARPA I like to see the "boring" details of such technical discussions. If I find it truly boring, I can always use "n". -- -- Art Zemon FileNet Corp. ...! {decvax, ihnp4, ucbvax} !trwrb!felix!zemon 30-Dec-84 12:23:25-MST,761;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 30 Dec 84 12:23:22-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 30 Dec 84 14:02 EST Date: Sun 30 Dec 84 12:03:46-MST From: Rick Conn Subject: Re: Problem with ZCPR3 MENU.COM To: Penny.Anderson@CMU-CS-C.ARPA cc: info-cpm@AMSAA.ARPA, apa@CMU-CS-C.ARPA, RCONN@SIMTEL20.ARPA In-Reply-To: Message from "Penny Anderson " of Sat 29 Dec 84 04:17:31-MST Don, The ^C problem has been addressed, and to my knowledge solved. The current version of MENU is 3.5 (several versions from the old 3.2), and you may want to look into getting a copy to see if your problem goes away. Rick ------- 30-Dec-84 12:42:23-MST,470;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 30 Dec 84 12:42:20-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 30 Dec 84 14:13 EST Date: Sun 30 Dec 84 12:15:44-MST From: Rick Conn Subject: ZCPR3 Newsletter 102 ... To: info-cpm@AMSAA.ARPA ... is now in MICRO: as Z3NEWS.102. Lots of tidbits of info there about ZRDOS, new versions of tools, etc. Rick ------- 30-Dec-84 14:12:15-MST,1386;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 30 Dec 84 14:12:10-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 30 Dec 84 15:45 EST Date: 30 Dec 1984 13:47 MST (Sun) Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@Amsaa.ARPA Subject: BU - hard disk backup utility BU, a new hard disk backup utility, is now available from SIMTEL20: Filename Type Bytes CRC Directory MICRO: BU.LBR.1 COM 36992 7E8AH Here's the author's message about it: Date: 12/09/84 From: Kim Levitt To: All Re: BU.LBR BU is a new "Backup Utility" program that will allow hard disk owners to quickly back up their system onto floppies. It was originally based on BAK25KP, but has been almost completely re-written. It is not hardware specific (except for the clear screen sequence, but that is easily patched without reassembly) and is set up to copy files in disk/user/alphabetical order and so works nicely on ZCPR/ZCPR2/ZCPR3 systems, but will work on a normal CP/M 2.2 system as well. Not sure it will work under 3.0 as it chases the DPH/DPB blocks to determine disk capacity/blocking size/etc. May not work under CP/M v1.4 either, but should work fine on all CP/M v2.2 systems. 30-Dec-84 21:38:13-MST,1358;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 30 Dec 84 21:38:08-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 30 Dec 84 23:04 EST Date: 30 Dec 1984 21:06 MST (Sun) Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@Amsaa.ARPA Subject: FBAD58 latest version of bad sector lockout program The latest version of FINDBAD, the program which does a non-destructive read of a disk and then creates a dummy file to allocate bad sectors so CP/M won't use them, is now available from SIMTEL20: Filename Type Bytes CRC Directory MICRO: FBAD58.AQM.1 COM 25216 F3D9H FBAD58.COM.1 COM 2176 D033H Here's the update author's comments on what's new in this version: ...Added the ability to keep bad blocks that were flagged in a previous [UNUSED].BAD file. If a block was ever flagged as bad by this program, it is probably weak. If on a subsequent test, it makes it through the BIOS retries and is read successfully, I want the block to stay in the UNUSED.BAD file. Removed the code in LTOP which cleared the high byte of HL after a call to SECTRN. My BIOS (Morrow DJDMA) sets the high bit of HL to indicate SIDE 1 of a double sided drive. --Keith 31-Dec-84 08:55:47-MST,1328;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 31 Dec 84 08:55:39-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 31 Dec 84 10:20 EST Date: 31 Dec 1984 08:21 MST (Mon) Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@Amsaa.ARPA Subject: Warning - VDIR bomb Relayed from the RCPM Sysop Clearinghouse: Msg 128 on 12/28/84 from KEN STRITZEL to ALL about VERDIR.LBR BOMB The program VDIR.COM that is being distributed in VERDIR.LBR is a real time bomb. Although the DOC file says that this program produces a vertical directory listing. When run, the program destroys all data on the system and directory tracks and fills them with garbage. Then it prints a vulgar message to the effect that "you have just been had!" Anyone that has this file on their system should erase it! I can not imagine the mentality behind this program, but it should not be allowed to damage any RCPM or innocent user who happens to download it. Another case for NOT distributing .COM files without the source code. Thanks to Robert Blacher, sysop of the Computer Connection, Washington DC, who brought this bomb to my attention. Flanders, NJ RCPM, 201+584-9227 31-Dec-84 13:19:01-MST,776;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 31 Dec 84 13:18:48-MST Received: From brl.arpa.ARPA by AMSAA via smtp; 31 Dec 84 14:57 EST Received: from mit-mc.arpa by BRL-AOS.ARPA id a003613; 31 Dec 84 14:57 EST Received: from tennessee by csnet-relay.csnet id a007194; 31 Dec 84 14:54 EST Date: Mon, 31 Dec 84 08:57 EST From: Phil Geraci To: info-cpm@MIT-MC.ARPA Has anyone tried the Z-80 macro assembler by Mitek? I saw it advertized in the January 1985 Dr. Dobbs Journal. I'd be interested in any comments about it. As I am not on the CP/M distribution list, I'd appreciate having any comments sent to me directly. Thanks in advance, Phil Geraci 31-Dec-84 20:39:35-MST,739;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 31 Dec 84 20:39:31-MST Received: From brl.arpa.ARPA by AMSAA via smtp; 31 Dec 84 22:12 EST Received: from wisc-rsch.arpa by BRL-AOS.ARPA id a004187; 31 Dec 84 22:09 EST Date: Mon, 31 Dec 84 21:07:58 cst From: David Neves Message-Id: <8501010307.AA24558@wisc-rsch.arpa> Received: by wisc-rsch.arpa; Mon, 31 Dec 84 21:07:58 cst To: info-cpm@brl.ARPA Subject: CPM to UCSD pascal transfer Help. I need a CPM to UCSD file transfer program. I have one that was published in Dr. Dobbs in 1980 but the copy I have is garbled in the middle. I think I got it at SIMTEL20 but I can't find it now. -Thanks, David 31-Dec-84 21:26:01-MST,993;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 31 Dec 84 21:25:53-MST Received: From simtel20.arpa.ARPA by AMSAA via smtp; 31 Dec 84 22:56 EST Date: 31 Dec 1984 20:58 MST (Mon) Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: David Neves Cc: Info-Cpm@Amsaa.ARPA Subject: CPM to UCSD pascal transfer In-reply-to: Msg of 31 Dec 1984 20:07-MST from David Neves Help. I need a CPM to UCSD file transfer program. I have one that was published in Dr. Dobbs in 1980 but the copy I have is garbled in the middle. I think I got it at SIMTEL20 but I can't find it now. -Thanks, David There are two available from Simtel20: Filename Type Bytes CRC Directory MICRO: PAS2CPM.ASM.2 ASCII 7500 50C6H PASTOCPM.ASM.2 ASCII 11660 D8DEH --Keith