1-Aug-85 07:03:07-MDT,1208;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 1 Aug 85 07:02:34-MDT Received: from merlin.purdue.edu by AMSAA.ARPA id a002754; 31 Jul 85 11:32 EDT Message-Id: <8507310215.AA13532@merlin.ARPA> Received: by merlin.ARPA; Tue, 30 Jul 85 21:15:19 EST To: Walt Sakai Cc: info-cpm@AMSAA.ARPA Subject: Re: ** Ramdisk Information ** In-Reply-To: Your message of 26 Jul 85 03:31:53 GMT. <164@proper.UUCP> Date: 30 Jul 85 21:15:15 EST (Tue) From: Ralph E Droms Micro-Cornucopia magazine recently reviewed a number of Z80 SBC memory expansion boards. Micro-C no. 22 (February-March, 1985) includes reviews of a 256K RAM Expansion Module from Ferguson Engineering, and the Rivendell Audiocomp 256K Ram + I/O expansion board. Issue no. 23 (April-May, 1985) has a short review of the MicroSphere 256K RAMdisk. Issue no. 9 (Dec. 1982) reviews the LASoftware 256K RAMDisk kit. - Ralph ------------------------- Ralph Droms ihnp4!purdue!droms 445 MATH droms@purdue.arpa Dept. of Computer Science droms@purdue.csnet Purdue University West Lafayette, IN 47907 ---------- 1-Aug-85 07:38:30-MDT,2449;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 1 Aug 85 07:37:57-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id aa04140; 31 Jul 85 12:27 EDT Received: from usenet by TGR.BRL.ARPA id a013753; 31 Jul 85 7:41 EDT From: The Polymath Newsgroups: net.micro.cpm Subject: Re: ** Ramdisk Information ** Message-ID: <610@ttidcc.UUCP> Date: 31 Jul 85 01:44:37 GMT To: info-cpm@AMSAA.ARPA In article <164@proper.UUCP> walt_sak@proper.UUCP (walt_sak) writes: > >I would like to invite comment on the RAMDISKS used in >conjunction with CP/M systems. Please discuss the advantages >and bugs you have found for your system. Currently I am >interested in using MICROSHERE's Ramdisk with a Kaypro 4-84. I'm currently using the 360K version of Westwind's Drive C on my Osborne 1. It works as advertised and enormously speeds up any program that does overlay swapping from disk (Wordstar is vastly improved). It also comes with a version of Supercalc 2 that uses the RAMDisk for virtual core, allowing truly enormous spreadsheets. I haven't had time to test this yet. I haven't encountered any bugs as yet, nor heard of any from anyone else. It does take about a minute to load from floppies when booting, but all's clear sailing from there. The drive includes software that allows it to act as a print buffer and RAMDisk simultaneously. >Is the cost of the ramdisk worthy of the increased speed in >program execution? Does the ramdisk make working with very >large dBase II files faster? What are typical time savings >(relative to processor speed)? Drive C costs about $650 in the 360K version. I thought it was worth it, others may not. I haven't tried it with dBase II yet, but did use dBase II with a RAMDisk on an IBM PC. It makes an enormous difference in speed (at least 10x) over floppy disk operation. On the other hand, no difference was detectable over hard disk operation. -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ The Polymath (aka: Jerry Hollombe) Citicorp TTI Common Sense is what tells you that a ten 3100 Ocean Park Blvd. pound weight falls ten times as fast as a Santa Monica, CA 90405 one pound weight. (213) 450-9111, ext. 2483 {philabs,randvax,trwrb,vortex}!ttidca!ttidcc!hollombe 1-Aug-85 07:43:39-MDT,1616;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 1 Aug 85 07:41:15-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a004140; 31 Jul 85 12:28 EDT Received: from usenet by TGR.BRL.ARPA id a013759; 31 Jul 85 7:41 EDT From: The Polymath Newsgroups: net.micro.cpm Subject: Re: DBASE II Message-ID: <611@ttidcc.UUCP> Date: 31 Jul 85 01:50:08 GMT To: info-cpm@AMSAA.ARPA In article <248@brl-tgr.ARPA> D-ROGERS@EDWARDS-2060.ARPA writes: >I AM SOMEWHAT NEW AT THIS. DOES ANYONE KNOW IF THERE IS ANY SUCH THING AS >AS COMPILER FOR DBASE II? IT HAS OCCURRED TO ME THAT THE DAY MAY COME >WHEN I DON'T WANT TO GIVE AWAY THE SOURCES WITH A PROGRAM. AT LEAST MBASIC >PROGRAMS COULD BE PROTECTED AGAINST LISTING. Last I heard there was no dBase II compiler, but there was a version available from Ashton-Tate specifically for people in your position. It's a subset of dBase II that allows your command files to be run, but doesn't give the user access to the dBase command level. I'm not sure if the source is accessible from other text editors with this version. I expect A-T will be happy to tell you about it (and sell you a license). -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ The Polymath (aka: Jerry Hollombe) Citicorp TTI Common Sense is what tells you that a ten 3100 Ocean Park Blvd. pound weight falls ten times as fast as a Santa Monica, CA 90405 one pound weight. (213) 450-9111, ext. 2483 {philabs,randvax,trwrb,vortex}!ttidca!ttidcc!hollombe 1-Aug-85 08:15:39-MDT,2322;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 1 Aug 85 08:12:42-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a004156; 31 Jul 85 12:28 EDT Received: from usenet by TGR.BRL.ARPA id a015738; 31 Jul 85 8:44 EDT From: John Blalock Newsgroups: net.micro,net.micro.cpm Subject: New Real Time Clock/Calendar Chip Message-ID: <651@terak.UUCP> Date: 30 Jul 85 17:23:57 GMT Xref: seismo net.micro:11875 net.micro.cpm:4723 To: info-cpm@AMSAA.ARPA ------- Adding a Real Time Clock to a micro can be somewhat of a hassle, to say the least. The OKI 5832 is best interfaced thru a PIA, the National 58174 and 58274 chips have faster access times but still require wait states. OKI, however, has recently introduced a new RTC chip, the MSM6242RS, that is designed to be directly interfaced to the sytem bus of Z80, 8080, 8085, 8086/8, 6800, 6502, etc. processors without the need for wait states. It has several neat features such as <30 microamps current draw (<10 microamps in standby mode), +/- 30 seconds adjust, automatic leap year correction, 12/24 hour modes, and year/month/day/day of week in addition to hours/min/sec. I have one running on my 4 MHz Z80 system now - extremely easy to interface! The only problems were in setting the 12/24 hour mode correctly and sometimes BUSY would never go low after once setting HOLD high. Here are the fixes: To read the clock registers, you set the HOLD bit and wait for BUSY to go low. If it does't go low within 190 usec, reset HOLD and try again. (You'll fail on the first try only once per 36000 tries.) The data sheet is not too clear on how to set the 12/24 hour modes. To set 12-hour mode, output 01H, then 00H to Ctl Reg F. To set 24-hour mode, output 05H, then 04H to Ctl Reg F. If you need a RTC, check this one out. I have no connection with OKI Semiconductor, just a satisfied user of a good part that I hadn't heard about until 4 days ago. They should do a better job of letting the world know about the 6242. John Blalock, W7AAY uucp: ...{amd,decvax,hao,ihnp4,seismo}!noao!terak!jb phone: (602) 998-4800 us mail: CalComp, 14151 N. 76th St., Scottsdale, AZ 85260 \\\\\\\ -------> Formerly Terak Corporation 1-Aug-85 08:20:34-MDT,967;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 1 Aug 85 08:15:48-MDT Received: from usc-isi.arpa by AMSAA.ARPA id a005573; 31 Jul 85 13:18 EDT Date: 31 Jul 1985 13:13:55 EDT Subject: Adaptive dialing with the ProModem 1200 From: Steve Noland To: IMFO-CPM@AMSAA.ARPA, INFO-CPM@AMSAA.ARPA cc: INFO-MODEM7@SIMTEL20.ARPA I recently tried using the adaptive dialing mode of my ProModem where it is possible to determine if tone or pulse is necessary. I have a tone line (on GTE, sigh...), and the call appeared to make the central office think I was trying to make a "0" prefixed call, such as credit card or whatever. The funny "bong" tone appeared followed shortly by a baffled operator. Has anyone else had similar experiences, or can someone offer advice on how to use the ProModem in this mode. Normal tone dialing works fine. Thanks in advance, Steve Noland ------- 1-Aug-85 08:46:07-MDT,443;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 1 Aug 85 08:45:47-MDT Received: from mitre-gateway.arpa by AMSAA.ARPA id a003423; 1 Aug 85 8:10 EDT Date: 31 Jul 1985 16:14:46 EDT (Wednesday) From: Tom Reid (MS W932) Subject: TKERMIT To: abn.iscams@usc-isid.ARPA Cc: info-cpm@AMSAA.ARPA TKERMIT.LBR is on simtel20 in directory micro:. tom. 1-Aug-85 09:27:51-MDT,1006;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 1 Aug 85 09:24:01-MDT Received: from xerox.arpa by AMSAA.ARPA id a004757; 1 Aug 85 8:33 EDT Received: from Salvador.ms by ArpaGateway.ms ; 31 JUL 85 12:09:45 PDT Sender: "Philip M. Burton.osbunorth"@XEROX.ARPA Date: 31 Jul 85 12:04:22 PDT (Wednesday) Subject: Re: using both side of disks From: Burton.osbunorth@XEROX.ARPA To: ABN.ISCAMS@USC-ISID.ARPA cc: Burton.osbunorth@XEROX.ARPA, king%dciem.uucp@BRL.ARPA, info-cpm@AMSAA.ARPA In-Reply-to: ABN.ISCAMS%USC-ISID:ARPA:Xerox's message of 30-Jul-85 23:44:32 Message-ID: <850731-120945-4863@Xerox> Dave, I use an ordinary hole-punch to punch out the extra index holes. I use the jacket of a bad disk as a template. As a caution, the hole-punch could be magnetized, so disks should be formatted after this treatment. Use flippies only for archival disks, not work disks in a floppy-only system. Phil Burton burton.osbunorth@xerox 1-Aug-85 10:26:15-MDT,1293;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 1 Aug 85 10:25:47-MDT Received: from ames-vmsb.arpa by AMSAA.ARPA id a012259; 1 Aug 85 11:20 EDT Date: 1 Aug 85 08:13:00 PDT From: nep.pgelhausen@AMES-VMSB.ARPA Subject: --- Apple to IBM --- To: info-cpm@AMSAA.ARPA Reply-To: nep.pgelhausen@AMES-VMSB.ARPA Sorry, as far as I know, Apple runs CP/M-80 (for a Z80, the eight-bit "original" CP/M). IBM runs CP/M-86, the sixteen-bit version. I know that CP/M was intended to create a "standard" such that the same program will run on many different machines. The catch is that CP/M-80 and CP/M-86 are two DIFFERENT operating systems (only the names (and the user interface) appear similar). To get the same program to run on two machines w/ direct transfer they both have to have the same CPU (both the Osborne and the Kaypro have a Z80 (I think) and run the eight-bit CP/M). If you have the source code for whatever program you want to transfer, in a high-level language, you can re-compile on the IBM. NOTE: Z80 assembler code is NOT suitable for compilation on the IBM. You need a language like C, Pascal, FORTRAN, or even BASIC. Does this answer your question? -Richard Hartman max.hartman@ames-vmsb ------ 2-Aug-85 07:03:09-MDT,755;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 2 Aug 85 06:58:45-MDT Received: from usc-isi.arpa by AMSAA.ARPA id a027803; 2 Aug 85 8:26 EDT Date: 1 Aug 1985 16:53:15 EDT Subject: M80 Symbol Table expander From: Steve Noland To: INFO-CPM@AMSAA.ARPA I recently ran across a program that purported to take a standard M80 symbol table (that normally contains only external references) and modify it to contain internal tags. This would be a great boon to SID/ZSID debugging. Unfortunately, I can't remember where I saw it. If anyone out there has access to it or knows were it can be found, I would appreciate the info. Thanks in advance, Steve Noland ------- 5-Aug-85 05:55:35-MDT,1182;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 5 Aug 85 05:50:41-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a018892; 5 Aug 85 7:15 EDT Received: from usenet by TGR.BRL.ARPA id a011409; 2 Aug 85 20:47 EDT From: Alan Rovner Newsgroups: net.micro.cpm Subject: Response to David Kirschbaum/USR Modems Message-ID: <541@tekigm.UUCP> Date: 1 Aug 85 22:57:10 GMT To: info-cpm@AMSAA.ARPA David, I think your problems are due to poor analog design/phone line interface in your modem. I went through two USR Passport modems and had all sorts of garbage characters, random phone line hang up, etc. At first I thought I had a bad modem, so I exchanged it for another Passport. It acted the same way. It was then I concluded the design of the modem did not meet my standards so I traded it in on a Rixon R212A. Calling the same BBS's I did with the Passport over the same phone line I now have no problems at all with bad characters, etc. While USR modems work well from the microprocessor side, their phone line interface is poor. Regards, Al Rovner Tektronix, Vancouver, WA 5-Aug-85 05:55:39-MDT,2076;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 5 Aug 85 05:54:01-MDT Received: from simtel20.arpa by AMSAA.ARPA id a010898; 3 Aug 85 8:28 EDT Date: Sat, 3 Aug 1985 06:28 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: Quick-reference list to SIMTEL20 CP/M directories Quick reference list to SIMTEL20's MICRO: directories as of 3-Aug-85 (where 'x' is one of the names below): 22RSX COMND GENASM MSOFT SYSLIB 6502 CPM3 GENCOM NEWS SYSLIB3 AMETHYST CPM86 GENDOC NSTAR SYSUTL APPLE CPMLIB HAMMING OSBORN T20-SQUSQ ASMUTL CPR86 HAMRADIO PACKET TERM ATARI CUG HDUTL PASCAL TOPS-20 AZTEC-C DBASEII HEATH PCDOS TRS-80 BASIC DEBUG HELP PILOT80 TURBODOS BDOS DIRUTL HEX PLOT33 TURBOPAS BDSC-1 DISASM IBM-PC PPSPEL TXTUTL BDSC-2 DISKPLOT IMP PUBKEY V2CMAC BDSC-3 DSKBUF INSIDCPM PUBPATCH VAXVMS BDSC-4 DSKUTL KAYPRO RBBS VOICE BSTAM EDITC80 LIST RBBS4 WSTAR BYE3 EDITOR MACLIB RCPM XCCP BYT85FEB EMX MATH ROS XLISP BYT85JAN EPSON MBBS SMALLC2 YAM C80 EZCPR MEMTEST SMALLC21 Z3LIBS CATLOG FAST2 MEX SORT Z3NEW CB80 FIDO MICNET SPELL ZCPR CBIOS FILCPY MISC SQU-PORT ZCPR2 CCP FILUTL MODEM SQUSQ ZCPR3 COBOL FORTH-83 MODEM2 STARTER-KIT COMMODORE FORTRAN MODEM7 SUBMIT 5-Aug-85 06:00:35-MDT,596;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 5 Aug 85 05:56:15-MDT Received: from simtel20.arpa by AMSAA.ARPA id a010913; 3 Aug 85 8:35 EDT Date: Sat, 3 Aug 1985 06:31 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: SIMTEL20 directory list updated MICRO:CPM.CRCLST on SIMTEL20 (the file listing all the filenames, sizes and CRCs of the MICRO directories) has been updated as of today. --Keith 5-Aug-85 06:00:39-MDT,1826;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 5 Aug 85 05:57:41-MDT Received: from usc-isid.arpa by AMSAA.ARPA id a011195; 3 Aug 85 10:11 EDT Date: 3 Aug 1985 10:10-EDT Sender: ABN.ISCAMS@USC-ISID.ARPA Subject: LOCK Bug Unmasked From: ABN.ISCAMS@USC-ISID.ARPA To: Info-CPM@AMSAA.ARPA Cc: ABN.ISCAMS@USC-ISID.ARPA Message-ID: <[USC-ISID.ARPA] 3-Aug-85 10:10:21.ABN.ISCAMS> Netlandians, A library file called LOCK.LBR was recently installed at SIMTEL20's MICRO archives, shortly thereafter followed by a horrible bug warning message (also in that archive). I did some testing, disassembly, etc. (the source code will be available shortly when I'm done - I DO believe in Public Domain source being released). Only problem I can discover is: If you LOCK a file twice, you gotta UNLOCK it twice! LOCK properly labels its locked files with an ASCII "Locked File" warning, but unfortunately does NOT look at that warning (or maybe the author didn't WANT to check that warning to permit double-LOCKing), and will gleefully lock the LOCKed file again! (Darn, forgot to check what happens if you LOCK twice using two different keywords!) Anyway, test results: If you LOCK a file once (any kind of file), you can UNLOCK it just fine with the same keyword. If you LOCK a file twice (SAME keyword both times), you can UNLOCK it just fine (using the SAME keyword both times). Could not make it crash given the above circumstances. Incidentally, LOCKing algorithm is quite simple - uses the scrambled buffer toward the end of LOCK.COM against the target file data. It ADDs the two values, ANDs in 55H, does a RLCA, XORs it with another pointer character, and then stuffs it away. Regards, David Kirschbaum Toad Hall ABN.ISCAMS@USC-ISID 5-Aug-85 06:39:18-MDT,1409;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 5 Aug 85 06:38:08-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a019527; 5 Aug 85 8:07 EDT Received: from usenet by TGR.BRL.ARPA id a025582; 4 Aug 85 8:19 EDT From: "Donald D. Henson" Newsgroups: net.micro.cpm,net.lang.pascal Subject: Re: Turbo Pascal File Handling Message-ID: <1429@islenet.UUCP> Date: 2 Aug 85 14:59:59 GMT Xref: seismo net.micro.cpm:4733 net.lang.pascal:362 To: info-cpm@AMSAA.ARPA > Does anyone know of a collection of subroutines for Turbo Pascal to do > file handling? Specifically, file look up, renaming, and deletion. > I currently need ones for CP/M but anticipate a need in the near future > for some MS-DOS ones also. Any pointers/References appreciated. > > --Chuck > -- > "Unix, the Teco of Operating Systems." - - - D I S C L A I M E R - - - > {ihnp4,fortune}!dual\ All opinions expressed herein are my > {qantel,idi}-> !intelca!cem own and not those of my employer, my > {ucbvax,hao}!hplabs/ friends, or my avocado plant. :-} Try Turbo Toolbox from Borland International (same folks who sell Turbo Pascal). Turbo Toolbox is a set of Pascal routines (in source) that implement ISAM files using B+ trees. Cost about the same as for Turbo Pascal. 5-Aug-85 11:12:22-MDT,864;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 5 Aug 85 11:08:58-MDT Received: from ames-vmsb.arpa by AMSAA.ARPA id a026908; 5 Aug 85 12:24 EDT Date: 5 Aug 85 09:15:00 PDT From: nep.pgelhausen@AMES-VMSB.ARPA Subject: --- lock --- To: info-cpm@AMSAA.ARPA Reply-To: nep.pgelhausen@AMES-VMSB.ARPA From the algorithm described, I would assume that locking twice, with different keywords could be undone, using the same two keywords IN REVERSE ORDER (i.e.: if locked with "dead" then "bolt", unlock with "bolt" first then "dead"....) It MIGHT work unlocking with "dead" then "bolt"....but I wouldn't want to bet on it..... BTW: can you "unlock" a file that has not been locked....if so, can you recover the data (perhaps by "locking" it?). -Richard Hartman max.hartman@ames-vmsb ------ 5-Aug-85 12:32:04-MDT,5789;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 5 Aug 85 12:30:10-MDT Received: from apg-1.arpa by AMSAA.ARPA id a029802; 5 Aug 85 13:36 EDT Date: Mon, 5 Aug 85 13:26:19 EDT From: Robert Bloom AMSTE-TOI 3775 Subject: Multiuser Micro Info Request To: info-cpm@AMSAA.ARPA, info-micro@simtel20.ARPA Cc: rbloom@apg-1.ARPA I'm depressed. I've been attempting to determine just how I can best upgrade my office computer. (I work in a U.S. Army RDT&E organization.) I thought I was in good shape when the Army signed a open contract to buy Intel 310 systems, but there is a problem. To get the capability I want, I need to spend over $50k if I go with the equipment listed on the (mandatory!) Army contract. I have a fairly good idea that the capability I want is available for much less than the aformentioned $50k - but I don't know quite where. Therefore, I would like to solicite responses from anyone of what I should mention as alternatives to my puchasing agent when I go in to fight the mandatory part of the contract. I need names, addresses, specifications, prices and everything else available to get the best available system that meets the requirements and is the least expensive. (I'm a taxpayer too!) I just don't believe the 310 is it. The remainder of this message contains what I am using now, my upgrade requirements, what I have to buy from the Intel contract to meet those requirements, and some possible alternates to the Intel system. My current system consists of a NorthStar Horizon w/18M HD, 5 Televideo terminals, a NEC printer, a IDS dot-matrix printer and a Hayes modem. It is running a multi-user OS ('TSS/C' - probably quite close to MP/M) with WordStar, dBase II, Mex, and SuperCalc as the main applications software. This system meets my require- ments except in the following areas: it is too slow under load [5 users on one Z80!], does not have enough user terminals [has 5, I need 8], the disk space is marginal [has 18M, I want ~30-40M), and communication with remote systems is awkward [I had to hack it badly to get it to work at all]. The two printers and modem will be used on the new system - if I can also use the 5 terminals that would be even better. The Horizon main frame and HD I suspect must go. Requirements (in order of priority) 1) must run WordStar, dBase, and SuperCalc (I had enough trouble training my people in these, I don't want to start over!) 2) shared files (single-user access to any r/w file, locked to other users until released, multiple access to any r/o file.) 3) queued output to 2 printers 4) two multiple access commo ports to the outside world - one 9600 baud direct connect, one dial-up. (dial-IN access NOT required!) 5) adequate processing speed for all users (TSS/C's major problem is speed - I will buy all the speed improvement I can.) 6) 8-simultaneous users (single-tasking ok) with access from each user's desk. Reset of 'hung' users w/o system reboot. 7) 3MegBytes HD storage per user, not including system and program storage. (I figure a minumum of 30M, 40M desired.) 8) Tape backup system for HD Note that my current system satisfies the first 4 items above; I will not accept a 'new' system that does less that the above even if it does that faster! Intel 310 configuration: The basic problem with the 310 is that it is a UNIX box and cannot satisfy #1 above in multi-user. Therefore, one needs to run the applications at the workstations, not in the central box - and that means using pc's. (The Wyse 1100 pc is included in the contract for just this purpose.) To satisfy #2 above, the pc's must be netted to the central HD via a network of some type. So, the configuration looks like: 8 Wyse 1100 pcs @ $1,926 (IBM-clone, 265k, 2 floppies) 8 Personal Network Interface Interface Unit @ $1,650 (this board connects the pc to the OpenNET LAN, the cheaper NIC steals memory from the pc stopping it from running dBase) 9 10 foot Transceiver Cables @ $70 (+ $15/10 foot over 10') 1 10 port Intellink @ $1,695 (central node on LAN) 1 Intel 310 4-user @ $11,245 (4-user includes 80286, 1MRAM and 40MB HD, smaller systems don't) 1 Ethernet commo controller @ $1,795 (connects 310 to LAN) 1 Tape subsystem on expansion chassis @ $3,339 The total (includes transportation and installation but WITHOUT SOFTWARE) is $45,617. A 'OpenNET' configuration is slightly more expensive than the 'Intellink' configuration cited above. Software would easily push it over $50k as one needs 8 copies of WordStar, dBase and SuperCalc. As I see it, a TurboDOS or similar system (NorthStar Dimension?) that has multiple processors would be best for this application. Something on the order of (pure guesses on the $ amounts): Main Frame/HD/master processor - $5,000 Tape drive added to main frame - $1,000 16-bit slave processors - 8 x $1,500 RAM disk for speed - $2,000 3 more terminals - 3 x $700 Comes to a total of 'only' $22,100 w/o software. That's less than HALF the above and does the same thing. (except run UNIX, but running UNIX is a nonrequirement.) So, anyone have any ideas of what and where I could get something better rather than spending $50k of 'your' money? Please reply directly to rbloom@apg-1, I will synopsize results and post later. This is strictly a request-for-information and does not obligate anyone for anything and does not represent nor indicate U.S. Army policy. Names used above are copyright somebody else. -bob bloom 6-Aug-85 06:19:23-MDT,1254;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Aug 85 06:15:31-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a008788; 6 Aug 85 7:37 EDT Received: from usenet by TGR.BRL.ARPA id a005011; 6 Aug 85 1:59 EDT From: PRO Workstations Pubs Newsgroups: net.micro.cpm Subject: CP/M Computer for Sale!! Message-ID: <3447@decwrl.UUCP> Date: 5 Aug 85 16:02:33 GMT Sender: daemon%decwrl.uucp@BRL.ARPA Posing-Version: version B 2.10.1 6/24/83; site decwrl.UUCP To: info-cpm@AMSAA.ARPA Last call - Epson Geneva (PX-8) Laptop CP/M Computer System for Sale! Computer (PX-8) with latest V2.2 OS chip and built-in microcassette and 64K workspace 120K RAM Disk integrates onto bottom of PX-8 3 1/2" Disk Drive (PF-10) with cable and Charger Modem (CX-20) with cable and charger (300 baud) Cables, Manuals, ROMware (Wordstar, Spreadsheet, Scheduler, MBASIC, and CP/M Utilities), all chargers/AC adaptors, several diskettes and tapes with programs including MEX and MDM7 tossed in, carry case for all All in Excellent shape (never abused) $1250 takes all!! Paul MacDonald 617-493-3439 days only 6-Aug-85 06:24:25-MDT,5733;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Aug 85 06:22:38-MDT Received: from simtel20.arpa by AMSAA.ARPA id a008395; 6 Aug 85 7:19 EDT Date: Mon, 5 Aug 1985 23:19 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Cc: Info-Modem7@SIMTEL20.ARPA Subject: New MEX overlays available from SIMTEL20 Ron Fowler, author of MEX (the ModemEXecutive program) kindly sent a disk of all the latest MEX overlays. It totaled over 1.1 megabytes! Rather than try to detail what new overlays are available, I have made a new list of files in the MEX directory: Filename Type Bytes CRC MICRO: ATRPAT.MEX.1 ASCII 3141 F756H AUTOMEX.IQF.1 BINARY 7936 1325H DOWJONES.MEX.1 ASCII 1315 450CH KGRAFMEX.LBR.1 BINARY 2816 82A6H MEX.HQP.1 BINARY 32640 71EAH MEX-EASY.DQC.1 BINARY 4352 7772H MEX-OVLY.BUG.1 ASCII 1519 0EBAH MEX-RVW.TXT.1 ASCII 2641 CD68H MEX-SET2.DQC.1 BINARY 8576 E147H MEX-STAT.FIX.1 ASCII 804 4D73H MEX-TDOS.LBR.1 BINARY 35328 0C10H MEX112.BUG.1 ASCII 1197 3EBDH MEX114.LBR.1 BINARY 145152 DDB4H MEX114-U.LBR.1 BINARY 39936 3C8FH MEX11DOC.TQC.1 BINARY 1664 2922H MEX11DOC.WQ.1 BINARY 55040 D7A2H MEX11UPD.DQC.1 BINARY 6400 8284H MEX20.HYP.1 ASCII 2572 04F1H MEXFILES.IQF.1 BINARY 5248 CC2EH MEXNEWS.0Q1.1 BINARY 5120 7307H MEXNEWS.0Q2.1 BINARY 5632 3FD6H MEXNEWS.0Q3.1 BINARY 4736 90BFH MEXNEWS.0Q4.1 BINARY 6400 ED85H MEXOVL06.LQT.1 BINARY 10880 F2A0H MEXSUM.DQC.1 BINARY 6144 8163H MEXWELCM.LBR.1 BINARY 4096 8454H MLOAD24.AQM.1 BINARY 24064 585AH MLOAD24.COM.1 BINARY 2816 D8AAH MTIMER12.BQS.1 BINARY 1664 FD84H MX-SM13A.AQM.1 BINARY 6784 A6B4H MX-SM13A.FIX.1 ASCII 1249 35E7H MX111UPD.DOC.1 ASCII 670 3A03H MX112UPD.DQC.1 BINARY 1664 5393H MXM-2400.AQM.1 BINARY 13568 0C2FH MXM-CD10.AQM.1 BINARY 11008 BE2FH MXM-CM11.AQM.1 BINARY 5376 32C5H MXM-CQ10.AQM.1 BINARY 10112 9BABH MXM-CQ11.AQM.1 BINARY 10112 427AH MXM-RT10.AQM.1 BINARY 10112 370DH MXM-RV15.AQM.1 BINARY 10368 821BH MXM-UD10.AQM.1 BINARY 11392 A67BH MXM-US13.AQM.1 BINARY 18432 C8BEH MXO-AC01.AQM.1 BINARY 6144 1425H MXO-AD13.AQM.1 BINARY 18944 15ACH MXO-AL10.AQM.1 BINARY 7808 249DH MXO-AL11.AQM.1 BINARY 7552 84FFH MXO-AM10.AQM.1 BINARY 13824 36C5H MXO-AP12.AQM.1 BINARY 17536 9FA2H MXO-AP30.AQM.1 BINARY 15104 3D61H MXO-AP31.AQM.1 BINARY 31488 DD44H MXO-AP50.AQM.1 BINARY 20864 C928H MXO-APCC.AQM.1 BINARY 19328 0A29H MXO-BB11.AQM.1 BINARY 19712 C7C2H MXO-CT14.AQM.1 BINARY 8320 5A5AH MXO-DB10.AQM.1 BINARY 9728 AC3AH MXO-DM10.AQM.1 BINARY 4224 1C83H MXO-DP10.AQM.1 BINARY 6912 F08CH MXO-DT10.AQM.1 BINARY 7936 FFF7H MXO-DV10.AQM.1 BINARY 11136 439EH MXO-EP12.AQM.1 BINARY 9600 2EDEH MXO-EP30.AQM.1 BINARY 21504 053FH MXO-EPQX.AQM.1 BINARY 9344 E35EH MXO-EPQX.DOC.1 ASCII 2403 FF64H MXO-GB11.AQM.1 BINARY 9728 4E75H MXO-H812.AQM.1 BINARY 8064 79C7H MXO-HZ13.AQM.1 BINARY 12416 7D47H MXO-IF10.AQM.1 BINARY 8192 1A9AH MXO-II12.AQM.1 BINARY 8064 0C47H MXO-IM11.AQM.1 BINARY 6272 7277H MXO-K484.AQM.1 BINARY 17408 EEB0H MXO-KP41.AQM.1 BINARY 28416 CB45H MXO-KP42.AQM.1 BINARY 28672 E2B9H MXO-KPS4.AQM.1 BINARY 21376 4E97H MXO-LO15.ASM.1 ASCII 15749 F1D5H MXO-MC10.AQM.1 BINARY 7040 1758H MXO-MD11.AQM.1 BINARY 11264 DCD0H MXO-MG10.AQM.1 BINARY 10880 CC6BH MXO-MM10.AQM.1 BINARY 11136 6137H MXO-MM2.AQM.1 BINARY 13440 C342H MXO-MR10.AQM.1 BINARY 7936 86F3H MXO-MW10.AQM.1 BINARY 9472 6D59H MXO-N815.LBR.1 BINARY 48256 40E2H MXO-NA1.AQM.1 BINARY 9472 AE31H MXO-NE11.AQM.1 BINARY 7424 9E5FH MXO-NE88.AQM.1 BINARY 13952 C9C2H MXO-NS11.AQM.1 BINARY 14464 9F3EH MXO-OA11.AQM.1 BINARY 11648 AAA6H MXO-OC10.AQM.1 BINARY 11904 3678H MXO-OS15.AQM.1 BINARY 18560 51DAH MXO-OS22.AQM.1 BINARY 10624 83DAH MXO-OSEX.AQM.1 BINARY 9216 700AH MXO-OX11.AQM.1 BINARY 9856 9519H MXO-P1-1.AQM.1 BINARY 8192 3264H MXO-PM22.AQM.1 BINARY 25728 443DH MXO-PR10.AQM.1 BINARY 4864 6F85H MXO-PX8.AQM.1 BINARY 22400 FB95H MXO-PX8.DQC.1 BINARY 7552 2279H MXO-QX10.AQM.1 BINARY 13056 CA30H MXO-R211.AQM.1 BINARY 7552 9361H MXO-RP10.AQM.1 BINARY 9088 7D32H MXO-RS13.AQM.1 BINARY 12288 1B68H MXO-RV13.AQM.1 BINARY 10112 A1F2H MXO-SB12.AQM.1 BINARY 14976 8DDEH MXO-SC10.AQM.1 BINARY 6272 BD8CH MXO-SCAT.AQM.1 BINARY 6272 BD8CH MXO-SD10.AQM.1 BINARY 7808 BE99H MXO-SM13.AQM.1 BINARY 6400 982CH MXO-SM14.AQM.1 BINARY 6912 6008H MXO-SS10.AQM.1 BINARY 7040 0064H MXO-SX10.AQM.1 BINARY 18048 6285H MXO-SY21.AQM.1 BINARY 18560 E23FH MXO-TD30.AQM.1 BINARY 13952 8359H MXO-TSA.AQM.1 BINARY 22784 6AB6H MXO-TV11.AQM.1 BINARY 7936 2FD7H MXO-UD10.AQM.1 BINARY 6528 E1A9H MXO-UR13.AQM.1 BINARY 25216 0F8AH MXO-US13.AQM.1 BINARY 18560 A039H MXO-VP10.AQM.1 BINARY 4736 0A83H MXO-VT11.AQM.1 BINARY 8960 44C3H MXO-VTL1.AQM.1 BINARY 6912 23CBH MXO-XE12.AQM.1 BINARY 11392 A869H MXO-XE2U.AQM.1 BINARY 22272 2C8DH MXO-Z321.AQM.1 BINARY 16384 DA71H MXO-ZB11.AQM.1 BINARY 7040 1552H MXSUM831.MQG.1 BINARY 11904 9A31H OTRONMEX.LBR.1 BINARY 34944 211EH See MEXOVL06.LQT for full details on what systems are supported. --Keith 6-Aug-85 06:57:28-MDT,799;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Aug 85 06:53:51-MDT Received: from gunter-adam.arpa by AMSAA.ARPA id a009461; 6 Aug 85 8:20 EDT Date: 5 Aug 1985 15:54:17 CDT Subject: Environmental question.. From: HUNEYCUTT@GUNTER-ADAM.ARPA To: Info-CPM@AMSAA.ARPA cc: Info-IBMPC@USC-ISIB.ARPA Does anyone have a 'quotable' specification for an acceptable sound level for an office environment? By quotable, I mean a MIL standard, OSHA spec, or the like that I can plug into a military Request for Proposal. We all instinctivly know what we can live with, but firm dB levels seem hard to come by. Minimum I need are noise levels, but any other (like levels at specific frequencies) would be appreciated. Thanx, Doug ------- 6-Aug-85 07:21:58-MDT,2139;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Aug 85 07:18:19-MDT Received: from simtel20.arpa by AMSAA.ARPA id a010117; 6 Aug 85 8:46 EDT Date: Tue 6 Aug 85 06:46:54-MDT From: Rick Conn Subject: ZCPR3: The Manual To: info-cpm@AMSAA.ARPA cc: info-micro@AMSAA.ARPA Message-ID: <12132950363.8.RCONN@SIMTEL20.ARPA> The book on ZCPR3, namely ZCPR3: The Manual, is out now, and it is available from the Library of Computer and Information Science and the Small Computer Book clubs. It is also available from Echelon. The book is divided into three sections: Using ZCPR3 (detailing all the commands with chapters devoted to the online documentation system, menus, VFILER, DU3, and general concepts), ZCPR3 Internals (how the system works), and ZCPR3 Installation. The book is 350 pages. If you have questions on ZCPR3 (and all of the softwre in the the archive on SIMTEL20), the book is a good source. I wrote ZCPR3 and the book, so you know where I'm coming from, but I really feel that the book meets a need. The next few issues of Byte (starting in Sept) contain Steve Ciarcia's column on the SB180 single-board computer, and there is a lot of ink on ZCPR3 here as well. Echelon has just received (from me) a new document on IOPs (the Input/Output Package concept of ZCPR3), and this adds another 60+ pages of reading. You can get a hardcopy from Echelon or download the document from a Z-Node (see the list on SIMTEL20). Finally, the Echelon newsletters (there are over 25 now) provide lots of information on the evolution of ZCPR3 and changes/bug fixes/new activities. I have written an article for Micro Cornucopia on the operational concept behind the ZCPR3 Environment Descriptor (which should appear in the next issue). Hopefully, this is enough reading to really start to get the ZCPR3 concepts across. The source code to the entire system is on SIMTEL20, and I will be sending an update soon which will bring the files on SIMTEL20 up with the latest versions of the software. Rick ------- 6-Aug-85 07:54:37-MDT,856;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Aug 85 07:50:47-MDT Received: from mitre.arpa by AMSAA.ARPA id a011054; 6 Aug 85 9:11 EDT Received: by mitre.ARPA (4.12/4.7) id AA21559; Tue, 6 Aug 85 09:12:27 edt Message-Id: <8508061312.AA21559@mitre.ARPA> To: HUNEYCUTT@GUNTER-ADAM.ARPA Cc: Info-CPM@AMSAA.ARPA, Info-IBMPC@USC-ISIB.ARPA Subject: Re: Environmental question.. In-Reply-To: Your message of 5 Aug 1985 15:54:17 CDT. <8508061248.AA21269@mitre.ARPA> Date: 06 Aug 85 09:10:59 EDT (Tue) From: Jeff Edelheit I think some work in this area was published by the Human Factors Society and, as I remember, the recommendation was for 60 db or less. I don't remember seeing any discussions regarding specific frequencies. Jeff Edelheit (edelheit@mitre) 6-Aug-85 08:09:01-MDT,605;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Aug 85 08:07:09-MDT Received: from su-star.arpa by AMSAA.ARPA id aa11679; 6 Aug 85 9:22 EDT Date: 5 Aug 85 13:30:00 PDT From: "R. Meier" Subject: re: Apple to IBM? To: info-cpm Reply-To: "R. Meier" Sue, If you have the source code, then kermit available with anonymous login to CU20b (between 12am and 6am EDT), will allow you to transfer files conveniently. Mail questions to: Bob Meier(riacs!meier@pluto) ------ 6-Aug-85 12:01:38-MDT,901;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 6 Aug 85 12:01:17-MDT Received: from xerox.arpa by AMSAA.ARPA id a020336; 6 Aug 85 13:13 EDT Received: from CheninBlanc.ms by ArpaGateway.ms ; 06 AUG 85 10:12:33 PDT Date: 6 Aug 85 10:12:28 PDT (Tuesday) From: Bicer.ES@XEROX.ARPA Subject: Re: Multiuser Micro Info Request In-reply-to: rbloom's message of Mon, 5 Aug 85 13:26:19 EDT To: Robert Bloom AMSTE-TOI 3775 cc: info-cpm@AMSAA.ARPA, info-micro@SIMTEL20.ARPA Message-ID: <850806-101233-1330@Xerox> I think you have perfectly described a Compupro 816 system (Viasyn as they are called now). I suggest you contact Gifford Systems (look at a recent Byte magazine for their number, if you can't, let me know). These are one of the fastest and most reliable machines on the market. Jack Bicer BICER.ES@XEROX.ARPA 7-Aug-85 10:51:40-MDT,852;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 7 Aug 85 10:49:44-MDT Received: from mit-mc.arpa by AMSAA.ARPA id a015341; 7 Aug 85 12:23 EDT Date: Tue, 6 Aug 85 17:20:27 EDT From: Herb Lin Subject: Multiuser Micro Info Request To: Bicer.ES@XEROX.ARPA cc: LIN@MIT-MC.ARPA, rbloom@APG-1.ARPA, info-cpm@AMSAA.ARPA Message-ID: <[MIT-MC.ARPA].602940.850806.LIN> I think you have perfectly described a Compupro 816 system (Viasyn as they are called now). I suggest you contact Gifford Systems (look at a recent Byte magazine for their number, if you can't, let me know). These are one of the fastest and most reliable machines on the market. Gifford Systems is no longer selling S-100 Compupro stuff; they seem to have abandoned that market. Herb 8-Aug-85 13:21:08-MDT,1733;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 8 Aug 85 13:18:26-MDT Received: from nosc-gw by AMSAA.ARPA id a001821; 8 Aug 85 13:21 EDT Received: from tetra.ARPA by nosc.ARPA (4.17/4.7) id AA13836; Thu, 8 Aug 85 07:54:48 pdt Received: by tetra.ARPA (4.17/4.7) id AA06532; Thu, 8 Aug 85 07:59:16 pdt Date: Thu, 8 Aug 85 07:59:16 pdt From: Gerry Key Message-Id: <8508081459.AA06532@tetra.ARPA> To: info-CPM@AMSAA.ARPA Subject: dBASE II Question Cc: ogasawar%tetra@nosc.ARPA, pasquere%tetra@nosc.ARPA I have a dBASE II question. First, the scenario. File X.dbf contains 100 records. File Y.dbf contains 0 records but has the same definition (i.e., STRUCTURE) as X.dbf. Someone inadvertently issues the command: . use Y . copy to X structure The result is that the 100 records in X.dbf are still there, but because it now has the definition of Y.dbf, X.dbf appears to con- tain 0 records. Any reference to a record number in X.dbf pro- duces an error because the definition thinks there are none. The question: is there any way to fake the definition of X.dbf into recognizing those 100 records? I tried doing an APPEND, thinking that when it updated the definition it would count in the 100 records that were there plus the dummy record I just ad- ded. Wrong. It now says I have 1 record in X.dbf instead of 0. --Gerry MILNET/ARPANET >-------------------- key@nosc.arpa akgua \ decvax \ dcdwest \ UUCP allegra -------------!sdcsvax!noscvax!key ucbvax / philabs/ ihnp4 / 8-Aug-85 13:21:16-MDT,5296;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 8 Aug 85 13:19:57-MDT Received: from usc-isi.arpa by AMSAA.ARPA id a002205; 8 Aug 85 13:23 EDT Date: 8 Aug 1985 13:21:16 EDT Subject: Protocol Wars From: Steve Noland To: INFO-MODEM7@SIMTEL20.ARPA cc: INFO-CPM@AMSAA.ARPA In the interest of broadening the scope of this discussion, I am relaying the following discourse that was found today on the MBBS Central RCP/M. To: All who are interested From: David McCord, sysop, ZCPR3 BBS (415) 489 9005 Date: 4 Aug 85 Subj: yet another opinion It seems as though many sysops (you know who you are) have an ax to grind against Irv Hoff. The various recent notes I have seen on the sysop board and in other places air a trend I see as undesireable; belittling KMD because they want to grind their axes against Irv. I am not attempting to defend whetever real or percieved greivances they may have against Irv; but I must question their rationale in their criticisms of KMD and BYE500. One of the things that not many sysops know is that Irv did not implement the automatic selection of 1k or 128 byte packets purely on his own whim. He was asked to bring forth a xmodem-like program that had automatic selection of block size by the northern california sysop organization, PRACSA. The reason this sysops organization did this was mainly ease of use for non-technical users. And, we believed there was sufficient precedent in the automatic selection of CRC or checksum error checking modes to warrant automatic selection of block size. By "automatic", I mean the user need not use any extra command line parameters, i.e., simply use "XMODEM S" or "KMD S". I have seen folks questioning and ridiculing the extra "K" that KMD uses in the synchronization stage to accomplish the automatic selection of block size. However, their comments are never specific, usually something along the lines of "it sucks". Personally, I would like some specific information on why "it sucks", because I have yet to see any. In my opinion as a professional telecommunications engineer, I see nothing wrong with the extra character. The overhead involved is exactly one character time at whatever baud rate is being used, no matter how long the file to be transferred is. This is hardly inefficient or undesireable, since the result is a program that is easier to use. Because the PRACSA sysop organization asked Irv to develop what has resulted in KMD, most of us are using it. We will probably go on using it until we are shown solid reasons why we should not do so. I do not speak officially for PRACSA, as I am not an elected officer. However, I am quite willing to speak at the next PRACSA meeting on the disadvantages of KMD, should any be brought out. Perhaps the only valid criticism of KMD is it's name: it is not XMODEM. I do not have a problem with this personally, because if you are using ZCPR3 (as I am), it is quite easy to construct an ALIAS named XMODEM that passes it's parameters to KMD.COM. However, for non-Z3 systems, facilities such as SYNONYM could do this also. Yet, I do concede this as a valid "problem" of KMD. But this leads me to the reason that KMD was named differently than XMODEM. It is because KMD uses BYE500; XMODEM does not. Charges have been made that Irv is trying to "lock in" XMODEM to systems using BYE500. Wrong! Irv has "locked in" KMD to systems using BYE500, NOT XMODEM!!! Irv has not, to my knowledge, ever come out and said that everyone can get rid of XMODEM now that KMD is here. If someone wants to use XMODEM as a standalone program, fine. They have that choice. But for systems already using BYE, eliminating the redundancy of both the file transfer program and BYE both having the same routines makes sense. And, having used BYE500 and KMD on my BBS, I am quite pleased with the added functionality. I can use the BYE function keys when KMD is active, and I get a much more informative description of block errors during file transfer than I ever recieved using XMODEM. Also, it is quite easy to install. In summary, I think that the arguing that has been going on has not really been specific enough regarding why KMD may be an inferior choice; instead it has been oriented more toward "We don't like Irv, and we're gonna get him by trashing KMD and BYE500". The people who are doing this are doing everyone a disservice, because the pseudo-debating is not addressing the real issues involved. We could invest our time better by: - informing users as to the merits and demerits of the 1k block in various circumstances, - discussing if it is better or not better to have auto selection of 1k blocks (regardless of the technique used), - discussing if it is possible for any mini- or mainframe based multiuser system to cope with 1k blocks with any increase in throughput, etc. I plead with all involved to continue debating the issues involved, but to become oriented to facts and logic, instead of insinuation and emotion. Enough said! (for now...) ======================================== Regards, Steve Noland (NOLAND@USC-ISI) ------- 9-Aug-85 06:25:19-MDT,11863;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Aug 85 06:22:02-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id ab04560; 8 Aug 85 13:49 EDT Received: from usenet by TGR.BRL.ARPA id a021413; 7 Aug 85 23:11 EDT From: Walt Sakai Newsgroups: net.micro.cpm Subject: >> RAMDISK : SUMMARY OF RESPONSES << Message-ID: <180@proper.UUCP> Date: 5 Aug 85 16:40:42 GMT To: info-cpm@AMSAA.ARPA Thanks to all who responded to my RAMDISK query. Below is an edited summary (about 4 pages long) for your information. Send additional responses if you like. Walt Sakai {ucbvax,hplabs,ihnp4,cbosgd, decwrl,unisoft,fortune,sun,nsc}!dual!proper!walt_sak * * * From nsc!seismo!purdue.edu!droms Wed Jul 31 08:44:38 1985 ================================================================= Micro-Cornucopia magazine recently reviewed a number of Z80 SBC memory expansion boards. Micro-C no. 22 (February-March, 1985) includes reviews of a 256K RAM Expansion Module from Ferguson Engineering, and the Rivendell Audiocomp 256K Ram + I/O expansion board. Issue no. 23 (April-May, 1985) has a short review of the MicroSphere 256K RAMdisk. Issue no. 9 (Dec. 1982) reviews the LASoftware 256K RAMDisk kit. Ralph Droms ihnp4!purdue!droms 445 MATH droms@purdue.arpa Dept. of Computer Science droms@purdue.csnet Purdue University, West Lafayette, IN 47907 From: dual!ukma!steve (Steve Ferry) ================================================================= I have a Drive C that I use with my Osborne I and I think its wonderful. To be really useful, it needs to be fairly large. Mine is 384K and 512K wouldn't hurt a bit. There is some problem using it with submit and with programs that sit up in high memory intercepting BDOS calls. I wouldn't use Wordstar without it. From dual!cbosgd!ihnp4!tektronix!tekchips!toma (Tom Almy) ================================================================= I have had about a years experience with a RAM-DISK that I built for my Lobo MAX-80. My system has a 5 Mhz Z-80, two DSDD 8" drives (1.2 meg apiece), and a 256k ram-disk. Operating system is CP/M+ with about 32k of sector-buffering. The buffering of CP/M+ improves performance of random-access files (such as databases) to the point that ram-disk offers little improvement. I put the utility .COM files and the overlays for Wordstar and KAMAS on the RAM disk. I also don't trust the RAM-DISK for data files (except read-only, where information is always backed up on a Floppy). If I could do it again, I would want to rely on track or sector buffering instead of a RAM DISK (since it automatically backs up to the floppy), perhaps with a few hundred K of RAM for this. Then I would want to have a ROM DISK (a RAM disk with 27256 EPROMS) to hold all my commonly used programs and overlays. In fact, the CP/M OS could be loaded of of the ROM DISK eliminating the need for a "System Disk". From nsc!seismo!MIT-MC.ARPA!STORK (Eric Stork) ================================================================= I've used a SEMIDISK for 1.5 years now, and would not be without it. Cost has come down a lot (see BYTE ad). Speed is amazing. For example, to load dBASEII off a floppy takes about 9 secs. To load off RAMDISK takes <1 sec.! Assembling long files is a pleasure. I keep about 300k of com files in a library, use the rest of the 1 meg for data. Highly recommend RAMSDISK. From dual!hplabs!tektronix!reed!elaine ================================================================= I am using the boards from SemiDisk systems and have had no trouble with them. They make anything disk intensive very fast. I run a BBS of of mine and I know that is disk *intensive*. From dual!ucbvax!sdcsvax!crash!ihom (Irwin Hom) ================================================================= My CP/M system consists of an Apple //e using a PCPI APPLI-Card with a 128k piggy-back RAM board. A RAMdisk is definitely an advantage when running programs that use overlays. Take WordStar for example. Making the transition from floppies to a hard disk speeded up the menu displays by about 70%. On the RAMdisk, this increased to 95%. Almost instantaneous! The cost for a 128k module is about $175. Two modules can be added to the PCPI card allowing a 192k workspace. A RAMdisk is worthy when working with programs that does a lot of disk access with files or overlays. Recently, I've been developing programs in Turbo Pascal. Saving and compiling files on the RAMdisk is a tremendous timesaver. From qantel!ihnp4!houxm!whuxl!whuts!amc Thu Aug 1 03:52:26 1985 ================================================================= I have a Compupro S100 system with a 1/2 Meg MDrive (RAMdisk), running OASIS, which is a business-oriented operating system modeled after PDP-11/VMS. I also have two 8" floppies attached. I keep all the OS stuff on the MDrive (OASIS uses about 1/2 Meg with all the goodies like assembler, editor, text formatter, terminal emulator, etc.). With the MDrive attached, my computer is simply the fastest thing I have ever used, and I have used them all--IBM, DEC, HP, Honeywell, Univac, AT&T, and lots of micros. Best money I ever spent. -Andy Cohill ================================================================= RAMDISK INFORMATION Source: BAKUP Kaypro User Group, CA This file consists of public messages left on the BBS from 3/14 to 7/20/85 in regards to mostly the MICROSPHERE RAMDISK. ================================================================= From: TOM CIARAMITARO To: ALL Date: 03/14/85 AS YOU KNOW, I WANT TO SEE ABOUT GETTING A FEW OF US TOGETHER FOR THE PURCHASE OF A 1 MB RAMDISK, BY PURCHASING THE MICROSPHERE BOARD AND GETTING A QUANTITY PRICE ON THE 256K CHIPS. 6 MONTHS AGO THESE CHIPS WERE ADVERTISED FOR OVER $50 IN MICRO C. I JUST GOT A FLYER THAT LISTS THEM FOR $8.75 (50 LOT), $8.25 (100 LOT). THAT WOULD BRING OUR TOTAL PRICE DOWN AS LOW AS $475!!! CALL ME (415) 825-0299, OR 687-0644 EVENINGS. THIS ALSO HAS A 64K PRINTER BUFFER INCLUDED FREE! From: KEN FOWLER To: ALL Date: 06/12/85 Subject: RAMDISK AND KEYPAD For all Microsphere Ram Disk users whose numeric keypads no longer work, the problem is not with the ramdisk software but with the cp/m BIOS. To provide room in memory for the ramdisk driver, you had to relocate cp/m using the MOVCPM utility. MOVCPM contains a copy of your BIOS as set up by KAYPRO, which includes the keypad definitions. It would be O.K. if you could use CONFIG.COM to reconfigure the keypad, but unfortunately they wrote CONFIG to work only with a 64k system. It should be relatively easy for a PASCAL programmer to write a new CONFIG which would work on any size cp/m. From: DANIEL HOWARD To: ALL Date: 06/11/85 Subject: RAM DISK ODDITY WHEN USING THE MICROSPHERE RAM DISK, DIRECT ACCESS TO THE PRINTER IS NO LONGER AVAILABLE. I TRIED USING CONTROL-P TO PRINT A SMALL DOCUMENT, AND LATER TRIED USING SELECT WORD PROCESSING TO PRINT A LETTER BUT NO PRINTING WAS STARTED. WHEN I INITIALIZED DISK "E" (THOUGH ONLY USED THE FLOPPIES AFTER INITIALIZING) THE PRINTER FUNCTIONED, SO IT SEEMS THAT THE BUFFER DOESN'T FUNCTION INDEPENDENTLY OF THE RAM DISK. THIS WILL RARELY BE A PROBLEM SINCE I EXPECT TO LOAD SELECT INTO THE RAM DISK MOST OF THE TIME, BUT WHEN QUICKLY BATTING OUT A SMALL LETTER AND USING THE FLOPPIES ONLY, THE RAM DISK MUST STILL HAVE BEEN INITIALIZED. From: STEVE WILLETT To: ALL Date: 06/12/85 Subject: D HAWKINS - RAM DISK I did not understand your message about RAM disk initialization. Specifically I was puzzled by your comment that EX.COM wouldn't work to initialize the RAM disk. I use EX.COM and the following NEWRAM.SUB file: RDISKM64| {to initialize the disk} YY {to ask for and confirm reformatting} PIP E:=A:*.*| {to copy files from A:} DIR F:| {to switch to RAM disk => A:} ERA ???RAM.SUB| {to erase SUB files} D| This all works fine. I have another file, OLDRAM.SUB, which does the same except it does not format the disk. I use this when I have left my external power supply on and have data on the disk. For this reason I do not give either commands automatically on boot -I just issue the EX OLDRAM or EX NEWRAM command from the A> prompt. From: DANIEL HOWARD To: ALL Date: 07/08/85 Subject: RAMDISK & WARM BOOT If owners of Microsphere's Ramdisk use DIR F: to make the Ramdisk drive A, then warm boots will not activate the floppies, nor will a new floppy be logged on. For example, Software Toolworks C/80 does a warm boot after a compile. If C/80 is in the Ramdisk and the latter is set to be drive A, then the warm boot takes place using the Ramdisk and there is no drive activity. But to log in a new floppy, it would be necessary to use DIR F: to return the top drive to being drive A, do a control C, access the new floppy (most likely in drive B), and then use DIR F: again to restore the Ramdisk as drive A. From: STEVE WILLETT To: ALL Date: 07/11/85 Subject: RAMDISK & WARM BOOT In response to Daniel Howard's message about Microsphere's RAM disk and warm boots I'm sorry, I have to disagree. I use DIR F: to set up the RAM disk as drive A: and it still spins the floppies and accesses the top drive every time I do a warm boot. It may be a side effect of having a Pro8 machine and/or having ZCPR installed, but it definitely does it. From: STUART HOLLANDER To: ALL Date: 07/12/85 Subject: RAMBOARD-NEW CHIPS!! For those of you who have purchased the Microsphere ramdisk, some stimulating news. Just called Fry's in Sunnyvale (408-733-1770) and found that (hold onto your seats) they are offering the NEC 41256-15 (exactly like the ones on our ramdisks) for $2.99 each. Get 'em while they're hot! More good news. Spoke to Don Thompson at Microsphere re the upgrade. Contra to the instruction manual, we don't need to upgrade our 8748 chips--the ones installed were the upgraded versions. Let's see, that is 16 x 2.99, or a 512K upgrade for the princely sum of $47.84 plus tax. Bought mine on Saturday, plugged 'em in, did the tests, and all is fine. Since mine was configured as 512k with a 32k printer buffer, I now have 960k available with a 32k printer buffer. Spoke to the people at Fry's and, as of Monday the 15th, they will start accepting mail orders. Additional charge is something like a dollar, plus the C.O.D. charge of $1.95 or so. From: DANIEL HOWARD To: ALL Date: 07/20/85 Subject: RAMDISK TO 1 MEG STUART HOLLANDER LEFT A MESSAGE RE UPGRADING THE MICROSPHERE RAMDISK FROM 512K TO 1 MEG USING THE 8748 CURRENTLY INSTALLED (THE INSTRUCTIONS STATE THE NEED TO PURCHASE A NEW ONE). WHAT STUART DIDN'T MENTION WAS THAT THE JUMPER THE INSTRUCTIONS STATE NEEDS TO BE INSTALLED ON U15 IS NOT REQUIRED EITHER. SIMPLY PUT IN THE 16 256K CHIPS AND ONE MEGABYTE MINUS THE CURRENT BUFFER IS AVAILABLE. -- EOF -- 9-Aug-85 06:35:18-MDT,1776;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Aug 85 06:31:18-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a022205; 9 Aug 85 7:28 EDT Received: from usenet by TGR.BRL.ARPA id a024605; 8 Aug 85 21:45 EDT From: Jeffrey Miller Newsgroups: net.micro.cpm Subject: Re: Multiuser Micro Info Request Message-ID: <569@mmintl.UUCP> Date: 7 Aug 85 18:41:11 GMT To: info-cpm@AMSAA.ARPA * I'm a firm believer in networking micros rather than using a central multi- user micro with terminals. You can get a massive increase in performance and usefulness that way. I suggest getting a network server with software and a large hard disk. Novell software seems to provide the greatest file and record locking capability of the popular packages and can run on a wide range of manufacturers' hardware. You can get cheap PC compatibles and you'll only need a network interface card (besides the usual stuff) in each. This will let you run the software required by your specification. Some software has network versions. Those programs you mention probably do. Each micro is also capable of standalone operation in this configuration versus the central multiuser config. You should be able to find 8-bit networking software if you prefer, but since the programs you mention also have 16-bit versions, you may find more available in that world. ************************************************* * Jeff Miller * * Multimate International Corp. * * 52 Oakland Avenue * * East Hartford, CT 06108-9911 * * UUCP: * * ...!seismo!utah-cs!utah-gr!pwa-b!mmintl!jeffm * ************************************************* (The usual exclaimers) * 9-Aug-85 06:45:17-MDT,976;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Aug 85 06:43:00-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id aa04560; 8 Aug 85 13:49 EDT Received: from usenet by TGR.BRL.ARPA id a021512; 7 Aug 85 23:14 EDT From: "Wherever you go, there you are." Newsgroups: net.micro.cpm Subject: Help wanted -- Z80 cross-assembler for VAX/VMS Message-ID: <3487@decwrl.UUCP> Date: 6 Aug 85 20:32:28 GMT Sender: daemon%decwrl.uucp@BRL.ARPA To: info-cpm@AMSAA.ARPA Can anyone point me at a public-domain Z80 cross-assembler that will run on a VAX under VMS? It can be MACRO-32, Fortrash, Basic, Pascal, C, or Bliss. If there's not a PD version, is there a CHEAP one that I can get for Apple CP/M? Thanks for any help. Cheers, Dick Binder (The Stainless Steel Rat) UUCP: { decvax, ucbvax, allegra... }!decwrl!dec-rhea!dec-dosadi!binder ARPA: binder%dosadi.DEC@decwrl.ARPA 9-Aug-85 06:55:17-MDT,1114;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Aug 85 06:53:39-MDT Received: from xerox.arpa by AMSAA.ARPA id a002646; 8 Aug 85 13:25 EDT Received: from PinotNoir.ms by ArpaGateway.ms ; 07 AUG 85 12:07:44 PDT Date: 7 Aug 85 12:07 PDT From: Ghenis.pasa@XEROX.ARPA Subject: XLISP12.COM To: info-cpm@AMSAA.ARPA cc: Ghenis.pasa@XEROX.ARPA Message-ID: <850807-120744-154@Xerox> I finally found a copy of XLISP12.COM. Thanks to Dave Giunti for uploading it to the Computer Language BBS. Unfortunately, it really BARELY fits in 64k: you run out of memory after typing just a few expressions (don't even try loading a short program). What I will end up doing for the local CP/M group (at least in the meantime) is using version 1.1 with an INIT file that will "fake" ASSOC, PUTPROP, GETPROP, MAPCAR and a few other improtant things. In case anyone is interested, the CL BBS's number is (415)957-9370. Also, thank you to all of those who responded offering to help. -- Pablo Ghenis Xerox Artificial Intelligence Systems Pasadena, CA 9-Aug-85 07:00:18-MDT,1031;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Aug 85 06:58:32-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a004560; 8 Aug 85 13:44 EDT Received: from usenet by TGR.BRL.ARPA id a018093; 7 Aug 85 21:52 EDT From: Eric Hestenes Newsgroups: net.micro.cpm Subject: how to execute programs from within cpm programs Message-ID: <946@sdcsla.UUCP> Date: 5 Aug 85 20:43:44 GMT To: info-cpm@AMSAA.ARPA Can anyone give me a hint as to how someone would call one program, say WORDSTAR or something simpler, from within another program. Methods using Turbo Pascal, 'C' or assembler would be useful. ( Please don't tell me to use AUTORUN, etc. I want to call programs from ) ( within programs, not do batch processing of commands. ) -------------------------- Eric Hestenes Institute for Cognitive Science, C-015 UC San Diego, La Jolla, CA 92093 arpanet: hestenes@nprdc.ARPA other: ....ucbvax!sdcsvax!sdcsla!hestenes 9-Aug-85 07:10:18-MDT,1888;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Aug 85 07:07:26-MDT Received: from sdcsvax.arpa by AMSAA.ARPA id a021353; 24 Jul 85 7:35 EDT Received: by sdcsvax.ARPA (4.24/4.41) id AA04384; Wed, 24 Jul 85 00:40:25 pdt From: crash!kevinb@sdcsvax.ARPA Message-Id: <8507240740.AA04384@sdcsvax.ARPA> Date: Tue, 23 Jul 85 18:08:43 PDT To: info-cpm-request@AMSAA.ARPA Subject: S-100 bus board problems Resent-Date: Thu, 8 Aug 85 14:41:00 EDT Resent-From: cpmlist@AMSAA.ARPA Resent-To: info-cpm@sdcsvax.ARPA I am new to the S-100 area, and having gotten an old IMSAI chassis with power supply and motherboard, I am eager to make sure it's up to snuff before I plug anything else into it. I am getting +11 on pins 1 & 51, +21 on 2, -21 on 52, 0 on the grounds (20,50,70,100) and about 2.3 or 4 everywhere else. Is this normal? If not, a) is it within acceptability and b) if not, what kinds of hints can you-all offer to help fix same? These values were tested WITHOUT boards, and I only plan to put in 1-3 boards in for quite a while. The name of the above is the PCS-80/15 microcomputer, using the EXP-10 motherboard, and the MBU-B 8085-based CPU. The motherboard also has traces cut at the terminator at pins 71-74,75 being blank,76-78,79 being reconnected, and 99. Also, the CPU board has spaghetti and cutouts around U31, a chip with the label N82S31N 7734 and the label is an S. This chip isn't in the original assembly instructions, which is ALL I have. Anything of help on this, would also be a godsend. I can do without the CPU, but I've got an Advanced Digital SUPER QUAD I can drop into the motherboard, once it gets working. Thanks in advance, Kevin Belles Kevin Belles - UUCP {ihnp4,cbosgd,sdcsvax,noscvax}!crash!kevinb ~~~~~ ~~~~~~ - ARPA crash!kevinb@{nosc,ucsd} 9-Aug-85 07:40:27-MDT,965;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Aug 85 07:40:10-MDT Received: from sdcsvax.arpa by AMSAA.ARPA id a018045; 26 Jul 85 14:33 EDT Received: by sdcsvax.ARPA (4.24/4.41) id AA09349; Fri, 26 Jul 85 00:12:35 pdt From: crash!kevinb@sdcsvax.ARPA Message-Id: <8507260712.AA09349@sdcsvax.ARPA> Date: Thu, 25 Jul 85 22:58:46 PDT To: info-cpm-request@AMSAA.ARPA Subject: 8085 assembler Cc: jaj.virginia@csnet-relay.ARPA, info-micro@brl-vgr.ARPA Resent-Date: Thu, 8 Aug 85 15:17:12 EDT Resent-From: cpmlist@AMSAA.ARPA Resent-To: info-cpm@sdcsvax.ARPA In reference to James Jokl's message, I'm trying to resurrect an Imsai 8085 based system, so any information re an 8085 assembler, I too, would appreciate. Thanks, Kevin Belles Kevin J. Belles - UUCP {ihnp4,cbosgd,sdcsvax,noscvax}crash!kevinb ~~~~~ ~~ ~~~~~~ - ARPA crash!kevinb@{ucsd,nosc}.ARPA 9-Aug-85 07:45:57-MDT,876;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Aug 85 07:42:02-MDT Received: from nprdc-gw by AMSAA.ARPA id a020908; 26 Jul 85 15:36 EDT Received: by nprdc.ARPA (4.12/4.7) id AA27516; Fri, 26 Jul 85 12:35:42 pdt From: Mel Moy Message-Id: <8507261935.AA27516@nprdc.ARPA> Date: 26 July 1985 1232-PDT (Friday) To: info-cpm-request@AMSAA.ARPA Subject: Re: print file repeatedly in Wordstar Resent-Date: Thu, 8 Aug 85 15:18:22 EDT Resent-From: cpmlist@AMSAA.ARPA Resent-To: info-cpm@NPRDC.ARPA The best way to output multiple copies from Wordstar is to utilize Mailmerge to output your file. Even if you are not really performing mailmerge functions, such as customizing form letters, you have the ability to specify how many copies you wish to have printed. Mel Moy melmoy@nprdc 9-Aug-85 08:19:54-MDT,687;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 9 Aug 85 08:16:52-MDT Received: from apg-1.arpa by AMSAA.ARPA id a021898; 9 Aug 85 7:23 EDT Date: Thu, 8 Aug 85 22:07:59 EDT From: Robert Bloom AMSTE-TOI 3775 Subject: Re: dBASE II Question In-Reply-To: Your message of Thu, 8 Aug 85 07:59:16 pdt To: Gerry Key Cc: key@nosc.ARPA, info-cpm@AMSAA.ARPA there is a neat basic program in simtel that lets you do exactly what you want to do. its in micro:, unfortunately, the name escapes me and my list is not handy. it's a library file with fairly good documentation. -bob 10-Aug-85 10:55:29-MDT,1789;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 10 Aug 85 10:55:18-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id aa15299; 10 Aug 85 12:24 EDT Received: from usenet by TGR.BRL.ARPA id a020429; 9 Aug 85 19:41 EDT From: jp@LANL.ARPA Newsgroups: net.micro.cpm Subject: Re: dBASE II Question Message-ID: <29487@lanl.ARPA> Date: 9 Aug 85 21:12:43 GMT To: info-cpm@AMSAA.ARPA > > > I have a dBASE II question. First, the scenario. > > File X.dbf contains 100 records. File Y.dbf contains 0 records > but has the same definition (i.e., STRUCTURE) as X.dbf. Someone > inadvertently issues the command: > > . use Y > . copy to X structure > > The result is that the 100 records in X.dbf are still there, but > because it now has the definition of Y.dbf, X.dbf appears to con- > tain 0 records. Any reference to a record number in X.dbf pro- > duces an error because the definition thinks there are none. > > The question: is there any way to fake the definition of X.dbf > into recognizing those 100 records? I tried doing an APPEND, > thinking that when it updated the definition it would count in > the 100 records that were there plus the dummy record I just ad- > ded. Wrong. It now says I have 1 record in X.dbf instead of 0. > > --Gerry > I haven't tried this but if the file got screwed up the way you say it did, whynot just reverse the process. Create a new file with the correct structure, enter the appropriate number of records (or more, if you must guess) then copy the correct structure back into your file. If all you did by your mistake was change the structure and record number, this should fix you up. Jim Potter jp@lanl.arpa 10-Aug-85 10:56:31-MDT,2966;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 10 Aug 85 10:56:16-MDT Received: from simtel20.arpa by AMSAA.ARPA id a015339; 10 Aug 85 12:24 EDT Date: 9 Aug 85 00:22:44 GMT Message-ID: Sender: Morris Jones From: Morris Jones Newsgroups: net.micro,net.micro.pc Subject: MicroPro product update information (August) ReSent-From: KPETERSEN@SIMTEL20.ARPA ReSent-To: Info-Cpm@AMSAA.ARPA ReSent-Date: Fri 9 Aug 1985 21:16-MDT Offered as a public service. If you feel this is contrary to the interests of the net, please send me mail. I'll proceed according to the responses. Mojo ------------------------------------------------------------------------- MICROPRO`S CUSTOMER UPDATE INFORMATION FOR AUGUST Customer Updates: 800-227-5609, Monday through Thursday, 9-11AM and 1-3PM, Pacific Time Technical Support-- 415-499-8320 --PRINTER ENHANCEMENT AVAILABLE-- The original WordStar program has been enhanced to work with the HP Laserjet, HP Thinkjet, Diablo ECS AND IBM Quitewriter and Wheelprinter. WordStar 2000 now supports all HP Laserjet font options and it's other print functions, such as proportional spacing, superscript, subscript and justification. Printer-Support Enhancement Disks permit dealers to upgrade existing WordStar 2000 and WordStar 3.3 IBM packages. This free update is available through your dealer. If you have trouble locating a dealer in your area, call 800-227-6730. --UPDATING YOUR SOFTWARE-- In referring to the Update prices listed below, please note the following product availability, listed next to update price. (MicroPro's pricing and product availability are subject to chan- ge.) 1)IBM/Compaq 2)CPM 80/86 3)Apple --Update prices are: WordStar-$85 (1,2,3) Prof Options (MailMerge, CorrectStar, StarIndex)-$140 (1,2,3) WS 2000-$250 (1) WS 2000+-$350 (1) WS2000 Options-100 (TeleMerge, Mailing List Management) (1) --To obtain an Update send: -your original MicroPro Disk -the appropriate prepayment -correspondence indicating what hardware you are using or intend to use. --When ordering either Options Pack, you do not need to send in your software. We are not set up to process purchase orders---We do honor Visa, MasterCard, checks or money orders. Please send your completed Update Order to: Customer Updates P.O. BOX 4960 San Rafael, CA 94913 -- Mojo ... Morris Jones, MicroPro Product Development {dual,ptsfa,hplabs}!well!micropro!kepler!mojo 10-Aug-85 11:20:59-MDT,3665;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 10 Aug 85 11:20:52-MDT Received: from simtel20.arpa by AMSAA.ARPA id a015381; 10 Aug 85 12:25 EDT Date: Fri, 9 Aug 1985 21:35 MDT Message-ID: Sender: Keith Petersen From: Keith Petersen To: nep.pgelhausen@AMES-VMSB.ARPA Cc: max.hartman@ames-vmsb.ARPA, Info-Modem7@SIMTEL20.ARPA Subject: 1k protocol discussions ReSent-From: KPETERSEN@SIMTEL20.ARPA ReSent-To: Info-Cpm@AMSAA.ARPA ReSent-Date: Fri 9 Aug 1985 21:39-MDT Not being on the INFO-MODEM list, I am not privy to the discussion that was mentioned on the message forwarded to INFO-CPM, however I do have one question to ask: Does this one byte change to the header information (to select block size) make KMD incompatible with programs that currently support the XMODEM protocol? Any changes made to a protocol should be made in such a manner that the new editions may still work with previous versions, that may not know of the new feature. Could somebody please inform me about this? Does anyone think that I have a valid point? If not, why? ...and, what about Naomi? -Richard Hartman max.hartman@ames-vmsb The following message from CompuServe explains... Date: Tuesday, 6 August 1985 18:16-MDT From: CSTROM at SIMTEL20.ARPA Re: Protocol wars continue Paul Homchick thought there might be interest in this message: #: 142754 S0/Communications 03-Aug-85 08:44:29 Sb: #142740-#Yam & r Fm: Paul Homchick 71445,527 To: Pete Holsberg 70240,334 (X) I would have thought that my stance on the wars was quite clear by now, but at the risk of boring everyone to death, I'm going to state it one more time. (Hit Cntrl-O NOW to skip this, if you wish!!). At this point there is NO difference between the 1K implementations except for Irv's additions of another 'receiving handshaking character' the timing dependent nature of the initial handshake, and the difference between "S" and "SK". This is in variance from the YMODEM standard already implemented on MSDOS and UNIX systems. If the CP/M community adopts the KMD/IMP protocol, I think it will be very unfortunate for two reasons. 1) It adds complexity, outside of the checksum, to an already shakey protocol which reduces its suitability for use over timesharing systems and packet-switching networks. Also by adding ANOTHER handshaking character, it continues the bad precedent of the C, and invites further "improvements" via this extension mechanism, and further degradation. 2) The existence of a split between the MSDOS / UNIX & CP/M impementations helps to ensure that adoption of the 1K packet will not be widespread, and could hasten the end of XMODEM as a low-end standard by which everyone can transfer files. For reasons given in (1), the M-U world is not going to adopt KMD. For reasons which I can only characterize as well-meaning but shortsighted, sections of the CP/M community have not adopted YMODEM. As you note, the commercial protocols have not knocked each other out, but they HAVE kept any one of them from becoming standard. CP/M users are now in the minority of micro users, and it's going to get worse. I fear that KMD, with its CP/M Ostrich outlook, will be counter productive to widespread transfer of data via telecommunications. To me, it is evident that these are significant reasons for taking a strong stand. I hope it is clear that there is no hidden agenda here. 12-Aug-85 05:52:25-MDT,968;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Aug 85 05:52:18-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a027707; 12 Aug 85 7:25 EDT Received: from usenet by TGR.BRL.ARPA id a003621; 10 Aug 85 17:49 EDT From: jack%boring.uucp@BRL.ARPA Newsgroups: net.micro.cpm Subject: Looking for Z80 disassembler under CPM. Message-ID: <6570@boring.UUCP> Date: 10 Aug 85 21:03:22 GMT Apparently-To: rnews@mcvax.LOCAL To: info-cpm@AMSAA.ARPA I'm posting this for a friend who doesn't have net access, so please reply directly to him. -Jack. I'm looking for a Z80 disassembler or debugger that runs under CPM. I have one for the 8085, but it screws up badly as soon as a Z80-specific instruction is executed. Any pointers/sources/etc are welcomed. Tom Uyldert, mcvax!vu44!htsa!htsame!dzut (or, if you're lucky, dzut@htsame.UUCP) -- Jack Jansen, jack@mcvax.UUCP The shell is my oyster. 12-Aug-85 05:54:59-MDT,1091;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Aug 85 05:54:53-MDT Received: from ames-vmsb.arpa by AMSAA.ARPA id a027713; 12 Aug 85 7:25 EDT Date: 9 Aug 85 09:23:00 PDT From: nep.pgelhausen@AMES-VMSB.ARPA Subject: --- KMD vs. XMODEM --- To: info-cpm@AMSAA.ARPA Cc: info-modem7@simtel20.ARPA Reply-To: nep.pgelhausen@AMES-VMSB.ARPA Not being on the INFO-MODEM list, I am not privy to the discussion that was mentioned on the message forwarded to INFO-CPM, however I do have one question to ask: Does this one byte change to the header information (to select block size) make KMD incompatible with programs that currently support the XMODEM protocol? Any changes made to a protocol should be made in such a manner that the new editions may still work with previous versions, that may not know of the new feature. Could somebody please inform me about this? Does anyone think that I have a valid point? If not, why? ...and, what about Naomi? -Richard Hartman max.hartman@ames-vmsb ------ 12-Aug-85 06:19:10-MDT,989;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Aug 85 06:19:03-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id ab27707; 12 Aug 85 7:25 EDT Received: from usenet by TGR.BRL.ARPA id a008794; 11 Aug 85 2:50 EDT From: Roger Leisch Newsgroups: net.micro.cpm,net.micro.trs-80,net.wanted Subject: Wanted: Terminal Emulator Program for CPM system Message-ID: <116@butler.UUCP> Date: 9 Aug 85 17:31:54 GMT Xref: seismo net.micro.cpm:4763 net.micro.trs-80:378 net.wanted:7396 To: info-cpm@AMSAA.ARPA I am looking for a Public Domain program that will allow my TRS-80 computer running CPM/TRSDOS to emulate a Terminal. I am particular interested in a program that would emulate a DEC terminal, an have upload/download capabilites. Thanks in advance. Roger Leischner uucp: uw-beaver!uw-june!entropy!dataio!butler!leisch P.S. Does anyone Know what the SIMTEL20 directories are??? 12-Aug-85 06:25:35-MDT,2831;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Aug 85 06:25:21-MDT Received: from simtel20.arpa by AMSAA.ARPA id a027787; 12 Aug 85 7:26 EDT Date: Sat, 10 Aug 1985 22:09 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Modem7@SIMTEL20.ARPA Cc: Info-Cpm@AMSAA.ARPA Subject: Kim praises Irv The following file HOFFGOOD.TXT was found on the RCPM Sysops Clearinghouse system Saturday night. It is presented here without comment. --Keith Re: Hoff's extensions to the 1k protocol Date: 8/6/85 From: pst I am writing this in support of the Hoff extensions to the 1k protocol. Separately, Paul Homchick and Irv Hoff developed 1k protocol for XMODEM. Irv called his new program KMD, Paul kept the XMODEM line going. Many of you know me personally, and know that Irv and I have a complementary/competitive attitude towards our respective programming projects. This should make my comments reasonably objective. I have tried every XMODEM protocol program available for CP/M and --MANY-- MS-DOS programs, and they are all (except for one exception) completely compatible with the Hoff extensions. 1) The Hoff extensions work. 2) They work well. [i.e. they are transparent to non-compatible programs] 3) If you are running IMP, 1k protocol transfers become automatic. 4) It is my dream that Ron Fowler add the extensions to Mex115, but that's up to him. I think this all-arround competition has brought about some really nice additions to RCP/M software. 1) The Christensen/Forsberg/Hoff 1k protocol 2) The Hoff extensions to the 1k protocol 3) The Traina Bye-BDOS calls in Bye337 Unfortunately, we have a disadvantage now. There is great confusion about XMODEM/BYE3 and KMD/BYE5. The problem is that these sets of programs are functionally identical (or will be as soon as the Hoff/Masters team releases BYE501/KMD04 which use my Bye-BDOS idea). There are minor differences between the XMODEM/BYE3 and KMD/BYE5 series, but they are identical from a user's standpoint. We have programs that are duplicates, the next step is to merge the best of XMODEM/BYE3 and KMD/BYE5 into a single group of programs again. However, none of us (the authors) should be the ones to make the merge, because we have different ideas all want things done our _own_ way, which was one of the causes of the "big split" to begin with. I will be more than happy to assist some individual in merging this software, but I will not do it myself, because I feel it would just continue the split between KMD/BYE5 and XMODEM/BYE3. Any volenteers? pst / Saratoga OxGate 408/354-5934 300/1200/2400 baud 12-Aug-85 07:17:59-MDT,719;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Aug 85 07:17:52-MDT Received: from simtel20.arpa by AMSAA.ARPA id a027806; 12 Aug 85 7:26 EDT Date: Sat, 10 Aug 1985 22:21 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: "Frank J. Wancho" Cc: Info-Modem7@SIMTEL20.ARPA, Info-Cpm@AMSAA.ARPA Subject: Kim praises Irv In-reply-to: Msg of 10 Aug 1985 22:12-MDT from Frank J. Wancho Keith, I *thought* "pst" was Paul S. Traina. Who is "Kim"? --Frank Yes, you're right. My error. Too late at night. --Keith 12-Aug-85 07:33:16-MDT,1182;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Aug 85 07:33:06-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id aa27707; 12 Aug 85 7:29 EDT Received: from usenet by TGR.BRL.ARPA id a004861; 12 Aug 85 6:40 EDT From: Miriam Clifford Newsgroups: net.micro.cpm Subject: Re: 8085 assembler Message-ID: <197@ecsvax.UUCP> Date: 10 Aug 85 10:00:23 GMT To: info-cpm@AMSAA.ARPA > In reference to James Jokl's message, I'm trying to resurrect an Imsai 8085 > based system, so any information re an 8085 assembler, I too, would appreciate. > I am not an assembler programmer, so am not too sure about my comments, but--- The Zenith Z100 (not the Z150 Z100 PC) has CPM on an 8085 as well as msdos. Therefore, I would think that the assmebler instructions that come with that machine would have the 8085 version. If you can't get it closer, I probably have it somewhere in the documentation that came with my machine. Or talk to a Heath/Zenith dealer. {decvax,ihnp4,akgua}!mcnc!ecsvax!dmimi Mimi Clifford 2535 Sevier St Durham, NC 27705 919-489-4821 919-684-2854 (Wed) 12-Aug-85 08:58:45-MDT,970;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Aug 85 08:58:38-MDT Received: from csnet-pdn-gw by AMSAA.ARPA id a004300; 12 Aug 85 10:24 EDT Received: from gmr by csnet-relay.csnet id ac13767; 12 Aug 85 10:14 EDT Date: Mon, 12 Aug 85 09:55 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: HD64180 Does anyone know if any vendors are working on S-100 boards using the new Hitachi HD64180 microprocessor? It seems like a natural for either CP/M Plus or Z-system. It runs 8080 or Z-80 machine code, has on-chip serial I/O, DMA controller, and programmable timers, and memory management for a 512K memory address space. It should reasonably make a single board computer and a full-feature S-100 bus board with RAM, ROM, serial I/O, and a floppy disk controller. Bob Haar G.M. Research Labs 12-Aug-85 12:19:02-MDT,840;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 12 Aug 85 12:18:54-MDT Received: from simtel20.arpa by AMSAA.ARPA id a010447; 12 Aug 85 13:30 EDT Date: Mon 12 Aug 85 11:30:25-MDT From: Rick Conn Subject: Re: HD64180 To: haar%gmr.csnet@CSNET-RELAY.ARPA cc: info-cpm@AMSAA.ARPA In-Reply-To: Message from "haar%gmr.csnet@CSNET-RELAY.ARPA" of Mon 12 Aug 85 08:58:47-MDT Message-ID: <12134574839.9.RCONN@SIMTEL20.ARPA> Yes, I have heard rumors which I believe to be true about Quadram coming out with an S-100 board which is based on the 64180. It is running the Z System, and I am supposed to see it in a month or so. More on that later. Also, look at the recent Echelon newsletters. I think you will find hints/more info dropped here. Rick ------- 13-Aug-85 05:23:04-MDT,2079;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 13 Aug 85 05:22:56-MDT Received: from simtel20.arpa by AMSAA.ARPA id a022405; 13 Aug 85 6:59 EDT Date: Mon, 12 Aug 1985 20:44 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: Revised quick reference list to Simtel20 CP/M directories Quick reference list to SIMTEL20's MICRO: directories as of Aug. 12, 1985 (where 'x' is one of the names below): 22RSX COMND GENASM MSOFT SYSLIB3 6502 CPM3 GENCOM NEWS SYSUTL AMETHYST CPM86 GENDOC NSTAR T20-SQUSQ APPLE CPMLIB HAMMING OSBORN TERM ASMUTL CPR86 HAMRADIO PACKET TOPS-20 ATARI CUG HDUTL PASCAL TRS-80 AZTEC-C DBASEII HEATH PCDOS TURBODOS BASIC DEBUG HELP PILOT80 TURBOPAS BDOS DIRUTL HEX PLOT33 TXTUTL BDSC-1 DISASM IBM-PC PPSPEL VAXVMS BDSC-2 DISKPLOT IMP PUBKEY VDOEDIT BDSC-3 DSKBUF INSIDCPM PUBPATCH VOICE BDSC-4 DSKUTL KAYPRO RBBS WSTAR BSTAM EDITC80 LIST RBBS4 XCCP BYE3 EDITOR MACLIB RCPM XLISP BYT85FEB EMX MATH ROS YAM BYT85JAN EPSON MBBS SMALLC21 Z3LIBS C80 EZCPR MEMTEST SORT Z3NEW CATLOG FAST2 MEX SPELL ZCPR CB80 FIDO MICNET SQU-PORT ZCPR2 CBIOS FILCPY MISC SQUSQ ZCPR3 CCP FILUTL MODEM STARTER-KIT COBOL FORTH-83 MODEM2 SUBMIT COMMODORE FORTRAN MODEM7 SYSLIB 13-Aug-85 05:26:21-MDT,1696;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 13 Aug 85 05:26:15-MDT Received: from simtel20.arpa by AMSAA.ARPA id a022421; 13 Aug 85 7:00 EDT Date: Mon, 12 Aug 1985 20:58 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: max.hartman@ames-vmsb.ARPA Cc: Info-Cpm@AMSAA.ARPA, Info-Modem7@SIMTEL20.ARPA Subject: 1k protocol discussion Thanks for sending the msg intended to answer my question....it was written poorly enough, though, that my main question (compatability w/ versions not incorporating the extension) remained unanswered. A seperate message that you later sent to info-cpm in general (as well as modem7), HOFFGOOD.TXT, cleared this up. Thanks for your help. In HOFFGOOD.TXT, they ask for help w/ the merge, and give phone #...does this person have an arpa address? if so, could you send it to me? Thanks again, -Richard Hartman max.hartman@ames-vmsb That person is not on the net. However, the various versions of XMDM (XMODEM) have been merged and are now available as: Filename Type Bytes CRC Directory MICRO: XMDM116.LBR.1 BINARY 99200 D27AH The various versions ARE compatible with MODEM2, MODEM7, MODM700, MEX, YMODEM (YAM), etc. However, the receiving end if assembled to use Hoff's "C" pause "K" approach may cause the sender to time out one or two times, making some people think the protocol is broken. This only happens on the first record - after that the receiving end sends ACK/NAK as the case may be. --Keith 13-Aug-85 06:10:03-MDT,1242;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 13 Aug 85 06:09:54-MDT Received: from simtel20.arpa by AMSAA.ARPA id a022449; 13 Aug 85 7:01 EDT Date: Mon, 12 Aug 1985 21:29 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Modem7@SIMTEL20.ARPA, Info-Cpm@AMSAA.ARPA Subject: 1k protocol doc [Is there] any other documentation you might have concerning the 1K protocol extension? We have added it to ASCII Pro (IBM) with a couple of variations and want to make sure that it is fully compatible with "the specs". Thanks. --Bill Blue Yes, Chuck Forsberg revised his original YMODEM.DOC file, adding a table of contents, etc. It's now available from SIMTEL20 as: Filename Type Bytes CRC Directory MICRO: XYMODEM.DQC.1 BINARY 27776 6394H ...or for those who don't have a way of UnSQueezing: Directory MICRO: XYMODEM.DOC.1 ASCII 43645 8113H --Keith Petersen Arpa: W8SDZ@SIMTEL20.ARPA uucp: ...!{decvax,unc,hao,cbosgd,seismo,aplvax,uci}!brl-bmd!w8sdz uucp: ...!{ihnp4!cbosgd,cmcl2!esquire}!brl-bmd!w8sdz 13-Aug-85 06:15:21-MDT,1441;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 13 Aug 85 06:15:12-MDT Received: from simtel20.arpa by AMSAA.ARPA id a022455; 13 Aug 85 7:01 EDT Date: Mon, 12 Aug 1985 21:46 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: decvax!mcvax!vu44!htsa!htsame!dzut@UCB-VAX.ARPA Cc: Info-Cpm@AMSAA.ARPA Subject: Looking for Z80 disassembler under CPM. I'm looking for a Z80 disassembler or debugger that runs under CPM. I have one for the 8085, but it screws up badly as soon as a Z80-specific instruction is executed. Any pointers/sources/etc are welcomed. Yes, Rick Conn write ZDASM, a Z80 disassembler, some time ago. It's available from SIMTEL20 as: Filename Type Bytes CRC Directory MICRO: ZDASM15.LBR.1 BINARY 77440 6DB4H If you are unable to access Simtel-20 because of network restrictions please remember that MOST of the new files announced to Info-Cpm are also available on my RCPM Royal Oak (MI) which may be accessed at 300 baud using the 103a modem mode or 1200 baud using either the 212a or Vadic 3400 modes. The telephone number is (313) 759-6569. --Keith Petersen Arpa: W8SDZ@SIMTEL20.ARPA uucp: ...!{decvax,unc,hao,cbosgd,seismo,aplvax,uci}!brl-bmd!w8sdz uucp: ...!{ihnp4!cbosgd,cmcl2!esquire}!brl-bmd!w8sdz 13-Aug-85 06:44:22-MDT,2745;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 13 Aug 85 06:44:04-MDT Received: from simtel20.arpa by AMSAA.ARPA id a022467; 13 Aug 85 7:02 EDT Date: Mon, 12 Aug 1985 22:13 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: Ward Christensen comments on protocol wars The following is a message from Ward taken from Compuserve's CP/M sig. #: 143664 S0/Communications 10-Aug-85 16:05:46 Sb: #143226-#protocol wars Fm: Ward Christensen 76703,302 To: Irv Hoff 72365,70 (X) Then you said 'The new "K" addition opens the door for expanding into tomorrow's technology, by replacing the "K" with say a "N" for 9600 baud use with say 2k or even 4k packet sizes.". Sorry, I frowned so much reading this that my eyebrows touched in the middle. Thank goodness Charlie Strom jumped in saying " Since these characters are not in the error-detection routine ... don't you have any concern that adding still more possibilities will make the protocol more fragile?" You blew me away with your reply: "None whatsoever, Charlie, you (and Ron Fowler) are likely overlooking the fact those protocol characters are never sent once the first record is sent. There is no more liklihood that would be "more fragile" than the current method of requiring a "C" or "NAK" prior to the first record being sent, in my evaluation." Gad, I'm getting to the point where no matter how much I want to do all this via CIS, I'm tempted to call you on the phone and scream! How can you not see, that the addition of characters that aren't checked, is not opening the door to more and more errors! I curse myself for initially doing single-char ACK/NAK/EOT. Then the opening was invented by someone (who?) - and not a bad idea. "C" naking was a hack, and obviously it doubled the chances of having the "protocol selection" hosed up, i.e. a 'glitch' that looks like a C or a NAK; now a glitch that looks like a C or nak or K, is bad. You seem to think adding "N" and more chars is "perfectly OK". If you'd said "I realize 'K' naking is a HACK, and while it opens the door to more problems, the benefits far outweigh them", THEN I'd be on your side, and Fowler and Homchick wouldn't be calling me to beg me to take the "anti-K side". I am willing to "bless the K-nak", as yet another hack whose side effects are not significant enough to warrant throwing it away. Please just don't smoke whatever you smoke when you rationalize that it is GOOD, and extendable into the future! It may not make YOUR brain hurt, but it sure makes MINE hurt! 13-Aug-85 07:38:01-MDT,739;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 13 Aug 85 07:37:57-MDT Received: from usc-isi.arpa by AMSAA.ARPA id a028065; 13 Aug 85 8:53 EDT Date: 12 Aug 1985 22:10:39 EDT Subject: HD64180 boards From: Rex Buddenberg To: info-cpm@AMSAA.ARPA cc: BUDDENBERGRA@USC-ISI.ARPA I've heard nothing about S-100 boards, but at the MicroCornucopia SOC a couple weeks ago, Hiroshi Katayama was showing a single board computer which had so much on it that someone asked where the kitchen sink was... In addition to the stuff already mentioned was X.25 support (HDLC etc). Somebody mentioned Kaypro competition... It would fit in the lunchpail. b ------- 13-Aug-85 08:26:06-MDT,5264;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 13 Aug 85 08:25:43-MDT Received: from mitre.arpa by AMSAA.ARPA id a000336; 13 Aug 85 9:38 EDT Received: by mitre.ARPA (4.12/4.7) id AA06698; Tue, 13 Aug 85 09:09:13 edt Message-Id: <8508131309.AA06698@mitre.ARPA> To: info-cpm@AMSAA.ARPA Subject: What are the Simtel20 Archives Date: 13 Aug 85 09:05:30 EDT (Tue) From: Jeff Edelheit It seems that it is time to run this blurb again for the benefit of the newer Usenetters. For those of us who have seen this note before, I appologize for cluttering-up your inbox. "How can a user of a USENET host access the public domain microcomputer software collection on the DDN/MILNET host SIMTEL20" is being asked with increasing frequency as that software collection continues to grow. Unfortunately, direct access is not possible as there is no UUCP gateway for file transfer between SIMTEL20 (running TOPS-20) and a USENET host (as there is for electronic mail). (DDN, formerly known as ARPANET, is the Defense Data Network. DDN, along with Arpanet, SATNET, SRINET, etc. are all members of a TCP/IP protocol-based, multiple gateway network called InterNet.) USENET has been built on adjacent hosts voluntarily agreeing to store-and-forward relatively short messages across the USENET over dialup lines at 300 or 1200 bps. In the past, helpful InterNet users would fetch the file(s) requested and then e-mail them to the requestor. However, it has been pointed out that large file transfers disrupt the service, delay the shorter messages, and generate unacceptably large phone bills, all of which add up to threaten the tenuous connections that some USENET hosts can barely afford to have. Therefore, we have been asked to encourage InterNet users not to pass archive programs this way. Now for the good news. Some InterNet users, if sent a suitable disk, will download files and return mail the floppy to the requestor. To find a friendly InterNet user, send a message to INFO-CPM at DDN host AMSAA.ARPA via net.micro.cpm identifying your disk format and your request. Usually, someone will respond and come to your aid. If not, don't be bashful, wait a week and try again. But please remember, any such arrangements are strictly between you and your respondent. This is not, repeat NOT, a service of either the InterNet or INFO-CPM. If the above arrangement is inconvenient, or doesn't work, here are several other sources for public domain software. ---------------------------------------------------------------------- Information (and prices) are subject to change without notice. A volume is usually one floppy disk. 1. CP/M User's Group The CP/MUG volumes are available from: CP/M User's Group 1651 3rd Avenue New York, NY 10028 Current volumes are numbered 1 through 92 at $13 per 8" SSSD disk (Northstar format also available). The catalog is $6. 2. Special Interest Group/Microcomputers (SIG/M) The SIG/M volumes are distributed by: SIG/M Amateur Computer Group of New Jersey, Inc. Box 97 Iselin, NJ 08830 Current volumes are numbered 000 through 172. The first disk is $6.00 and $5.00 for each additional disk. The catalog is $2. 3. New York Amateur Computer Club PC-BLUE software volumes for the IBM-PC are available from: S-100, CP/M User Group The New York Amateur Computer Club P.O. Box 106 Church Street Station New York, NY 10008 The documentation files from the SIG/M and CPMUG volumes are available in hardcopy form, grouped into "books", from the NYACC. Each book is priced at $10 including shipping, $15 for overseas airmail. All orders must be prepaid. 4. PicoNet CP/M Users Group PicoNet, CP/MUG, and SIG/M software volumes are available from: PicoNet P.O. Box 391566 Mountain View, CA 94039 Available in 8" and most 5 1/4" soft sector only at $6.00 per disk plus $1.50 shipping per order. California residents add 6.5% sales tax. Quantity discounts are available. 5. Other sources: Compuserve Information Service is another source of public domain software. There are a number of special interest groups (SIGs) devoted to specific hardware as well as CP-MIG, the generic CP/M SIG, a repository for a large quantity of public domain software downloadable by the Compuserve file transer protocol (Christensen protocol is expected by late summer, 1984). There is no charge for access to CP-MIG other than the standard CIS connect charges, and Compuserve can be accessed through their own communications network or through Tymnet. ... and many Remote CP/M (RCPM) systems around the country, where software is available for downloading for the price of a phone call. The May 1984 issue of Microsystems contains the full listing of known RCPMs at the time of publication. I would like to thank Dave Towson, Frank Wancho and Charlie Strom for all their assistance in putting this blurb together. If anybody out in InterNet Land has any questions or comments about the above blurb, feel free to contact any one of us. Jeff Edelheit (edelheit at mitre) 13-Aug-85 09:00:53-MDT,1488;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 13 Aug 85 09:00:44-MDT Received: from brl-aos.arpa by AMSAA.ARPA id a002962; 13 Aug 85 10:25 EDT Received: from mit-multics.arpa by AOS.BRL.ARPA id a004647; 13 Aug 85 10:24 EDT Date: Tue, 13 Aug 85 10:16 EDT From: Bakin@MIT-MULTICS.ARPA Subject: RE: This is serious! To: Info-CPM@BRL.ARPA Message-ID: <850813141649.427852@MIT-MULTICS.ARPA> Hey, this really is serious! The following is a brief article from the August 1985 AdaData newsletter: ----- VLSI Circuits Too Small to Endure? A report in the June issue of the Journal of Defense & Diplomacy states that the lightweight conductors used in very large-scale integrated circuits may be getting too small to withstand the stresses of carrying current. JODD says that even the tiny flow of electricity passing through a chip may be sufficient to displace an aluminum circuit's individual molecules in the same way that traffic can turn an uneven roadway into a streat of potholes. But while the road is usually able to continue to carry its load, the same may not be true of the microscopic conductor, which could actually end up breaking. The magazine therefore recommends that military chip suppliers use heavier metals like tungsten, for which Sandia National Laboratories (Albuquerque, NM) is developing a two-stage vapor deposition process. ----- -- Dave (Bakin -at mit-multics.ARPA) 13-Aug-85 09:15:55-MDT,552;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 13 Aug 85 09:15:49-MDT Received: from brl-aos.arpa by AMSAA.ARPA id aa02962; 13 Aug 85 10:25 EDT Received: from mit-multics.arpa by AOS.BRL.ARPA id a004665; 13 Aug 85 10:25 EDT Date: Tue, 13 Aug 85 10:20 EDT From: Bakin@MIT-MULTICS.ARPA Subject: RE: My last message To: Info-CPM@BRL.ARPA Message-ID: <850813142021.954265@MIT-MULTICS.ARPA> Sorry about that -- wrong list. It should have gone to info-micro. -- Dave (bakin -at mit-multics) 13-Aug-85 13:38:11-MDT,1410;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 13 Aug 85 13:38:02-MDT Received: from simtel20.arpa by AMSAA.ARPA id a013115; 13 Aug 85 14:42 EDT Date: Tue 13 Aug 85 12:42:29-MDT From: Rick Conn Subject: Re: HD64180 boards To: BUDDENBERGRA@USC-ISI.ARPA cc: info-cpm@AMSAA.ARPA In-Reply-To: Message from "Rex Buddenberg " of Mon 12 Aug 85 22:10:39-MDT Message-ID: <12134850102.7.RCONN@SIMTEL20.ARPA> I'm working on an SB180 board (Steve Ciarcia's design) now. SUPER board. This 7 1/2" by 4" SBC has an HD64180, 256K bytes RAM, 2 RS-232C drivers, 1 parallel port, and a floppy disk controller for 3 1/2", 5 1/4", and 8" floppies. All running the Z System with a RAM disk. Clock speed is 6+ MHz. Note that by using the HD64180, the HD64180 ALONE has 64 I/O ports internally, providing 2 UARTs (RS-232C line drivers are off-chip), one clocked serial port, 2 timers/counters, 2 DMA controllers (mem-to-mem, mem-to-io, and mem-to-mem-mapped-io transfers), and a 12-level priority interrupt controller. Most impressive. Finally, the new Echelon ZAS assembler (a Z System tool) assembles the extended instructions for the 64180, and the ZDMH debugger helps debug, recognizing 64180 instructions. So there is a toolset to support 64180 development available now as well. Rick ------- 14-Aug-85 06:06:11-MDT,1284;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 14 Aug 85 06:06:05-MDT Received: from brl-aos.arpa by AMSAA.ARPA id a024021; 14 Aug 85 7:31 EDT Received: from mit-mc.arpa by AOS.BRL.ARPA id a018321; 13 Aug 85 19:12 EDT Received: from WISCVM.ARPA by MIT-MC.ARPA 13 Aug 85 19:10:05 EDT Received: from (ZDV626)DJUKFA11.BITNET by WISCVM.ARPA on 08/13/85 at 18:09:33 CDT Date: Tue, 13 Aug 85 21:43:37 cet To: INFO-CPM@MIT-MC.ARPA From: ZDV626%DJUKFA11.BITNET@WISCVM.ARPA Subject: Date: Tue, 13 Aug 1985 21:20 cet From: Eberhard W. Lisse To: info-cpm@mit-mc.arpa Subject: cp/m-bulletin board Hi, I have been given your mailing adress by gubbins@radc-tops20.arpa. If you have a similar mailing list, could you please include me in it. I'm a senior in the Technical University of Aachen Medical School and as we have been hooked into BITNET, I have been volunteered by the German cp/m ( Sorry, some of my capital keys seem not to work properly) user group to look into it. Do you distribute public domaine software ? If yes, could you send me a list ? Is it possible to get back issues of your digests ? Thanks in advance, el 14-Aug-85 12:03:39-MDT,2024;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 14 Aug 85 12:03:29-MDT Received: from simtel20.arpa by AMSAA.ARPA id a012326; 14 Aug 85 13:08 EDT Date: Wed 14 Aug 85 11:08:50-MDT From: Rick Conn Subject: Re: HD64180 boards To: RFOWLER@SIMTEL20.ARPA cc: info-cpm@AMSAA.ARPA, info-micro@AMSAA.ARPA In-Reply-To: Message-ID: <12135095197.22.RCONN@SIMTEL20.ARPA> Hi, Ron, I'm afraid your rumors are true. The 64180 has an on-chip MMU which provides the memory management. This is accessed via on-chip I/O ports and the special set of 64180 I/O instructions. I haven't found this to be a problem yet. SW-wise, you init the MMU, defining the 64K memory banks to have 0, 1, or 2 common banks (common to all memory 64K memory banks) and 1 base bank (unique to each 64K memory bank). Switching banks is like loading a segment register, wherein you output any of the standard registers or (HL) to the MMU for the selection. The resolution of the common and base banks is to 4K, but that does not stop you from having a 63K+ TPA. I really like the 64180, but a problem came up last night which really bothered me. One of the two UARTS onchip (which I am using to connect to a Smartmodem) pays attention to the DCD line. You can sense this line internally thru a port. However, if DCD drops off (no carrier), then the Transmitter section of the UART is disabled! Ban news! No more comm to the Smartmodem for dialing the phone, answering the phone, hanging up the phone, etc. You can, of course, set the switch on the Smartmodem to keep DCD true (reverse logic, so 0 actually), but then you can't use DCD to detect loss of user signal. There is a way around this problem for the Ciarcia board, but I can't talk until Nov or so for reasons of confidence. Ciarcia will have a project on this option in Dec Byte. If Steve says I can talk earlier, I will. Rick ------- 15-Aug-85 05:45:38-MDT,1125;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 15 Aug 85 05:45:28-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id aa02558; 15 Aug 85 7:13 EDT Received: from usenet by TGR.BRL.ARPA id a011462; 14 Aug 85 22:50 EDT From: "Lee B Grey, Programmer Extraordinaire" Newsgroups: net.micro.cpm Subject: Re: DBASE II Message-ID: <647@gitpyr.UUCP> Date: 12 Aug 85 22:21:59 GMT To: info-cpm@AMSAA.ARPA > Last I heard there was no dBase II compiler, but there was a version > available from Ashton-Tate specifically for people in your position. There is something called DBCompiler. It's fairly nice, but, last time I looked at it, it did not have the capability of compiling programs which utilized the macro (&) function. It seemed fairly simple to add this capability. It is possible that they have, by now. Also, a company called Fox & Geller puts out some utilities which, I believe, include a dBASE compiler. I know for a fact that there ARE ways to get your dBASE code compiled. Just hunt around. Lee Grey 15-Aug-85 05:52:08-MDT,1744;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 15 Aug 85 05:52:02-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id ac02558; 15 Aug 85 7:13 EDT Received: from usenet by TGR.BRL.ARPA id a013599; 15 Aug 85 0:12 EDT From: "Richard L. Klappal" Newsgroups: net.micro.cpm Subject: Re: how to execute programs from within cpm programs Message-ID: <124@wlcrjs.UUCP> Date: 11 Aug 85 05:52:56 GMT To: info-cpm@AMSAA.ARPA In article <946@sdcsla.UUCP> hestenes@sdcsla.UUCP (Eric Hestenes) writes: >Can anyone give me a hint as to how someone would call one program, >say WORDSTAR or something simpler, from within another program. > >Methods using Turbo Pascal, 'C' or assembler would be useful. Both AZTEC (MANX) and BDS C support the 'exec' statement or an equivalent, that allow a program to call another. NOTE: These calls are NOT forks, so you cannot return to the original program. I believe both systems supply enough of the source to show how it is done. (if I remember correctly, the file name of the new program is stored in the BDOS buffer (?at BDOSBASE+8 (?)), and a couple of pointers need to be set up pointing to the start and end of the filename. If this is not enough help, send me mail, and I will try to look up the details. Richard Klappal UUCP: ..!ihnp4!wlcrjs!uklpl!rlk | "Money is truthful. If a man MCIMail: rklappal | speaks of his honor, make him Compuserve: 74106,1021 | pay cash." USPS: 1 S 299 Danby Street | Villa Park IL 60181 | Lazarus Long TEL: (312) 620-4988 | (aka R. Heinlein) ------------------------------------------------------------------------- 15-Aug-85 06:16:59-MDT,1532;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 15 Aug 85 06:16:47-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a002558; 15 Aug 85 7:13 EDT Received: from usenet by TGR.BRL.ARPA id a014150; 15 Aug 85 0:28 EDT From: Hugh Redelmeier Newsgroups: net.micro.cpm Subject: Osborne I software portability Message-ID: <1214@hcrvx1.UUCP> Date: 7 Aug 85 15:43:41 GMT To: info-cpm@AMSAA.ARPA I just bought three pieces of Osborne I software (issued by Osborne itself), hoping to run them on my Kaypro II. The programs should be generic CP/M because they do not require bypassing the operating system. And yet two out of the three don't work. Is it the case that Osborne hobbled its software to prevent it to run on other brands of machines? If so, how did they do it? Note: the software is not the bundled stuff that came with an Osborne. The two packages are MuSimp/MuMath (Soft Warehouse's symbolic algebra package), and Bascom (Microsoft's BASIC compiler). I bought new copies, still shrinkwrapped, from an Osborne dealer (they were very old stock). Nothing in the license seems to preclude running on a Kaypro. Symptoms: MuSimp: Whenever a "RECLAIM();" is executed, the system crashes. Usually the machine locks up, but sometimes it gets a BDOS error, indicating some kind of wild jump. BASCOM: BASCOM loads and then immediately does a warm boot. Hugh Redelmeier (416) 922-1937 {utzoo, ihnp4, decvax}!hcr!hugh 15-Aug-85 06:21:42-MDT,1132;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 15 Aug 85 06:21:30-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id ab02558; 15 Aug 85 7:13 EDT Received: from usenet by TGR.BRL.ARPA id a014154; 15 Aug 85 0:28 EDT From: Hugh Redelmeier Newsgroups: net.micro.cpm Subject: CP/M directory information Message-ID: <1215@hcrvx1.UUCP> Date: 7 Aug 85 16:04:52 GMT To: info-cpm@AMSAA.ARPA While examining the directory on some Osborne I disks, I noticed a couple of things that puzzled me. The first extent of some files (they seemed to be big ones) was sometimes numbered one, instead of zero (the number of the extent is in the field named "ex", at offset 12). Why? Is this legal? The record count field was not an exact record count for the extent (nor could it be). The record count is constrained to be in the range 0 through 128, but an extent can hold up to 256 records. What are the rules for resolving this? The CP/M manual does not seem to discuss this. Hugh Redelmeier (416) 922-1937 {utzoo, ihnp4, decvax}!hcr!hugh 15-Aug-85 06:43:42-MDT,1082;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 15 Aug 85 06:43:36-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id ad02558; 15 Aug 85 7:13 EDT Received: from usenet by TGR.BRL.ARPA id a015903; 15 Aug 85 1:15 EDT From: Dan Winkler Newsgroups: net.micro.cpm Subject: Identifying Simtel20 Files? Message-ID: <299@harvard.ARPA> Date: 13 Aug 85 21:30:03 GMT To: info-cpm@AMSAA.ARPA How do you tell what all those interesting looking files on Simtel20 are? Does anyone have descriptions of them? I'm interested in any public domain languages that might be there. I haven't found any yet. I'm using an Otrona Attache, by the way. I have a Pascal program written on an Apple II with UCSD Pascal that I want to run on my Attache. It seems a shame to buy a compiler to compile a single program, but if I can't find any public domain language that is reasonably similiar to Pascal (even basic would be OK), that's what I'll have to do. Any recommendations for a CP/M Pascal? Thanks! 15-Aug-85 06:47:12-MDT,648;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 15 Aug 85 06:47:04-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id ae02558; 15 Aug 85 7:13 EDT Received: from usenet by TGR.BRL.ARPA id a016447; 15 Aug 85 1:31 EDT From: WhiteR Newsgroups: net.micro.cpm Subject: Question on how to acess SIMTEL20 Message-ID: <1149@druxm.UUCP> Date: 12 Aug 85 14:39:05 GMT To: info-cpm@AMSAA.ARPA How do you read files out of the SIMTEL20 MICRO:CPM(x) directories to another location on the net? Iam interested in the AZTEC-c and TURBO directories. Thank you in advance. 15-Aug-85 07:17:24-MDT,2962;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 15 Aug 85 07:17:10-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id af02558; 15 Aug 85 7:13 EDT Received: from usenet by TGR.BRL.ARPA id a019529; 15 Aug 85 3:02 EDT From: "Richard L. Klappal" Newsgroups: net.micro.cpm Subject: Re: Osborne I software portability Message-ID: <129@wlcrjs.UUCP> Date: 13 Aug 85 00:32:43 GMT Keywords: unlocking it To: info-cpm@AMSAA.ARPA In article <1214@hcrvx1.UUCP> hugh@hcrvx1.UUCP (Hugh Redelmeier) writes: >I just bought three pieces of Osborne I software (issued by Osborne >itself), hoping to run them on my Kaypro II. The programs should be >generic CP/M because they do not require bypassing the operating >system. And yet two out of the three don't work. Is it the case that >Osborne hobbled its software to prevent it to run on other brands >of machines? If so, how did they do it? > >Note: the software is not the bundled stuff that came with an Osborne. >The two packages are MuSimp/MuMath (Soft Warehouse's symbolic algebra >package), and Bascom (Microsoft's BASIC compiler). I bought new copies, >still shrinkwrapped, from an Osborne dealer (they were very old stock). >Nothing in the license seems to preclude running on a Kaypro. > >Symptoms: > >MuSimp: Whenever a "RECLAIM();" is executed, the system crashes. > Usually the machine locks up, but sometimes it gets a BDOS error, > indicating some kind of wild jump. >BASCOM: BASCOM loads and then immediately does a warm boot. > >Hugh Redelmeier (416) 922-1937 >{utzoo, ihnp4, decvax}!hcr!hugh I also ran into the same problem taking BASCOM from the Os1 to CP/M on a co-processor board in a Fortune 32:16. Fix is as follows (and probably the same for Mu*). Using ddt (or preferferably zsid) trace execution through the init sequence of the program. Very shortly after starting, the program will jump above 4000H. trace that code, looking for a section of about 32 bytes, beginning with a DI (disable interrupts) and ending with EI (enable interrupts). This section of code does a bank switch, and verifies that there is ROM at 0100H. replace this 32 bytes of code with 00h, exit and save the image. Works for me. For the record, Drive B on the Os died again, so I am only using the software on one CPU (albeit a Z80B, running as a task under UNIX on a 68K). Who says you can't do what you want? (The MIMIX (tm) software even lets me use vi as the replacement for CP/Ms ED.) Richard Klappal UUCP: ..!ihnp4!wlcrjs!uklpl!rlk | "Money is truthful. If a man MCIMail: rklappal | speaks of his honor, make him Compuserve: 74106,1021 | pay cash." USPS: 1 S 299 Danby Street | Villa Park IL 60181 | Lazarus Long TEL: (312) 620-4988 | (aka R. Heinlein) ------------------------------------------------------------------------- 15-Aug-85 07:18:04-MDT,1608;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 15 Aug 85 07:17:55-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id ag02558; 15 Aug 85 7:14 EDT Received: from usenet by TGR.BRL.ARPA id a020712; 15 Aug 85 3:42 EDT From: Chuck Forsberg WA7KGX Newsgroups: net.micro.cpm Subject: Re: Protocol Wars Message-ID: <215@omen.UUCP> Date: 12 Aug 85 20:01:22 GMT To: info-cpm@AMSAA.ARPA The main weakness in the Hoff protocol is the dependence on timing of the C-K sequence. If timesharing systems, error correcting modems, and/or packet switch networks are involved, two characrers sent back to back can arrive at the other end separated by several seconds, and vice versa. With the advent of PC-PURSUIT which allows virtually unlimited night calling within 12 cities local call areas for a $25/month flat fee, these considerations may be upon us sooner than we think. The YMODEM protocol, wherein the block size is specified to the sender (SK for 1k, S for 128) has been in use for several years on a multitude of micro, mini, and mainframe computers and does not have this weakness. Working between two sngle process micros, with standard modems and phone lines, the Hoff protocol works well enough for CP/M use. -- Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf CIS:70715,131 Omen Technology Inc 17505-V NW Sauvie Island Road Portland OR 97231 Voice: 503-621-3406 Modem: 503-621-3746 (Hit CR's for speed detect) Home of Professional-YAM, the most powerful COMM program for the IBM PC 15-Aug-85 08:29:03-MDT,1044;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 15 Aug 85 08:28:55-MDT Received: from simtel20.arpa by AMSAA.ARPA id a003314; 15 Aug 85 7:23 EDT Date: Thu 15 Aug 85 00:31:43-MDT From: Rick Conn Subject: Documentation (Notes) on HD64180 To: info-cpm@AMSAA.ARPA cc: info-micro@AMSAA.ARPA Message-ID: <12135241358.10.RCONN@SIMTEL20.ARPA> In light of the interest in the HD64180 chip, I have placed a copy of my presentation foils on the HD64180 in: MICRO:HD64180.WS While they are sketchy (and designed for a presentation), they contain a lot of summary information, including the instructions extended beyond the Z80, how the memory management unit works, how the various interrupt modes work, etc. For those of you in the Dallas area, I'm giving this presentation tonight (15 Aug) at the Metroplex CP/M Interest Group meeting at Dealy (sp?) Recreation Center. These are the foils for the presentation. Enjoy! Rick ------- 15-Aug-85 10:35:30-MDT,2711;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 15 Aug 85 10:35:19-MDT Date: Thu, 15 Aug 85 11:41:22 EDT From: David Towson (SECAD) To: info-cpm@AMSAA.ARPA, info-micro@brl.ARPA Subject: Microprocessors Unlimited, an extraordinary company: Fellow hardware hackers - I was interested in some recent postings concerning Microprocessors Unlimited in Beggs, Oklahoma, (918) 267-4961. Several readers have reported very favorably concerning their dealings with this company, and since I needed some parts, I decided to give them a try. I telephoned my order on Friday 9 August, and the parts arrived via UPS Blue on Tuesday the 13th. Just placing the order on the phone was a pleasant experience. The lady with whom I spoke explained carefully who made each chip, its rated speed, its price, and what optional parts were available. After I had made my selection, she took the shipping and billing information, and then read-back ABSOLUTELY EVERYTHING concerning the order to verify that she had the correct infor- mation. The company prefers to take a credit-card number for their own protection, but to be paid by check when the merchandise is received. Thus, an invoice accompanies the package; and if prompt payment is made, no billing is submitted to the credit-card company. The chips were packed in anti-static carriers, and the group of carriers were then wrapped in aluminum foil. A label cautioning the user about static damage had been affixed to the foil package. A stout shipping box with adequate shock-absorbant packing was used. Along with the parts, there was a nine-page "newsletter" written by John Gilchrist, who I presume is the proprietor. Some of the interesting items: 1. Several portions dealing with static electricity damage to IC's , and how to prevent it. (Microprocessors Unlimited shipping personnel work barefoot on a conductive floor mat!) 2. A discussion of the disadvantages of doing circuit development work using surplus IC's. 3. A statement that the author believes three Japanese companies - NEC, Hitachi and Fujitsu - make the best quality IC's. 4. A brief description of a Mitsubishi 64K DRAM having on-chip refresh. 5. A warning that to avoid damage, 2732A EPROMS must be programmed with 21 volts rather than the 25 volts used for non-suffix 2732's. 6. Several items dealing with the company's business policies. So far, I have not tested any of the material I received. If I discover anything further of interest concerning this company, I will post another message. Dave towson@amsaa.arpa 15-Aug-85 14:16:17-MDT,2110;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 15 Aug 85 14:16:04-MDT Received: from radc-tops20.arpa by AMSAA.ARPA id a028065; 9 Aug 85 10:07 EDT Date: Fri 9 Aug 85 10:06:37-EDT From: Gern Subject: Re: S-100 bus board problems To: crash!kevinb@SDCSVAX.ARPA cc: info-cpm-request@AMSAA.ARPA In-Reply-To: Message from "crash!kevinb@sdcsvax.ARPA" of Fri 9 Aug 85 09:06:21-EDT Resent-Date: Thu, 15 Aug 85 14:56:42 EDT Resent-From: cpmlist@AMSAA.ARPA Resent-To: info-cpm@RADC-TOPS20.ARPA For anyone doing ANY work with an S-100 system, especially if it is an older, possibly not IEEE-696 or even a new Z-100 which is IEEE-696, you MUST get a copy of the book by Sol Libes and Mark Garetz. I think the correct title is Interfacing to the IEEE-696/S-100 Bus. It is very well written and will describe everything you need to know. It helps if you have a copy of the standard: IEEE Standard 696 Interface Devices ANSI/IEEE Std 696-1983 It is Heathkit part number 500-69 A rough draft of the standard was published July 1979 in Computer (IEEE) magazine. The standard says the +8 lines (pins 1 & 51) must have an instantaneous minium greater than +7V, instant max less than 25V and an average max less than +11V. The pin 2 is 14.5<16<35V with average <21.5 Pin 52 is the same, but negative. As far as signals go, high state is +2V or greater on the reciever end. If you have an old S-100 system, therer are about 4 lines that have have been changed, but they were never used much anyhow (Memory write lock, etc.). Major concern is the bus termination circuits to prevent ringing and such. I am doing a lot of work at home, on the side on a 6 channel stereo sound/speech Synthesizer/joysticks (both analog and digital types)/ clock-calendar with battery backup and on-chip-leap-year. The design is finalized and I am workin on the PC Board layout. It is completely IEEE-696/S-100. So if you have any S-100 questions, I'll take a stab at them. Cheers, Gern ------- 15-Aug-85 14:18:01-MDT,1545;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 15 Aug 85 14:17:48-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a024663; 15 Aug 85 15:07 EDT Received: from usenet by TGR.BRL.ARPA id a006495; 15 Aug 85 14:28 EDT From: Chuck McManis Newsgroups: net.micro.cpm Subject: Re: how to execute programs from within cpm programs Message-ID: <38@intelca.UUCP> Date: 13 Aug 85 15:41:25 GMT To: info-cpm@AMSAA.ARPA > In article <946@sdcsla.UUCP> hestenes@sdcsla.UUCP (Eric Hestenes) writes: >Can anyone give me a hint as to how someone would call one program, >say WORDSTAR or something simpler, from within another program. > >Methods using Turbo Pascal, 'C' or assembler would be useful. > Aside from the fact that Turbo Pascal provides the function Execute(FilVar) where FilVar is the name of the program to run, if you want to be really slick, you could run ZCPR3 and stuff the name of the file to run (and all of its arguments) into the External Command line buffer and then exit to the CCP. Next thing running would be your program. (I have done this from turbo and found the results to be rather effective. --Chuck -- "Unix, the Teco of Operating Systems." - - - D I S C L A I M E R - - - {ihnp4,fortune}!dual\ All opinions expressed herein are my {qantel,idi}-> !intelca!cem own and not those of my employer, my {ucbvax,hao}!hplabs/ friends, or my avocado plant. :-} 16-Aug-85 07:46:27-MDT,969;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 16 Aug 85 07:46:12-MDT Received: from nprdc-gw by AMSAA.ARPA id a016220; 15 Aug 85 11:43 EDT Received: by nprdc.ARPA (4.12/4.7) id AA00892; Thu, 15 Aug 85 08:43:53 pdt From: Mel Moy Message-Id: <8508151543.AA00892@nprdc.ARPA> Date: 15 August 1985 0843-PDT (Thursday) To: info-cpm-request@AMSAA.ARPA Subject: Re: Identifying Simtel20 Files? Resent-Date: Thu, 15 Aug 85 15:55:43 EDT Resent-From: cpmlist@AMSAA.ARPA Resent-To: info-cpm@NPRDC.ARPA There was a request about what CP/M based Pascal is suitable for human consumption. Turbo Pascal from Borland International comes about as close to being the public domain software you need as anything else. Its low price to performance ratio makes Turbo Pascal an excellent bargain. The cleanup necessary to go from UCSD Pascal to Turbo shouldn't give too much difficulty. 16-Aug-85 07:47:08-MDT,1382;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 16 Aug 85 07:46:58-MDT Received: from brl-aos.arpa by AMSAA.ARPA id a025878; 15 Aug 85 15:32 EDT Received: from rand-unix.arpa by AOS.BRL.ARPA id a005257; 15 Aug 85 15:23 EDT Return-Path: Received: from vortex.UUCP by rand-unix.ARPA; Thu, 15 Aug 85 12:22:47 pdt Date: Thu, 15-Aug-85 11:56:27 PDT From: Lauren Weinstein Subject: mail order and credit cards Message-Id: <8508151156.101.0.VT1.00C@vortex.UUCP> To: info-cpm@BRL.ARPA, info-micro@BRL.ARPA Note that companies that take your credit card number down, even for a purchase by check, may cause you some problems. In particular, these companies often "run" your number (for verification) for the amount of the purchase through the credit card authorization computer, which eats down your available credit even though no actual purchase on the credit card is being made. While the lack of a followup purchase will normally eventually timeout the resulting "purchase authorization" after some period of time (typically two weeks or so) that is credit that is unavailable to you during that time--important if you have low credit limits. Also, the credit card firms may become irate about this practice if it occurs too often. --Lauren-- 16-Aug-85 08:18:09-MDT,1573;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 16 Aug 85 08:18:01-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a027707; 15 Aug 85 16:06 EDT Received: from usenet by TGR.BRL.ARPA id a009687; 15 Aug 85 15:30 EDT From: Dan Winkler Newsgroups: net.micro.cpm Subject: JRT Pascal Message-ID: <304@harvard.ARPA> Date: 15 Aug 85 14:07:39 GMT To: info-cpm@AMSAA.ARPA To answer a question I asked recently, yes there is a public domain (or rather free) Pascal compiler for CP/M. It's JRT Pascal and it's in micro: on simtel20. After a lot of work, I mangaged to bootstrap my machine to modem7 by way of mboot3, ftp all the files (warning: get20 didn't always work properly on my machine), and download them. (Strange, I never had to convert ITS format. I wonder if ftp or something was doing that for me.) Anyway, the program I want to run gets some strange errors from JRT for normal operations involving read, readln, write, writeln, reset, and rewrite. Could someone tell me where I can find a copy of the JRT manual or a few large example programs using those features? Thanks. One quirk I've already fixed was that you can't use the string initialize as an identifier in JRT. I had procedure initialize; and JRT said identifier expected. Changing the string stopped the error message. Does anyone know if it's possible to create stand alone applications with JRT or will I always have to type: exec file.int ? Thank you for your help! 16-Aug-85 09:35:58-MDT,5341;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 16 Aug 85 09:35:37-MDT Received: from mitre.arpa by AMSAA.ARPA id a013148; 16 Aug 85 10:47 EDT Received: by mitre.ARPA (4.12/4.7) id AA06296; Fri, 16 Aug 85 10:48:15 edt Message-Id: <8508161448.AA06296@mitre.ARPA> To: WhiteR Cc: info-cpm@AMSAA.ARPA Subject: Re: Question on how to acess SIMTEL20