1-Jun-85 07:57:00-MDT,1455;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 1 Jun 85 07:55:34-MDT Received: from simtel20.arpa by AMSAA.ARPA id a000213; 1 Jun 85 9:35 EDT Date: Sat, 1 Jun 1985 07:35 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: crash!victoro@sdcsvax.ARPA Cc: Info-Cpm@AMSAA.ARPA Subject: How to get MODM700 (latest version of MODEM7) Victor, MODM700 (the latest version of MODEM7) is too large to send by netmail. Those who don't have access to SIMTEL20 can get it from my RCPM Royal Oak (Michigan) (313) 759-6569. It uses a Racal-Vadic triple modem, speaks 103, 212 and 3400 protocol at 300, 450 and 1200 baud. Your friend can get it there on the C: drive as MODM700.LBR (everything needed to run the program except for the user overlay) and MODM700.AQM (full source - very large and not necessary to get). There is a M7-OVL.LBR (about 500k) full of user overlays. Don't take that, just download the overlays needed using the XMODEM L command or run LUX and use the SEND command to extract them. You'll also find MEX112.LBR there. MEX has a lot more features than MODEM7. The MEX user overlays are in MEX-OVL1.LBR. --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 1-Jun-85 08:41:16-MDT,1345;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 1 Jun 85 08:40:05-MDT Received: from ucb-vax.arpa by AMSAA.ARPA id a000284; 1 Jun 85 10:15 EDT Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.46) id AA21416; Sat, 1 Jun 85 07:12:42 pdt Received: from ucbamber.CC.Berkeley.ARPA (ucbamber.ARPA) by ucbjade.CC.Berkeley.ARPA (4.19/4.35.2) id AA00516; Sat, 1 Jun 85 07:16:42 pdt Received: by ucbamber.CC.Berkeley.ARPA (4.19/4.35.2) id AA15855; Sat, 1 Jun 85 07:16:16 pdt Date: Sat, 1 Jun 85 07:16:16 pdt From: swillett%ucbamber.CC@ucb-vax.ARPA Message-Id: <8506011416.AA15855@ucbamber.CC.Berkeley.ARPA> To: info-cpm@AMSAA.ARPA, rbt%sftig.uucp@BRL.ARPA Subject: Re: BORLAND TURBO PASCAL - New release (CP/M Version) (Really how to contact TUG) TUG can be contacted at: Turbo Users Group PO Box 1510 Poulsbo, WA 98370 Re: Recursion Turbo does indeed support recursion if the proper compiler directive is set. The issue is whether or not is supports standard pascal recursion -it appar- ently does not, since it does not allow the passing of *local* variables to recursive modules by reference. It works fine with globavariables. I doubt that Borland considers this a "bug" since they designed the software that way. steveswillett 1-Jun-85 19:14:29-MDT,1626;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 1 Jun 85 19:12:40-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a024684; 1 Jun 85 20:42 EDT Received: from usenet by TGR.BRL.ARPA id a000487; 1 Jun 85 20:40 EDT From: John Blalock Newsgroups: net.micro.cpm Subject: Xebec 1410 BIOS Help Wanted Message-ID: <583@terak.UUCP> Date: 31 May 85 05:59:16 GMT To: info-cpm@AMSAA.ARPA *** REPLACE THIS BUGLINE WITH YOUR MESSAGE *** I've decided to add a SA606 Winchester drive to my S-100 CP/M 2.2 system. (CCS 2810 Z80A CPU and CCS 2422 floppy controller.) The Wini will be interfaced thru a SASI/SCSI Host Adapter (I have the design pretty well completed) and a Xebec 1410 SASI controller. Modifying the BIOS to handle the hard disk will be my major challenge and I'd sure like some pointers, sample BIOS listings, etc. to help me in this task. Where better to ask for help than here? Please mail any listings, suggestions, warnings, experiences, or encouraging words to me at the address below. Discouraging words should be directed to dev/null as I couldn't resist the price of $275 for the drive/controller combo from Paramount Electronics in Sunnyvale, CA (408) 773-9595. Thanks in advance for the help! John Blalock, W7AAY uucp: ...{amd,decvax,hao,ihnp4,seismo}!noao!terak!jb phone: (602) 998-4800 us mail: Terak Corp., 14151 N. 76th St., Scottsdale, AZ 85260 \\\\\ -----> Soon to be part of CalComp, A Sanders Company (See page 2 of May 6 issue of Electronic News) 2-Jun-85 00:12:48-MDT,1351;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 2 Jun 85 00:09:43-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a025172; 2 Jun 85 1:45 EDT Received: from usenet by TGR.BRL.ARPA id a004022; 2 Jun 85 1:40 EDT From: vr0z05%unido.uucp@BRL.ARPA Newsgroups: net.micro.cpm Subject: Interrupts in TURBO on Apple Message-ID: Date: 31 May 85 20:45:00 GMT Sender: notes%unido.uucp@BRL.ARPA Nf-ID: #N:unido:10900001:000:748 Nf-From: unido!vr0z05 May 31 18:45:00 1985 To: info-cpm@AMSAA.ARPA Hi folks, I have a question on Turb-Pascal. Has anybody out there tried to write interrupt procedures in Turbo-Pascal on CP/M 2.23 on an Apple II+ with a Microsoft Softcard. Has anybody tried to write interrupt procedures on the same configuration in assembler. I have tried it, but the documentation seems to be not always correct in the parts about machine-level and interrupt programming, so my program doesn't work correct. I'm interested in any help how to catch the interrupts on both processors (6502 - Apple / Z80 - MS-Softcard) correct. Thanks in advance Uwe Hoch Computer Science Department University of Dortmund 4600 Dortmund 50 P.O. Box 500500 West Germany E-mail address UUCP: ...!mcvax!unido!vr0z05 2-Jun-85 01:53:51-MDT,33351;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 2 Jun 85 01:51:14-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a025246; 2 Jun 85 2:53 EDT Received: from usenet by TGR.BRL.ARPA id a004362; 2 Jun 85 2:40 EDT From: Mark Mallett Newsgroups: net.micro.cpm,net.sources Subject: TOPS20 style parsing Message-ID: <393@sii.UUCP> Date: 27 May 85 14:46:26 GMT Xref: seismo net.micro.cpm:4564 net.sources:2989 To: info-cpm@AMSAA.ARPA Greetings. About a year ago, I wrote a set of C routines to implement TOPS-20 style parsing on my CP/M system. I have used these routines for a number of programs, such as a reminder program and software which composes my bulletin board system here in NH. With that, I am now convinced that the routines work (at least to the point where I can use them), and have put them together as a kit. What follows is the document for the library. If you have comments, please send me mail. If there is enough interest, I shall post the sources. I hope that if this happens, someone will tell me whether the net.micro.cpm or the net.sources area is appropriate; I am sending this message off to both. Cheers, Mark Mallett decvax!sii!mem or ittvax!sii!mem C O M N D A TOPS-20 style command parsing library for personal computers Documentation and source code Copyright (C) 1985 by Mark E. Mallett; permission is granted to distribute this document and the code indiscriminately. Please leave credits in place, and add your own as appropriate. This Document This document contains the following sections: o Document overview (this here section) o Introduction and history o Functional overview o How to write programs using the subroutine library o How to make the library work on your system Introduction and History This document describes the COMND subroutine package for C programmers. COMND is a subroutine library to effect consistent parsing of user input, and in general is well suited for verb-argument style command interfaces. The library provides a consistent user interface as well as a program interface which, I believe, could well remain unchanged if the parsing library were re-written to support different interface requirements (such as menu interaction). The COMND interface is based on the TOPS-20 model. TOPS-20 is an operating system which is/was used by Digital Equipment Corporation on their PDP-20 computer. TOPS-20 was based on TENEX, written by BBN (I think, I think). TOPS-20 COMND is much more robust and consistent than the library which this document describes; this library being intended for small computer applications, it provides the most commonly used functions. This library was written on a Z-80 system running Digital Research Corporation's CP/M operating system version 3.0 (CPM+). I have also compiled and tried it on a VAX 11/780 running VMS. It is completely written in the C language, and contains only a few operating system specific elements. The COMND JSYS section of the TOPS-20 Monitor Calls manual is probably a good thing to read. Please note: while there are a few unimplemented sections of this library, I felt that it was nevertheless worthwhile to submit it to public domain since it is usable for almost all general command parsing and since the call interface is well defined. I have used this library extensively since sometime in 1984. Functional Overview The COMND subroutine library provides a command-oriented user interface which is consistent at the programmer level and at the user level. At the program level, it gives an algorithmically controlled parsing flow, where a call to the library exists for each field or choice of fields to be parsed. At the user level, the interface provides: o Command prompting. o Consistent command line editing. The user may use editing keys to erase the last character or word, and to echo the current input line and prompt. o Input abbreviation and defaulting. The user may type abbreviations of keywords, or may type nothing to have defaults applied. o Incremental help. By pressing a known key (usually a question mark), the user can find out what choices s/he has. o Guide strings. Parenthesized guide words are shown at the users option. o Command completion. Where the subroutine library can judge what the succesful completion of a portion of user input will be, the user can elect to have this input completed and shown automatically. Using the COMND Library While you read this part of the document, you might want to look at the sample program named TEST.C which has been included with this package. It is an over-commented guide to the use of the COMND library. Any module which makes use of this library shall include the definition file named "comnd.h". This file contains definitions which are necessary to the caller-library interface. Mnemonics (structures and constants) mentioned in relation to this interface are defined in this file. The philosophy of parsing with the COMND library is that a command line is typed, the program inspects it, then the program acts on the directions given in that line. This process is repeated until the program finishes. The COMND library assists the user in typing the command line and the program in inspecting it. Acting on it is left up to the calling program. The typing and parsing of fields in the command line go essentially hand-in-hand with this library. The single subroutine COMND() is used to effect all parsing. This routine is called for each element of the input line to be parsed. Parsing is done according to a current parse state, which is maintained in a parameter block passed between caller and library. The state block contains the following sort of information (described in detail later): o What to use for a prompt string. o Addresses of scratch buffers for user input and atom storage. o How much the user has entered. o How much of the line the program has parsed. An important thing to note is that the indexes (how much entered and parsed) are both variable. The program begins parsing of the input line upon a break signal by the user (such as the typing of a carriage return, question mark, etc). The user may then resume typing and erase characters back to a point BEFORE that already parsed. It is very important that the program does not take any action on what has been parsed until the line has been completely processed, otherwise that action could be undesired. Since the user may back up the command input to a point before that already processed by the application program, a mechanism must be provided to backup the program to the correct point. Rather than going to the point backed up to, the COMND library expects the application program to return to the beginning of the line, and start again. The user's input has remained in the command line buffer, and the library will take care of buffering the rest of the input when that parse point is again reached. However, this means that there must be a method of communicating to the calling program that this "reparse" is necessary. Actually there are two methods provided, as follows: o Each call to the command parsing routine COMND() yields a result code. The result may indicate that a reparse has to take place. The program shall then back up to the point where the parse of the line began, and start again. o The application program may specify the address of a setjmp buffer which identifies the reparse point. (Note setjmp is a facility provided as part of most standard C libraries. It allows you to mark a point in the procedure flow [call frame, registers, and whatever else is involved in a context], and return to that point from another part of the program as if control had never proceeded. If you are unfamiliar with this facility, you might want to find a description in your C manual.) It is up to the caller to setup the setjmp environment at the reparse point. In either case, the reparse point (the point at which the parse will be restarted if necessary) is the point at which the first element of the command line is parsed. This is after the initialization call which starts every parse. Every call to the COMND() subroutine involves two arguments: a command state block, in which is kept track of the parse state, and a command function block, which describes what sort of thing to parse next. The command state block is given a structure called "CSBs", and a typedef called "CSB". Each element of the structure is named with a form "CSB_xxx", where "xxx" is representative of the element's purpose. The following are the elements of the command state block, in the order that they appear in the structure. o CSB_PFL is a BYTE. This contains flags which are set by the caller to indicate specifics of the command processing. These flags are: o _CFNEC: Do not echo user input. o _CFRAI: Convert lowercase input to uppercase. o CSB_RFL, a BYTE value, contains flags which are kept by the library in the performance of the parse. Generally, these flags are of no interest to the caller since their information can be gleaned from the result code of the COMND() call. However, they are: o _CFNOP: No parse. Nothing matched, i.e., an error occured. o _CFESC: Field terminated by escape. o _CFEOC: Field terminated by CR. o _CFRPT: Reparse required. o _CRSWT: Switch ended with colon. o _CFPFE: Previous field terminated with escape. o CSB_RSB is the address of a setjmp buffer describing the environment at the reparse point. If this value is non-NULL, then if a reparse is required, a longjmp() operation is performed using this setjmp buffer. o CSB_INP is the address of the input-character routine to use. If this value is non-NULL, then this routine is called to get each character of input. No line editing or special interactive characters are recognized in this mode, since it is assumed that this will be used for file input. Note especially: this facility is not yet implemented, however the definition is provided for future expansion. Thou shalt always leave this NULL, or write the facility thyself. o CSB_OUT is the inverse correspondent to the previous element (CSB_INP). It is the address of a routine to process output from the command library. Please see the warning in the CSB_INP description about not being implemented. o CSB_PMT is the address of the prompt string to use for command parsing. The command library takes care of prompting, so make sure this is filled in. o CSB_BUF is the address of the buffer to put user input into as s/he is typing it in. o CSB_BSZ, an int, is the number of bytes which can be stored in CSB_BUF; i.e., it is the buffer size. o CSB_ABF is the address of an atom buffer. Some (if not all) parsing functions involve extracting some number of characters from the input buffer and interpreting or simply returning this extracted string. This buffer is necessary for those operations. It should probably be as large as the input buffer (CSB_BUF), but it is really up to you. o CSB_ASZ, an int, is the number of characters which can be stored in CSB_ABF; i.e., it is the size of that buffer. ** Note ** CSB elements from here to the end do not have to be initialized by the calling program. They are used to store state information and are initialized as required by the library. o CSB_PRS, an int, contains the parse index. This is the point in the command buffer up to which parsing has been achieved. o CSB_FLN, an int, is the filled length of the command buffer. This is the number of characters which have been typed by the user. o CSB_RCD, an int, is a result code of the parse. This is the same value which is returned as the result of the COMND() procedure call. o CSB_RVL is a union which is used to contain either an int or a long value. The names of the union elements are: _INT for int, _ADR for address (note that a typecast should be used for proper address assignment). This element contains a value returned from some parse functions which return values which are single values. For example, if an integer is parsed, its value is returned here. o CSB_CFB is the address of a command function block for which a parse was successful. This is significant in cases where there are alternative possible interpretations of the next command element. The parse of each element in a command line involves, as well as the Command State Block just described, a Command Function Block which identifies the sort of thing to be parsed. This block is defined in a structure named "CFBs", which has a corresponding typedef named "CFB". Elements of the CFB, named "CFB_xxx", are as follows (in the order they appear in the structure): o CFB_FNC, a BYTE, is the function code. This defines the function to be performed. The function codes are listed, and their actions described, a little later. o CFB_FLG, a BYTE, contains flags which the caller specifies to the library. These are very significant, and in most cases affect the presentation to the user. The flag bits are: o _CFHPP: A help string has been supplied and should be given when the user types the help character ("?"). o _CFDPP: A default string has been supplied, and shall be used if the user does not type anything at this point (typing nothing means typing a return or requesting command completion). Note that this flag (and the default string) is ONLY significant for the CFB passed in the call to the COMND() routine, and not for any others referenced as alternatives by that CFB. o _CFSDH: The default help message should be supressed if the user types the help character ("?"). This is normally used in conjunction with the _CFHPP flag. However, if this flag is present and the _CFHPP is not selected, then the help operation is inhibited, and the help character becomes insignificant (just like any other character). o _CFCC: A character characteristic table has been provided. A CC table identifies which characters may be part of the element being recognized. Not all functions support this table (for example, it does not make sense to re-specify which characters may compose decimal numbers). This table also specifies which characters are break characters, causing the parser to "wake up" the calling program when one of them is typed. If this bit is not set (as is usually the case), a default table is associated according to the function code. o _CFDTD: For parsing date and time, specifies that the date should be parsed. o _CFDTT: For parsing date and time, specifies that the time should be parsed. o CFB_CFB is the address of another CFB which may be invoked if the user input does not satisfy this CFB. CFBs may be chained in this manner at will. Recognize, however, that the ORDER of the chain plays an important part in how input is handled, particularly in disambiguation of input. Note also that only the first CFB of the chain is used for specifying a default string and CC table (for command wake-up). CFB chaining is a very important part of parsing with this library. o CFB_DAT is defined as a long, since it is used to contain address or int values. It should be referenced via typecast. It is not defined as a union because it is inconvenient or impossible to initialize unions at compile time with most (all?) C compilers, and initialization of these blocks at runtime is not desirable. This element contains data used in parsing of a field in the command line. For instance, in parsing an integer, the caller specifies the default radix of the integer here. o CFB_HLP is the address of a caller-supplied help string. This is only significant if the flag bit _CFHPP is set in the CFB_FLG byte. o CFB_DEF is the address of a caller-supplied default string. This is only significant if the flag bit _CFDPP is set in the CFB_FLG byte, and only for the first CFB in the CFB chain. o CFB_CC is the address of a character characteristics table. This is only significant if the flag bit _CFCC is set in the CFB_FLG byte. This is the address of a 16-word table, each word containing 16 bits which are interpreted as 8 2-bit characteristic entries. The most significant bits correspond to the lower ASCII values, etc. The 2-bit binary value has the following meaning, per character: o 00: Character may not be part of the element being parsed. o 01: Character may be part of the element only if it is not the first character of that element. o 02: Character may be part of the element. o 03: Character may not be part of the element; furthermore, when it is typed, it will case parsing to begin immediately (a wake-up character). The function code in the CFB_FC element of the command function block specifies the operation to be performed on behalf of that function block. Functions are described now. CFB function _CMINI: Initialize Every parse of a command line must begin with an initialization call. This tells the command library to reset its indexes, that the user must be prompted, etc. There may be NO other CFBs chained to this one, because if they are, they are ignored. The reparse point is the point right after this call. If the setjmp method is used, then the setjmp environment should be defined here. After the reparse point, any variables etc which may be the victims of parsing side-effects should be initialized. CFB function _CMKEY: Keyword parse _CMKEY parses a keyword from a given list. The CFB_DAT element of the function block should point to a table of string pointers, ending with a NULL pointer. The user may type any unique abbreviation of a keyword, and may use completion to fill out the rest of a known match. The address of the pointer to the matching string is returned in the CSB_RVL element of the command state block. The value is returned this way so that the index can be easily calculated, and because it is consistent with the general keyword parsing mechanism (_CMGSK). The incremental help associated with keyword parsing is somewhat special. The default help string is "Keyword, one of:" followed by a list of keywords which match anything already typed. If a help string has been supplied (indicated by _CFHPP) and no suppression of the default help is specified, then the initial part ("Keyword, ") is replaced with the supplied help string and the help is otherwise the same. If a help string has been supplied and the default has been supressed, then the given help string is presented unaltered. CFB function _CMNUM: number This parses a number. The caller supplies a radix in the CFB_DAT element of the function block. The number parsed is returned (as an int) in the CSB_RVL element of the state block. CFB function _CMNOI: guide word string This function parses a guide word string (noise words). Guide words appear between significant parts of the command line, if they are in parentheses. They do not have to be typed, but if they are, they must match what is expected. If the previous field ended with command completion, then the guide words are shown automatically by the parser. An interesting use of guide word strings is to provide alternate sets with the command chaining feature. The parse (and program) flow can be altered depending on which string was matched. CFB function _CMCFM: confirmation A confirmation is a carriage return. The caller should parse a confirmation as the last thing before processing what was parsed. Since carriage return is by default a wake-up character, requiring a confirmation will (if you don't change this wake-up attribute) require that the parse be completed with no extra characters typed. A parse with this function code returns only a status. CFB function _CMGSK: General storage keyword This call provides for parsing of one of a set of keywords which are not arranged in a table. Often, keywords are actually stored in a file or in a linked list. The caller fills in the CFB_DAT element of the command function block with the address of a structure named CGKs (typedef CGK), which contains the following elements: o CGK_BAS: A base address to give to the fetch routine. Does not matter what this is, as long as the fetch routine understands it. o CFK_CFR: The address of a keyword fetch routine. The routine is called with the CGK_BAS value, and the address of the pointer to the previous keyword. It is expected to return the address of the pointer to the next keyword, or with the first one if the passed value for the previous pointer is NULL. When this function completes successfully, it returns the address of the pointer to the string in the CSB_RVL element in the command state block. Please see the description of the _CMKEY function code for a description of help and other processing. CFB function _CMSWI: Parse a switch. This is functionally equivalent to _CMKEY, and exists to fill a need for switch parsing. Basically it is a placeholder for an unimplemented function. CFB function _CMTXT: Rest of line This function parses the text to the end of the line. Note that this does not parse the trailing break character (i.e. the carriage return). The text is returned in the atom buffer which is defined (by the caller) by the CSB_ABF and CSB_ASZ elements of the command state block. CFB function _CMTOK: token This function will parse an exact match of a particular token. A token is a string of characters, whose address is supplied by the caller in the CFB_DAT element of the command function block. This function is mainly useful for parsing such things as commas and other separators, especially where it is one of several alternative parse functions. It returns no value other than its status. CFB function _CMUQS: unquoted string This function parses an unquoted string, consisting of any characters other than spaces, tabs, slashes, or commas. This set may of course be changed by supplying a CC table. The unquoted string is returned in the atom buffer associated with the command state block. CFB function _CMDAT: parse date/time This function parses a date and/or time. The caller specifies, via flag bits in the CFB_FLG byte of the command function block (as identified above) which of date, time, or both, are to be parsed. The date and time are returned as the first two ints in the atom buffer which is associated with the command state block. Note that both date and time are returned, regardless of which were requested. Note further that this routine is not fully implemented as of this writing. Calling the COMND library All that you need to know to use the above information is how to call the command library. Basically, there is one support routine: COMND(). It is used like this: status = COMND (csbp, cfbp); Here, "csbp" is the address of the command state block, and "cfbp" is the address of the command function block. The COMND() routine returns an int status value, which is one of the following: o _CROK: The call succeeded; a requested function was performed. The address of the matching function block is returned in the CSB_CFB element of the command state block, and other information is returned as described above. o _CRNOP: The call did not succeed; nothing matched. o _CRRPT: The call did not succeed because the user took back some of what had already been parsed. In other words, a reparse is required, and your program must back up to the reparse point. Note that if you specify a setjmp buffer address in the CSB_RSB element of the command state block, you will never see this value because the COMND library will execute a longjmp() operation using that setjmp buffer. o _CRIFC: The call failed because you provided an invalid function code in the command function block (or in one which is chained to it). You have made a programming error. o _CRBOF: Buffer overflow. The atom buffer is too small to contain the parsed field. o _CRBAS: Invalid radix for number parse. o _CRAGN: You should not see this code. It is reserved for a support-mode call to the subroutine library. Installing the COMND library This part of the document describes the modules which come with the COMND library kit, and what you might have to look at if the code does not instantly work on your system (which will probably be the case if your system is not the same kind as the one which you got it from). The files which come in the COMND kit are as follows: o COMND.R - Source for this document, in a form suitable for the public domain formatting program called "roff4". o COMND.DOC - This document. o MEM.H - A file of my (Mark Mallett) definitions which are used by the code in the command subroutine library. o COMND.H - Command library interface definitions. o COMNDI.H - Command library implementation definitions. o COMND.C - Primary module of the COMND library. Contains user input buffering and various library support routines. o CMDPF1.C - First module of parse function processing routines. o CMDPF2.C - Second module of parse function processing routines. o CMDPFD.C - Contains the date/time parse function routines. This is included in a separate module so that it can be replaced with a stub, since few programs (that I have written, anyway) use this function, and it does take up a bit of code. o CMDPSD.C - A stub for the date/time parsing functions. This can be linked with programs which do not actually use the date/time parse function. o CMDOSS.CPM - Operating system specific code which works for CP/M. This is provided as a model for the routines which you will have to write for your system. o CMDDTM.CPM - Date/time support routines for version 3.0 of CP/M. This is a module containing routines to get the date and time from the operating system, and to encode/decode these values to and from internal form. This is provided as a model; you will probably have to rewrite them for your system. 2-Jun-85 07:57:06-MDT,659;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 2 Jun 85 07:52:22-MDT Received: from simtel20.arpa by AMSAA.ARPA id a025923; 2 Jun 85 9:21 EDT Date: Sun, 2 Jun 1985 07:22 MDT Message-ID: From: CSTROM@SIMTEL20.ARPA Subject: Need CCPM hd driver To: INFO-CPM@AMSAA.ARPA cc: CSTROM@SIMTEL20.ARPA I am in search of hard disk drivers for the Konan DGC-100 controller and Rodime drives for Concurrent CP/M. If anyone could supply source, gratis or at reasonable cost, or could supply possible avenues to explore, I would very much appreciate it. -Charlie 2-Jun-85 09:51:15-MDT,1329;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 2 Jun 85 09:46:25-MDT Received: from su-score.arpa by AMSAA.ARPA id a026101; 2 Jun 85 11:31 EDT Date: Sun 2 Jun 85 08:31:18-PDT From: Sam Hahn Subject: Re: Need CCPM hd driver To: CSTROM@SIMTEL20.ARPA cc: info-cpm@AMSAA.ARPA In-Reply-To: Message from "CSTROM@SIMTEL20.ARPA" of Sun 2 Jun 85 06:58:02-PDT Hello, Charlie -- This is two-year-old information, but the only company I came across that worked with that particular hardware combination was a company called Monitor Dynamics, in Upland CA. Their phone number is 714-985-7214. I had been interested in Rodime drives when I still ran my SD Systems boards, and Media Distributing, in Scotts Valley CA (800-824-7386 or 800-824-7385) had really good prices on those drives. They, at the time, were being supported by Monitor Dynamics for the Konan drivers. Of course, this was all before ConcurrentCP/M. The fellow I talked with at Media Distributing (I think they've changed their name since I called them) was Marshall Post (he's also reachable at 408-438-5454, if he's still there). The guy at Monitor Dynamics he put me in touch with was Gary Clinard. Hope this helps. Best lead I can muster. -- Sam ------- 2-Jun-85 11:11:50-MDT,597;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 2 Jun 85 11:06:53-MDT Received: from simtel20.arpa by AMSAA.ARPA id a026224; 2 Jun 85 12:46 EDT Date: Sun, 2 Jun 1985 10:46 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 2-Jun-85 21:46:07-MDT,1324;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 2 Jun 85 21:45:18-MDT Received: from ucb-vax.arpa by AMSAA.ARPA id a027389; 2 Jun 85 23:14 EDT Received: from ucbarpa.ARPA by UCB-VAX.ARPA (4.24/4.46) id AA09363; Sun, 2 Jun 85 20:11:25 pdt Received: by ucbarpa.ARPA (4.24/4.46) id AA27674; Sun, 2 Jun 85 20:14:52 pdt Date: Sun, 2 Jun 85 20:14:52 pdt From: Jordan Hayes Message-Id: <8506030314.AA27674@ucbarpa.ARPA> Organization: Computer Systems Research Group Home-Phone: (415) 835-8767 Uucp-Path: ...ucbvax!jordan To: info-cpm@AMSAA.ARPA Subject: Hmmm... the difference between "R" and "r"... Well, it still seems that there are some people who don't yet know the difference between "R"eplying and "r"eplying to mail. BE SURE TO CHECK THAT YOU SEND A COPY OF YOUR MESSAGE TO WHERE YOU WANT IT TO GO. This networking newsletter (I haven't received mine yet... :-) ) is generating a lot of extra mail (I really don't mind, but I guess some people do; the problem I see is when someone wants to make a personal reply to someone and winds upsending to the whole net...). I'm all for sharing replies with the whole net, but there are "features" of certain mail programs that are there for a reason... /jordan 3-Jun-85 01:41:09-MDT,1307;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 3 Jun 85 01:39:12-MDT Received: from simtel20.arpa by AMSAA.ARPA id a027636; 3 Jun 85 3:10 EDT Date: Mon, 3 Jun 1985 01:03 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: Adam computer CP/M help needed Relayed from my RCPM Royal Oak (759-6569): Date: 5/30/85 From: HORST MANN To: ALL Re: CP/M HELP Some may be surprised to find out that the much maligned ADAM computer operates on Z-80A chips and runs CP/M 2.2. This has been a life saver for ADAM users since the computer has been discontinued. Many programs from BBS like this run without alteration, but the one major drawback is the ADAM video display -- 31 columns displayed in a moving window -- making it almost impossible to follow along on most CP/M written for 80 columns. I understand a small program is available that alters the screen width, called something like SCNOP (??). Does any one know it it or something like it is available here or on another nearby system? I'm not much of a programmer, so I really can't do anything about it myself. Any ideas? HORST MANN 3-Jun-85 03:21:42-MDT,5987;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 3 Jun 85 03:20:17-MDT Received: from simtel20.arpa by AMSAA.ARPA id a027779; 3 Jun 85 4:51 EDT Date: Mon, 3 Jun 1985 02:51 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: New files on SIMTEL20 between 7-May-85 and 2-Jun-85 The following is a list of files added to the SIMTEL20 MICRO: directories between 7-May-85 and 2-Jun-85. A complete list of all files is available in MICRO:CPM.CRCLST. Dir. Filename Type Bytes CRC MICRO: FORM7.LBR.1 BINARY 9472 ABF8H MICRO: MAKSRL.LBR.1 BINARY 8832 1CF7H MICRO: NEAT7.LBR.1 BINARY 6144 9C8FH MICRO: Z80MR.LBR.1 BINARY 41344 B0D0H MICRO: TINIDISK.LBR.1 BINARY 44672 7D5FH MICRO: B3EPQX-4.IQS.1 BINARY 4096 6259H MICRO: BYE334A.LBR.1 BINARY 59648 1F31H MICRO: BYEP-333.LBR.1 BINARY 62208 6AFEH BYEP-INS.LBR.1 BINARY 22400 0262H MICRO: NULU01.IQF.1 BINARY 1152 63C0H MICRO: PATCH18A.LBR.1 BINARY 66176 2D51H MICRO: FIDO-109.LQT.1 BINARY 14976 6B97H FIDO-203.NQS.1 BINARY 33152 D8F3H FIDO-204.NQS.1 BINARY 32384 FFC4H FIDO-209.NQS.1 BINARY 21120 D73AH FIDO-211.NQS.1 BINARY 23808 0C01H FIDO-212.NQS.1 BINARY 27392 E856H FIDO-219.NQS.1 BINARY 18304 D33FH FIDO-301.NQS.1 BINARY 34304 0C6AH FIDO-315.NQS.1 BINARY 24704 D59BH NODE-109.LQT.1 BINARY 14848 0CBCH MICRO: MSJ.DOC.1 ASCII 1452 9C99H Z800MORE.DQC.1 BINARY 5120 0ED2H MICRO: JMODZ100.LBR.1 BINARY 7424 6E4AH MICRO: CURSOR.LBR.1 BINARY 4736 2E97H FASTTERM.LBR.1 BINARY 4608 CD25H MICRO: GALLERY.LBR.1 BINARY 9216 F696H MICRO: MEX-STAT.FIX.1 ASCII 804 4D73H MICRO: PDSE-062.DQF.1 BINARY 20096 2B3DH PDSE-062.LQT.1 BINARY 44928 7F85H RCPM-062.LQT.1 BINARY 1920 4D2EH MICRO: HAYS2400.IQF.1 BINARY 5376 C444H HEXLINK.LBR.1 BINARY 17152 EEBEH MICRO: M7AQ-4.AQM.1 BINARY 12800 E9B7H MICRO: PACKET93.LBR.1 BINARY 219648 0C0BH PACKET93.MSG.1 ASCII 2144 C55CH ROUTING.TXT.1 ASCII 28795 2D49H TCP-IP.TXT.1 ASCII 56129 368BH MICRO: JDATE.PQS.1 BINARY 2816 B618H MICRO: LPT-30.AQM.1 BINARY 17792 9E27H LPT-30.DQC.1 BINARY 3584 BCAEH MICRO: MBBS30.LBR.1 BINARY 153472 9A56H RBBS40.LBR.1 BINARY 30976 728FH MICRO: LUXTYP42.BUG.1 ASCII 590 D648H NBYE10.LBR.1 BINARY 100224 FBB4H RCPM-UG.WQ.1 BINARY 33792 84DBH WHATSN04.LBR.1 BINARY 25984 6A7EH XMFIX.NOT.1 ASCII 2711 229EH MICRO: MAKESQ..2 ASCII 156 23CEH MAKEUSQ..2 ASCII 91 8E4BH README..2 ASCII 3817 A23DH SQ.1.2 ASCII 1657 E6FCH SQ.C.2 ASCII 5518 7EE5H SQ.H.2 ASCII 1900 F320H SQCOM.H.2 ASCII 445 F27AH SQDEBUG.C.2 ASCII 791 78FFH SQIO.C.2 ASCII 810 B0BEH SQU-PORT2.MAN.1 ASCII 1954 A5DEH SQU-PORT2.MSG.1 ASCII 818 197FH TR1.C.2 ASCII 1361 CC07H TR2.C.2 ASCII 13424 763AH USQ.C.2 ASCII 6527 1AF0H USQ.H.2 ASCII 376 BF51H UTR.C.2 ASCII 1778 9735H MICRO: SQ17.BUG.1 ASCII 717 375DH MICRO: MODEM7.DOC.1 ASCII 13552 C0A9H MICRO: REFS13.LBR.1 BINARY 12288 E598H MICRO: FILT7.LBR.1 BINARY 6016 9921H GTXT.LBR.1 BINARY 4480 5014H TABS7.LBR.1 BINARY 4736 E31BH TOUR20.LBR.1 BINARY 96512 2F91H TOURND.LBR.1 BINARY 10240 2300H VDO25.LBR.1 BINARY 41472 C4B7H MICRO: WSFAST22.LBR.1 BINARY 13440 183DH MICRO: YMODEM.DQC.1 BINARY 24704 4837H MICRO: Z3NEWS.109.1 ASCII 10844 5BA3H Z3NEWS.201.1 ASCII 9211 457FH Z3NEWS.202.1 ASCII 12202 5AAAH Z3NEWS.203.1 ASCII 12150 1D35H MICRO: ACREATE2.LBR.1 BINARY 11648 8A0AH Z3NEWS.109.1 ASCII 10844 5BA3H Z3NEWS.201.1 ASCII 9211 457FH Z3NEWS.202.1 ASCII 12202 5AAAH Z3NEWS.203.1 ASCII 12150 1D35H --Keith 3-Jun-85 05:21:23-MDT,1724;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 3 Jun 85 05:20:33-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a028090; 3 Jun 85 6:57 EDT Received: from usenet by TGR.BRL.ARPA id a017007; 3 Jun 85 6:51 EDT From: John Blalock Newsgroups: net.micro.cpm Subject: Xebec 1410 BIOS Help Wanted Message-ID: <584@terak.UUCP> Date: 2 Jun 85 09:37:21 GMT To: info-cpm@AMSAA.ARPA *** REPLACE THIS BUGLINE WITH YOUR MESSAGE *** I've decided to add a SA606 Winchester drive to my S-100 CP/M 2.2 system. (CCS 2810 Z80A CPU and CCS 2422 floppy controller.) The Wini will be interfaced thru a SASI/SCSI Host Adapter (I have the design pretty well completed) and a Xebec 1410 SASI controller. Modifying the BIOS to handle the hard disk will be my major challenge and I'd sure like some pointers, sample BIOS listings, etc. to help me in this task. Where better to ask for help than here? Please mail any listings, suggestions, warnings, experiences, or encouraging words to me at the address below. Discouraging words should be directed to dev/null as I couldn't resist the price of $275 for the drive/controller combo from Paramount Electronics in Sunnyvale, CA (408) 773-9595. Thanks in advance for the help! John Blalock, W7AAY uucp: ...{amd,decvax,hao,ihnp4,seismo}!noao!terak!jb phone: (602) 998-4800 us mail: Terak Corp., 14151 N. 76th St., Scottsdale, AZ 85260 \\\\\ -----> Soon to be part of CalComp, A Sanders Company (See page 2 of May 6 issue of Electronic News) (Reposting as I don't think first posting made it out. Please excuse if this is a duplication.) 3-Jun-85 12:00:46-MDT,936;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 3 Jun 85 11:56:05-MDT Received: from xerox.arpa by AMSAA.ARPA id a018340; 3 Jun 85 13:05 EDT Received: from Aurora.ms by ArpaGateway.ms ; 03 JUN 85 10:03:35 PDT Date: Mon, 3 Jun 85 13:03 EDT From: Thieret.WBST@XEROX.ARPA Subject: Re: EMACS for CP/M, MINCE, and SCRIBBLE In-reply-to: "BHUBER@USC-ECL.ARPA's message of 31 May 85 09:26 PDT" To: BHUBER@USC-ECL.ARPA cc: daemon%decwrl.uucp@BRL.ARPA, info-cpm@AMSAA.ARPA Message-ID: <850603-100335-1452@Xerox> Bud Huber & company, While Final Word does operate under CP/M-80 (I have a copy too) it still has some significant bugs and fixes to those bugs, while recognized by Mark of the Unicorn, are not being addressed by the company. They apparantly have bowed down to the MS-DOS icon and will support only that O.S. :-( Tracy (still waiting for my upgrade) Thieret 4-Jun-85 06:48:24-MDT,1673;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 4 Jun 85 06:47:58-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a002749; 4 Jun 85 8:17 EDT Received: from usenet by TGR.BRL.ARPA id a007530; 4 Jun 85 8:05 EDT From: Chuck McManis Newsgroups: net.micro.cpm Subject: Re: Re: EMACS for CP/M, MINCE, and SCRIBBLE Message-ID: <596@intelca.UUCP> Date: 3 Jun 85 15:21:24 GMT To: info-cpm@AMSAA.ARPA > > Mince and Scribble for CP/M-80 live on as Perfect Writer and Perfect > Formatter (respectively), and used to come standard with Kaypros. I don't > know if Kaypro still furnishes the (im)Perfect family. Unfortunately, > source is not available for the Perfect versions. You can do some > limited customization by rebinding keys and telling it a bit about your > printer (but you can't get superscripts and subscripts unless your printer > is one of the `supported' models-- no way to write your own driver for > others). > > --Michal Young > young@uci.arpa However, Mince could handle files larger than 64K wheras Perfect Writer didn't seem to. Even with a huge >128K swap file. It is/was quite a shame for MotU to drop Mince/Scribble support like it did. Now if they would just release the source to the public domain... --Chuck -- - - - 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. :-} 4-Jun-85 09:21:32-MDT,1624;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 4 Jun 85 09:19:23-MDT Date: Tue, 4 Jun 85 10:37:18 EDT From: David Towson (SECAD) To: info-cpm@AMSAA.ARPA Subject: Bright spots. Fellow CP/Mers - Just for fun, here is a note I received from Ferd Brundick, list maintainer for info-pascal@brl. Things like this provide bright spots in what is normally a routine job. I recently had such a pleasure when I added to this list a reader in Norway. We also have readers in other countries outside the USA. ----------------------------------------------------------------------------- [Dave,] I thought you might be (mildly) interested in the following request I received as Pascal mailman. dsw, fferd ----- Forwarded message # 1: Date: Thursday, 30 May 1985 19:21:07-PDT From: seki%tkov60.DEC@decwrl.ARPA (Kouichi Seki - Tokyo, TKH / SWS) To: info-pascal-request@brl-voc.ARPA Subject: Please add my name to mailing list Hello, Frederick-san My name is Kouichi Seki. Please add my name to mailing list. My email-address is [ SEKI%TKOV60.DEC@DECWRL.ARPA ]. Best regards, Kouichi Seki my address is as follows. NIHON DEC Sunshine 60 (35F) Higashi Ikebukuro 3-1-1 Toshimaku Tokyo Japan zip 170 ----- End of forwarded messages ---------------------------------------------------------------------------- Dave towson@amsaa.arpa aka info-cpm-request@amsaa.arpa 4-Jun-85 12:41:16-MDT,632;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 4 Jun 85 12:36:56-MDT Received: from wiscvm.arpa by AMSAA.ARPA id a026642; 4 Jun 85 14:01 EDT Received: from (HARRELL)EDUCOM.BITNET by WISCVM.ARPA on 06/04/85 at 13:01:16 CDT Date: 4 JUN 85 13:19-EDT From: HARRELL%EDUCOM.BITNET@WISCVM.ARPA To: INFO-CPM@AMSAA.ARPA Subject: Networking Newsletter All, The Networking Newsletter was mailed today to all who requested before 05/28/85. A second mailing will take place in about 2 weeks. Thanks for all of your interest. Please provide feedback. Regards, Ralph 4-Jun-85 13:36:05-MDT,829;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 4 Jun 85 13:35:23-MDT Received: from oslo-vax.arpa by AMSAA.ARPA id a001267; 4 Jun 85 7:50 EDT Received: by oslo-vax.ARPA (4.12/4.7) id AA08655; Mon, 3 Jun 85 09:03:53 -0100 Date: 3 Jun 1985 09:00-EST From: Bj|rn Larsen Subject: Re: TOPS20 style parsing To: info-cpm-request@AMSAA.ARPA Message-Id: <486633658/blarsen@oslo-vax> In-Reply-To: info-cpm-request@AMSAA.ARPA's message of Thu, 1-Jan-70 00:59:59 MET Resent-Date: Tue, 4 Jun 85 14:48:12 EDT Resent-From: cpmlist@AMSAA.ARPA Resent-To: info-cpm@oslo-vax.ARPA There is no such thing as a PDP-20 computer. The processor running TOPS-20 is a PDP-10, most commonly a model KL10 (on DECSYSTEM-2060's) or a KS10 (on DECSYSTEM-2020's). 4-Jun-85 13:47:17-MDT,644;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 4 Jun 85 13:42:44-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a029412; 4 Jun 85 14:55 EDT Received: from usenet by TGR.BRL.ARPA id a018050; 4 Jun 85 14:42 EDT From: Rick Johnson Newsgroups: net.micro,net.micro.cpm Subject: termcap entry for DEC Rainbow Message-ID: <2867@ncsu.UUCP> Date: 1 Jun 85 22:46:17 GMT Xref: seismo net.micro:11259 net.micro.cpm:4567 To: info-cpm@AMSAA.ARPA # Would someone send me or post a termcap entry for a DEC Rainbow. Thanks. Rick Johnson ...decvax!mcnc!ncsu!rlj 4-Jun-85 14:30:32-MDT,823;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 4 Jun 85 14:28:47-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a000511; 4 Jun 85 15:07 EDT Received: from usenet by TGR.BRL.ARPA id a018615; 4 Jun 85 14:56 EDT From: oacb2 Newsgroups: net.micro.cpm Subject: Re: Re: EMACS for CP/M, MINCE, and SCRIBBLE Message-ID: <1784@ut-ngp.UUCP> Date: 4 Jun 85 16:04:24 GMT To: info-cpm@AMSAA.ARPA > However, Mince could handle files larger than 64K wheras Perfect Writer > didn't seem to. Even with a huge >128K swap file. I often use Perfect Writer with files larger than 64K. I think the largest I've ever edited with it is about 180K. I use a 248K swap file. -- Mike Rubenstein, OACB, UT Medical Branch, Galveston TX 77550 4-Jun-85 16:09:23-MDT,716;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 4 Jun 85 16:07:40-MDT Received: from mit-mc.arpa by AMSAA.ARPA id a004381; 4 Jun 85 17:36 EDT Date: Tue, 4 Jun 85 17:36:04 EST From: Herb Lin Subject: EMACS for CP/M, MINCE, and SCRIBBLE To: info-cpm@AMSAA.ARPA cc: LIN@MIT-MC.ARPA In-reply-to: Msg of 4 Jun 85 16:04:24 GMT from oacb2 Message-ID: <[MIT-MC.ARPA].530244.850604.LIN> > However, Mince could handle files larger than 64K wheras Perfect Writer > didn't seem to. Even with a huge >128K swap file. PW seems able to handle huge files; you just have to wait longer to do the swapping. 4-Jun-85 17:23:14-MDT,586;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 4 Jun 85 17:18:35-MDT Received: from ames-vmsb.arpa by AMSAA.ARPA id a004505; 4 Jun 85 18:32 EDT Date: 4 Jun 85 15:23:00 PDT From: max.hartman@ames-vmsb.ARPA Subject: --- Kaypro & hard-disks --- To: info-cpm@AMSAA.ARPA Reply-To: max.hartman@ames-vmsb.ARPA Does anyone know if it is possible to put a 10-meg (or any high-density mass storage) hard disk on a KayPro?? If so, what is required & what is the expected cost?? -Richard Hartman max.hartman@ames-vmsb ------ 4-Jun-85 18:01:55-MDT,505;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 4 Jun 85 18:00:59-MDT Received: from jpl-vlsi.arpa by AMSAA.ARPA id a004552; 4 Jun 85 18:55 EDT Date: 4 Jun 1985 1550 PST From: "Richard B. August" Subject: VT-100 terminal emulation program for Z80/APPLE To: info-cpm@AMSAA.ARPA Reply-To: AUGUST@JPL-VLSI.ARPA Do you know of such a program? Where one may obtain this program? If so please respond. Regards, Richard ------ 4-Jun-85 19:34:28-MDT,2067;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 4 Jun 85 19:29:37-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a004813; 4 Jun 85 20:51 EDT Received: from usenet by TGR.BRL.ARPA id a024296; 4 Jun 85 20:40 EDT From: Kenn Barry Newsgroups: net.micro.68k,net.micro.cpm Subject: Re: Need modem program for CP/M 68K (summary) Message-ID: <1016@ames.UUCP> Date: 4 Jun 85 21:13:38 GMT Xref: seismo net.micro.68k:922 net.micro.cpm:4569 To: info-cpm@AMSAA.ARPA I haven't been able to send individual responses to all the many people who answered my request for help in finding a modem program for a CP/M-68K system, so I'd like to say "thanks" to all of you here; I was most gratified at the number of helpful responses I received. The most common recommendation was for YAM, for which there is source code (in C) on SIMTEL20. Also recommended were KERMIT, and Lmodem, a short C program which was published in Byte. None of these, of course, are specifically for CP/M-68K systems, though they could be adapted. Fortunately, a couple of people who responded had versions of either Xmodem or KERMIT that had been adapted for CP/M-68K, and I'm hoping to receive this code shortly. By the way, we solved our immediate problem (files on the ERG that needed to be sent to UN*X *quickly*) by hooking an Apple II to the ERG as a terminal, capturing the files on Apple disks, and then hooking up the Apple as a UN*X terminal and porting the files once more. A kluge, but a successful one. With luck, we'll have a better system ready for the next batch of files. Thanks again to all who responded to my request for help. - From the Crow's Nest - Kenn Barry NASA-Ames Research Center Moffett Field, CA ------------------------------------------------------------------------------- USENET: {ihnp4,vortex,dual,nsc,hao,hplabs}!ames!barry 4-Jun-85 19:54:29-MDT,1998;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 4 Jun 85 19:51:46-MDT Received: from usc-ecl.arpa by AMSAA.ARPA id a004797; 4 Jun 85 20:44 EDT Date: 4 Jun 1985 1739-PDT From: BHUBER@USC-ECL.ARPA Subject: Re: VT-100 terminal emulation program for Z80/APPLE To: AUGUST@jpl-vlsi.ARPA, info-cpm@AMSAA.ARPA cc: BHUBER@usc-ecl.ARPA In response to the message sent 4 Jun 1985 1550 PST from AUGUST@JPL-VLSI.ARPA There is a software package called MITE+ (with emulation option) which provides Apple CP/M systems with emulation of 94 terminal types, of which the popular DEC terminals are included. Be aware of the fact that, depending upon the hardware CP/M implementation, the scrolling of the monitor at speeds above 300 bps may cause "character loss". I put the phrase character loss in quotes because the characters really are received, but not displayed. I do file transfers using XMODEM with this program at 1200 bps and never had a fault. Uploading or downloading files without a protocol wrapped around the transmission can be interesting at speeds greater than 300 bps, however. Regular interactive sessions at 1200 bps also display this character loss problem. Mite+ does just about everything you could ask for. Other than this Apple hardware problem, I am completely satisfied with MITE+. (By the way, the '94' terminal types mentioned above is NOT a typo; that is for real!) If you want to run VT-100 emulation in ProDOS, Apple's ACCESS II software package runs great, even at 1200 bps. Also will emulate a VT-52. Bud P.S., MITE+ costs about $150 to $200 depending on where you buy it. The company is in Florida. I found their technical support to be outstanding. I needed help from them because when they went to a new major release of the software earlier this year, they had a hammered .COM file. They FedExed new diskettes (Saturday delivery option also) at their expense! ------- 4-Jun-85 20:48:43-MDT,4028;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 4 Jun 85 20:46:58-MDT Received: from mit-mc.arpa by AMSAA.ARPA id a005001; 4 Jun 85 22:04 EDT Date: Tue, 4 Jun 85 22:04:31 EST From: Herb Lin Subject: list of portables... To: ibmpc@USC-ISIB.ARPA, info-cpm@AMSAA.ARPA cc: LIN@MIT-MC.ARPA Message-ID: <[MIT-MC.ARPA].530671.850604.LIN> some time ago, I asked people to pass along suggestions for portables. Here's what I got back. 05/27/85 10:53:10,442;000000000000 Date: 27 May 85 10:25:57 EDT (Mon) From: Jeff Edelheit To: lin at mit-mc.ARPA Re: true portables For what it's worth, I was fairly impressed with the DG/1. I was shown a pre-production version and found that the screen was a little bit difficult to read, but I understand that has been corrected. I really liked the idea of being able to attach a 5.25" drive to it. Jeff Edelheit (edelheit@mitre) 05/27/85 10:53:23,300;000000000000 Date: Mon, 27 May 85 03:20:24 EST From: Jerry E. Pournelle To: LIN Re: true portables HP is Real; Good with software etc but BUT BUT I at least cannot wsee the oops cannot see the display. Alas. Data G 1 has better visibility but not as good software. There is no best. jep 05/27/85 19:11:31,211;000000000000 Date: 27 May 1985 11:44-EDT From: SCHNUR at USC-ISI.ARPA To: LIN at MIT-MC.ARPA Re: true portables looking for people who have tried out in real world test the new Gridcase. It looks great onpaper. 05/27/85 19:12:24,488;000000000000 Date: Mon, 27 May 1985 13:25 EDT From: Robert L. Krawitz Sender: ZZZ.RLK%MIT-OZ at MIT-MC.ARPA To: Herb Lin Re: true portables My favorite: HP portable. Why: better processor than the others (8086 vs 8088). Plenty of memory. Matched portable components (disk drive, printer) that apparently work well in portable mode. Rugged (rated to take 100G shock on all sides according to Creative Computing). Robert 05/28/85 14:30:07,1204;000000000000 Date: Mon, 27 May 85 21:09:56 EST From: Eric Stork To: LIN Re: true portables Herb, I use the PX-8 (EPSON) while traveling. I got the 120k add-on memory, which makes the whole thing very practical. I have no trouble working on a cross-country flight (about five hours), and then recharging. I do not know what the limit is have not reached it. I dumpt to (and from) my S-100 system, using a version of MODEM2 set up for the PX-8 by C>Strom of NYU. Works great, at 4800 baud or better. The only problem is getting the MODEM program on the unit. No way to do it but get a friend who has one to make up a micro cassette and send it to you. That's what Strom did for me, and I'll be glad to help others. Using some sort of pyramid, one could easily cover the need - each one serve three, or something like that. Cost: With discounts easily available locally, I paid abotu $1100 for the unit PLUS the 120k add-on. If you get one, get the simplest possible cable (no tying of pins in the cable), and do your own typing by mating the Epson cable to a DB-25 female connector and then to whatever you like. If you want nore data, respond direct to me. Eric Stork 05/28/85 14:30:50,657;000000000000 Date: 28 May 1985 06:31-PDT From: STANLEY at USC-ECLB To: lin Re: True Portables Herb, My vote is for the Radio Shack Model 100 for most portable uses. Pros: Truly portable--fits in my briefcase Adequate wordprocessing that downloads to WordStar via RS232 port Runs on batteries or AC power Rugged Good keyboard Cons: Won't do "fancy" things (but I don't usually do those away from my desk anyway) on-volatile storage via cassette tape can be a problem sometimes If you`re away from a power outlet, batteries last only 3-4 hourr ...Dick P.S. Added pro--it's cheap!! 5-Jun-85 07:22:39-MDT,1406;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 5 Jun 85 07:21:48-MDT Received: from office-2.arpa by AMSAA.ARPA id a008954; 5 Jun 85 8:43 EDT Date: 4-Jun-85 20:51 PDT From: Alan Bomberger Subject: Microsoft Applcard To: info-cpm@AMSAA.ARPA Message-ID: There is a 60K CP/M for the Microsoft Applecard which seems to be a Z80 version of the BDOS. Is this Z80 version of BDOS a standard from DR or is this something special. Is this the version of BDOS that runs on the Osborne Vixen? Second question: The 60K CP/M for the Applecard seems to be a "split system" in that the BIOS is above a 4K hole in the memory space of the Z80 (I assume this is for the 6502) yet I cannot seem to locate a BIOS jump table after the BDOS that is the mirror of the one pointed to by the JMP at location 0 (BIOS seems to be at FAxx) as in the Northstar "split-system". Is there one or does this version of the BDOS use the "pointer" at location 1? How large is this Z80 version? (I may have missed the Jump table not knowing where to look. It is certainly not E00 bytes above the BDOS entry as one would expect) (disassembly of the first few instructions showed a few cases where the Z80 code was just as long as the 8080 version.) Thanks in advance for any infor you can provide! 5-Jun-85 11:41:21-MDT,1217;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 5 Jun 85 11:39:50-MDT Received: from crdc-vax2.arpa by AMSAA.ARPA id a024743; 5 Jun 85 13:03 EDT Date: Wed, 5 Jun 85 13:00:35 EDT From: "Jack H. Smith" To: info-cpm@AMSAA.ARPA Subject: splitter Dear Friends: Last August (l984) a fellow named MIKE NAULT submitted a program named 'splitter' which allowed one to 'split' large files into smaller ones. The splitter.lbr is located in MICRO: at SIMTEL20. My problem is this: When I try to use the program, it prompts me for which file to split and after I enter the file- name and press return, the program goes haywire. Could someone send me a good copy of splitter.asm, so that I can assemble and load it myself? I'm running CP/M 2.2 on a Intertech compustar model 10 with a DSS-10 Winchester, and an Intertech Compustar model 30 stand-alone or chained-into the hard disk. I really need a program like 'Splitter' and if I can't get it to work, I may have to write a new program from scratch. Please, help if you can..... Thanks much , Jack H. Smith 5-Jun-85 21:42:50-MDT,750;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 5 Jun 85 21:39:00-MDT Received: from simtel20.arpa by AMSAA.ARPA id a006280; 5 Jun 85 16:51 EDT Date: Wed, 5 Jun 1985 14:51 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: remote CP/M user's guide now available A remote CP/M user's guide was recently uploaded to my system and is now available via FTP from SIMTEL20 in two forms: Filename Type Bytes CRC Directory MICRO: RCPM-UG.PRN.1 ASCII 53332 A3CEH <--ready to print RCPM-UG.WQ.1 BINARY 33792 84DBH <--a WordStar document file --Keith 5-Jun-85 22:21:54-MDT,431;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 5 Jun 85 22:19:00-MDT Received: from simtel20.arpa by AMSAA.ARPA id a009836; 5 Jun 85 23:23 EDT Date: Wed 5 Jun 85 20:55:26-MDT From: Jon Albers Subject: Osborne Executive BYE To: info-cpm@AMSAA.ARPA I am looking for a version of bye for the Osborne Executive. Please reply to me ASAP. ------- 5-Jun-85 23:42:57-MDT,1360;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 5 Jun 85 23:40:47-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a010446; 6 Jun 85 1:15 EDT Received: from usenet by TGR.BRL.ARPA id a002281; 6 Jun 85 0:58 EDT From: jp@LANL.ARPA Newsgroups: net.micro,net.micro.cpm,net.wanted Subject: Info needed on CPT disk format Message-ID: <26814@lanl.ARPA> Date: 5 Jun 85 07:10:40 GMT Xref: seismo net.micro:11274 net.micro.cpm:4570 net.wanted:6936 To: info-cpm@AMSAA.ARPA I want to transfer files from the 8" disks of a CPT 7800 word processor system to a VAX 750. I was planning to do this via my CP/M system since I have a program which will write VAX readable files from CP/M and I am sufficiently familiar with my BIOS to create the disk tables needed to read foreign format disks. However, there is one small stumbling block. I don't have sufficient information about the CPT format to accomplish this. My controller seems to think that it is formatted in 256 byte sectors, but I have not been able to log a CPT disk on to look at it with DU. Does anyone have the information I need to solve this problem or to convince me that it is unsolvable? Alternatively, does any one know how to go from the CPT to the VAX (and vice versa) directly? Thanks, Jim Potter jp@lanl.arpa 6-Jun-85 00:51:42-MDT,7441;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 6 Jun 85 00:46:27-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a010691; 6 Jun 85 1:51 EDT Received: from usenet by TGR.BRL.ARPA id a003809; 6 Jun 85 1:42 EDT From: "R.Thomas" Newsgroups: net.micro.apple,net.micro.cpm Subject: Re: Wordstar/Appli-Card offer query Message-ID: <536@sftig.UUCP> Date: 3 Jun 85 22:00:15 GMT Xref: seismo net.micro.apple:2074 net.micro.cpm:4571 To: info-cpm@AMSAA.ARPA The time has come for me to summarize what I have learned about the PCPI Applicard for all you folks out there who have helped me in my search for information. First -- The manuals that come with the Starcard (The name for the Applicard when it is bundled with Wordstar.) are full of typos and not exceedingly detailed. If you can read around the typos, they are reasonably good cook-books for getting CPM and Wordstar up and running, but they will not make a CPM hacker out of you. I have not heard that PCPI's own manuals are any better. All is not completely lost though, because there is a friendly person at the end of a PCPI technical hot-line who can send you xerox copies of various napkins (and such) on on which the software/hardware developers have scribbled down the real poop. In addition, there is an 'OEM Package' that PCPI will sell you for 50 bucks which consists of a double-sided disk full of software and about 35 pages of badly xeroxed notes. The above mentioned napkins are in addition to these notes, and necessary for a real understanding of what is going on. If you have looked at all of the above and are still curious about what is going on, you can offer to sign a non-disclosure agreement, and they may consent to send you the source code for the various drivers. Then again, they may not. I haven't gotten my copy of the non-disclosure agreement yet, so I don't know how stringent it is, or what happens after you sign it and send it back to them. Second -- It runs CPM2.2 just great. I have Turbo Pascal for CPM/80 running on it and am much impressed with the speed and convenience of the package. The 6MHZ Z80B processor is *FAST*. On the other hand, since the Z80 and the 6502 do not share any memory, (The Z80 has its own 64K of fast DRAM. You can buy a piggy-back card that will expand it to about a half-Meg) the communication between the two cpu's is restricted to a single one-byte-wide I/O port and a couple of flag bits. Even with a dedicated server running on the 6502, this means that the Z80 can't write on the Apple's 80col screen at higher than a few hundred characters/second. (Disk accesses are significantly faster, because they use block-mode transfers in which the Z80 tells the 6502 how many characters to expect then sends them all in a burst. Character devices like the 80col screen are restricted to a single byte at a time, so the overhead is much higher.) Since the nitty-gritty I/O is all handled by the 6502 side, the BIOS on the Z80 side can afford to be very small. This leads to a remarkably large 57K Transient Program Area. You can run larger programs on it than you can on the Microsoft card. (Further comments on differences between this card and the Microsoft card later.) Third -- The terminal emulator that runs on the 6502 side and manipulates the Apple 80col screen is excessively dumb. It seems to lack character/line insert/delete sequences. If anybody knows differently, please speak up. It hurts to watch the screen get repainted just to insert a line at the top. I sincerely hope that this is just a misfeature of the Turbo Pascal editor, which I otherwise like very much. Fourth -- it is *not* compatible with the Microsoft CPM card. It will not run anything that assumes hardware features of that card. However, it *will* run just about any generic CPM program, of which there are a multitude! The price you pay for the blazingly fast CPU is incompatibility with the 'standard' Microsoft card. The worst part of this is that it will not run the drivers that give you access to the Profile hard disk from CPM. (Does anybody know if the Sider has a driver that runs on the Applicard?) The person on the hot-line hinted that PCPI would sell you a driver written by someone in Australia that gave the Applicard access to a Profile, but he didn't make it sound like it was compatible with much. In particular, I think he said that if you used that driver, you couldn't use your Profile with Prodos. He didn't know for sure, but I expect that there is no provision for partitioning the disk. I asked about software from third-party sources, but (while he said they did keep a registry of such) he couldn't point me at anybody who could help me with my specific problems. Which brings me to -- Fifth -- They supply a driver that runs under DOS3.3 and turns the Applicard into a ramdisk, with up to a half meg of memory if you buy the piggyback cards (300 bucks for 256K -- a trifle expensive for today's market -- maybe mailorder places have them cheaper.) However, they do not supply a corresponding driver for Prodos. I assume that the Prodos driver would be a snap, given the code for the DOS3.3 driver, but nobody at PCPI has seen fit to do it yet. Sounds like a market for a 3rd party in there somewhere! I have used the DOS3.3 driver, it works very well. Sixth and finally -- They supply a printer driver that uses the left-over 6502-side ram (including the Alternate bank on the 80-column card, if one exists) as a printer buffer (up to 80K in my configuration, IIe with extended 80 Column color card.) But it seems to me that a much better use for that memory would be as a ramdisk for CPM (with maybe a 16K buffer reserved for the printer driver.) The tech-support hot-line person did not know of any such driver -- sounds like another 3rd party opportunity! > > I recently received an advertisement from Broadreach > for Wordstar and the Appli-Card CP/M card for $164.95. This is a very good price! > It lists features of the Appli-Card, but doesn't specify > whether all the software and manuals necessary to use > the features are included in the package. If this is the Micropro Starcard package, they are included, but see above. The manuals are not very detailed. > If anyone has experience with the Appli-Card, or this offer, > please send me your opinion. > > In particular, does the 6Mhz Appli-card run all CP/M software? > Are preboots needed? Runs everything I have come across, but I have not experimented widely. Also, see above regarding Microsoft compatibility. > Is the manual sufficient to learn CP/M? No. Go buy a good book. Don't count on the manuals. > Are there needed utilities that are not included with Appli-Card? Everything you need to configure it and get CPM up and running is included. There is the DRI assembler and editor and DDT (and PIP and stat, and so on) but no 'higher level' languages. I recommend buying Turbo Pascal. > The ad says the 64K ram on the card can be used as > RAM/Disk for DOS3.3. Has anyone used the Applicard in > this way? Yes, see above. > > Thanks, > > David Lazar > ihuxk!dcl55611 Rick Thomas {ihnp4,akgua,sdcsvax,just about anywhere}!attunix!rbt (201)-522-6062 6-Jun-85 00:56:43-MDT,665;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 6 Jun 85 00:54:03-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a010822; 6 Jun 85 2:05 EDT Received: from usenet by TGR.BRL.ARPA id a004089; 6 Jun 85 1:49 EDT From: Litzhoff Newsgroups: net.micro.cpm Subject: (wanted) database or stock packages Message-ID: <474@ihu1e.UUCP> Date: 4 Jun 85 22:40:09 GMT To: info-cpm@AMSAA.ARPA Help. I am looking for stock market packages that run under CPM OS. Or a cheap database that iI can construct my own stock packages. I would appreciate the names of any vendor and their cost. 6-Jun-85 07:30:58-MDT,1352;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 6 Jun 85 07:27:46-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a016490; 6 Jun 85 8:46 EDT Received: from usenet by TGR.BRL.ARPA id a009873; 6 Jun 85 8:41 EDT From: George Smith Newsgroups: net.micro.cpm,net.lang.pascal,net.micro.pc Subject: Re: BORLAND TURBO PASCAL (Really how to contact TUG) Message-ID: <783@voder.UUCP> Date: 4 Jun 85 05:10:06 GMT Xref: seismo net.micro.cpm:4573 net.lang.pascal:331 net.micro.pc:4483 To: info-cpm@AMSAA.ARPA *** REPLACE THIS LINE WITH YOUR USER GROUP *** > How does one get hold of Tug Lines (I presume that Tug is some kind of Turbo > User's Group) > Rick Thomas > {akgua,ihnp4,sdcsvax,just about anywhere}!attunix!rbt > From the last issue of TUG Lines (V1#5, Feb/Mar 85): TUG Lines is published bi-monthly by the Turbo User Group, PO Box 1510, Poulsbo, WA 98370. Membership in TUG is for one year from receipt of your application. Membership fee is $20.00. This latest issue contained a large list of known bugs with fixes and workarounds along with much info on using Turbo, lots of source code, new products, etc. Highly recommended! -- George B. Smith National Semiconductor ...!{ihnp4!nsc | decvax!decwrl!nsc | ucbvax}!voder!gbs 6-Jun-85 07:46:02-MDT,2045;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 6 Jun 85 07:45:14-MDT Received: from usc-isid.arpa by AMSAA.ARPA id a018354; 6 Jun 85 9:02 EDT Date: 6 Jun 1985 09:02-EDT Sender: ABN.COSCOM-CE@USC-ISID.ARPA Subject: Re: Info needed on CPT disk format From: ABN.COSCOM-CE@USC-ISID.ARPA To: jp@LANL.ARPA Cc: info-cpm@AMSAA.ARPA, abn.coscom-ce@USC-ISID.ARPA Message-ID: <[USC-ISID.ARPA] 6-Jun-85 09:02:00.ABN.COSCOM-CE> In-Reply-To: <26814@lanl.ARPA> What I would recommend is that you give CPT a call. We have a CPT Word Processing system but no correspondence on the technical characteristics of the disks. The phone number for CPT (Minnesota) is (612)937-8000. I hope that this will help. Text: ------------------------------ <<>> From: jp@LANL.ARPA To: info-cpm@AMSAA.ARPA Subject: Info needed on CPT disk format I want to transfer files from the 8" disks of a CPT 7800 word processor system to a VAX 750. I was planning to do this via my CP/M system since I have a program which will write VAX readable files from CP/M and I am sufficiently familiar with my BIOS to create the disk tables needed to read foreign format disks. However, there is one small stumbling block. I don't have sufficient information about the CPT format to accomplish this. My controller seems to think that it is formatted in 256 byte sectors, but I have not been able to log a CPT disk on to look at it with DU. Does anyone have the information I need to solve this problem or to convince me that it is unsolvable? Alternatively, does any one know how to go from the CPT to the VAX (and vice versa) directly? Thanks, Jim Potter jp@lanl.arpa Text: <<>> ------------------------------ JOSEPH LOGAN WO1 USAR 1st COSCOM @ISID.ARPA 6-Jun-85 13:16:47-MDT,768;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 6 Jun 85 13:13:08-MDT Date: Thu, 6 Jun 85 14:27:15 EDT From: David Towson (SECAD) To: info-cpm@AMSAA.ARPA Subject: Rejected mail to hlp.lr@mit-speech. Fellow CP/Mers - Anyone sending a message to info-cpm in the last couple days has probably received a rejection message for the subject address, which is over-quota (no more disk space). This address is not in the info-cpm distribution list, and is probably included in a re-distribution list somewhere at MIT. I have sent a request for help to the MIT post- master, and I hope to have this cleared up soon. Dave towson@amsaa.arpa aka info-cpm-request@amsaa.arpa 6-Jun-85 13:17:03-MDT,1035;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 6 Jun 85 13:13:58-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a017129; 6 Jun 85 14:34 EDT Received: from usenet by TGR.BRL.ARPA id a019034; 6 Jun 85 14:22 EDT From: Stephen Hemminger Newsgroups: net.micro.cpm Subject: How do you turn off auto-answer (Rixon modem). Message-ID: <1296@hammer.UUCP> Date: 4 Jun 85 02:34:25 GMT To: info-cpm@AMSAA.ARPA Quick question: how do you turn out off the auto-answer on a Rixon 212 modem. Is there some Rs-232 control line to do it? Is there something you can program in the NOV ram? do you have to go into Hayes mode to do it? The relatives would appreciate this! ___________________________________________________________ |--| |--| [I'd rather be skiing] | /| | /| . |/ | |/ | .|--| |--| | .| | | Stephen Hemminger | |. | | . ...!ihnp4!tektronix!hammer!steveh 6-Jun-85 15:00:39-MDT,1204;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 6 Jun 85 14:59:35-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a023351; 6 Jun 85 16:05 EDT Received: from usenet by TGR.BRL.ARPA id a021983; 6 Jun 85 15:57 EDT From: "R.Thomas" Newsgroups: net.micro.cpm Subject: Re: BORLAND TURBO PASCAL - New release (CP/M Version) (Really Message-ID: <537@sftig.UUCP> Date: 5 Jun 85 20:08:12 GMT To: info-cpm@AMSAA.ARPA > Re: Recursion > Turbo does indeed support recursion if the proper compiler directive is set. > The issue is whether or not is supports standard pascal recursion -it appar- > ently does not, since it does not allow the passing of *local* variables to > recursive modules by reference. It works fine with globavariables. I doubt > that Borland considers this a "bug" since they designed the software that way. > > steveswillett What *DOES* happen if you try to pass local variables as var parameters? If the behavior is well-defined, it may be useful, even if it is not standard. Anybody know for sure? Is there somebody from Borland out there who can answer definitively? Rick Thomas 6-Jun-85 20:52:53-MDT,922;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 6 Jun 85 20:49:00-MDT Received: from think.arpa by AMSAA.ARPA id a027335; 6 Jun 85 22:20 EDT Received: by THINK.ARPA with CHAOS id AA00894; Thu, 6 Jun 85 22:17:07 edt Date: Thu, 6 Jun 85 22:18 EDT From: Cliff Lasser Subject: power supply protectors. To: INFO-CPM@AMSAA.ARPA Message-Id: <850606221802.4.CAL@DESIDERIUS.ARPA> I have some friends in Vermont who have had bad luck with the maintenance of their PCs. All of them live in fairly old houses with old wiring. It has been suggested that the power in their homes is responsable for the frequent deaths of power supplies and floppy drives. Might there be some truth to this? Does anyone know of a power conditioner that is recommended for solving this type of problem? Where might I get more info on this topic? -Thanx, Cliff 6-Jun-85 22:31:38-MDT,766;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Thu 6 Jun 85 22:28:00-MDT Received: from simtel20.arpa by AMSAA.ARPA id a027584; 6 Jun 85 23:54 EDT Date: Thu, 6 Jun 1985 21:54 MDT Message-ID: From: WANCHO@SIMTEL20.ARPA To: INFO-CPM@AMSAA.ARPA, INFO-IBMPC@usc-isib.ARPA, INFO-MICRO@brl.ARPA Subject: [SIMTEL20]MICRO: Under Construction The PC/BLUE Collection on SIMTEL20 is in the process of being reloaded from scratch up to Volume 124. This time we're doing it right, with the loan of a real IBM PC running MEX-PC. It's going to take a while. Look for another announcement in a couple of weeks. In the meantime, peek at your own risk. --Frank 7-Jun-85 08:12:31-MDT,830;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 7 Jun 85 08:11:04-MDT Received: from 26.4.0.106 by AMSAA.ARPA id a004487; 7 Jun 85 9:35 EDT Date: 7 Jun 85 09:26 EDT From: dbrothers@DDN1.ARPA Subject: My account is moving to DDN2 on June 17th To: mundy@DDN1.ARPA, info-cpm@AMSAA.ARPA, info-ibmpc@USC-ISIB.ARPA On the 17th of June, my account will be moved to DDN2. Therefore, any mail sent to me on, or after that date should be addressed to dbrothers-at-DDN2. Sorry for the inconvenience. The system administrator tells me that this will relive congestion on DDN1 and also give me access to a less-used host. This should result in faster service for users of DDN1. I only hope the DDN2 users don't resent the slowdon due to the additional users. D oug Brothers 7-Jun-85 09:17:11-MDT,1686;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 7 Jun 85 09:14:49-MDT Received: from usc-isid.arpa by AMSAA.ARPA id a006722; 7 Jun 85 10:22 EDT Date: 7 Jun 1985 06:57-EDT Sender: ABN.ISCAMS@USC-ISID.ARPA Subject: Re: power supply protectors. From: ABN.ISCAMS@USC-ISID.ARPA To: CAL@THINK.ARPA Cc: INFO-CPM@AMSAA.ARPA Message-ID: <[USC-ISID.ARPA] 7-Jun-85 06:57:02.ABN.ISCAMS> In-Reply-To: <850606221802.4.CAL@DESIDERIUS.ARPA> Cliff, et al, Re maybe old houses with old wiring producing "bad" power, killing power supplies and floppy drives. Well, old, underwired houses might cause a voltage drop by the time it gets to the PC, but a quick test (well, maybe an extended watching) with any old voltmeter would tell you something about that. If there is low voltage, the good old Sola variable voltage transformers are great for that. I ran a bushel of Apples in tactical environments at Fort Bragg and Germany, HORRIBLE electricity, and there was nothing like a boat anchor Sola to bring the voltage up to snuff. If rats are chewing/dancing on the wires and causing spikes, most of your (relatively) inexpensive isolators could strip the spikes out. Combination of Sola transformer and any old isolator usually served us just fine, commonly running with 85 volts AC, fluctuating up to 140 volts when the generator operator let the RPM run away, no-notice shutdowns and startups, lightning through the trees and dancing through the tents, spikes and drops making color monitors look like oscilloscopes... Plus you can keep your feet/coffee warm on the Sola. Regards, David Kirschbaum Toad Hall 7-Jun-85 10:27:28-MDT,1591;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 7 Jun 85 10:24:20-MDT Received: from simtel20.arpa by AMSAA.ARPA id a010933; 7 Jun 85 11:42 EDT Date: Fri 7 Jun 85 09:41:49-MDT From: "William G. Martin" Subject: Re: power supply protectors. To: ABN.ISCAMS@USC-ISID.ARPA cc: info-cpm@AMSAA.ARPA, cal@THINK.ARPA, wmartin@ALMSA-1.ARPA In-Reply-To: Message from "ABN.ISCAMS@USC-ISID.ARPA" of Fri 7 Jun 85 04:57:00-MDT For what it's worth, my house had old wiring when I bought it, with fuses on both the hot and neutral sides of the line. Once, some really strange situation developed, involving intermittent connections or blown fuses on the neutral side, which ended up feeding 220 V into some of my 110 V circuits! The refrigerator and freezer on the affected circuit did NOT like this :-) (luckily, built-in protection circuits shut them off and it seemed no lasting harm was done, thank goodness!) -- however, you would find it interesting how quickly a 110-volt light bulb burns out on 220 V (and how brightly it shines! [for a while :-]). That wiring has since been replaced. Why I post this is to note that flaky old wiring can sometimes produce other effects than simple resistance losses. I wouldn't be surprised to measure widely-fluctuating voltages or spikes or surges at the affected computers' power outlets. It would be worth running a single isolated newly-wired circuit from the main power box to the computer site; this can usually be done inexpensively. Will Martin ------- 7-Jun-85 11:00:33-MDT,1436;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 7 Jun 85 10:57:59-MDT Received: from ornl-msr.arpa by AMSAA.ARPA id a011273; 7 Jun 85 12:14 EDT Received: by ornl-msr.ARPA (4.12/4.7) id AA04537; Fri, 7 Jun 85 11:54:44 edt Date: Fri, 7 Jun 85 11:54:44 edt From: "James A. Mullens" Message-Id: <8506071554.AA04537@ornl-msr.ARPA> To: CAL@THINK.ARPA, INFO-CPM@AMSAA.ARPA Subject: Re: power supply protectors. Here is some (possibly) related data. I have an Apple, an IBM PC, and a Sage II in the same room at my house. The IBM is clearly more sensitive to power fluctuations than the other two (it has full AST 6-pack, dual floppies, and color display). I suspect my house has strange wiring because I blow a lot of light bulbs. I have also had a lot of problems with my IBM. I have had 4 separate problems on 3 separate AST 6-pack boards, occasional memory parity halts, and a CPU failure. (I have a hot 8087 right next to the CPU and have wondered about heat problems though). I have not had problems like this with any other computer. I put el cheapo Radio Shack surge protectors on my lines. These are supposed to protect against "x" surge events, and have a small light which goes out when they are used up. I have had them installed for several months. No more IBM problems yet, but the surge lights have not gone out either.. q 7-Jun-85 12:19:05-MDT,1460;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 7 Jun 85 12:18:50-MDT Received: from su-star.arpa by AMSAA.ARPA id a012757; 7 Jun 85 13:19 EDT Date: 7 Jun 85 10:05:00 PDT From: "R. Meier" Subject: vt-100 terminal emulation program for z80/apple To: info-cpm Reply-To: "R. Meier" Richard, Kermit is a public domain file transfer protocol which includes vt52 terminal emulation. You can obtain kermit from Columbia-20 (after 6pm EDT) or from SIMTEL20 (). I hgith recommend it for interprocessor communication. It can be easily modified to simulate a vt100 instead of a vt52 (sans graphics). If you just need the vt100 emulation, then in your cp/m handbook note the description of the bios functions for the terminal. All versions of cp/m that I know of for the Apple use vectors and a translation table for terminal emulation. If your cp/m is such, then making it emulate a vt100 is simply a matter of changing the entries in the translation tables and altering the vectors, to point to routines that will first filter the characters not recognized by translation. (None for vt52). If you need to simulate the graphics of a vt100, then I don't believe that the Apple has the required resolution. If this is not sufficiently helpful, then contact me as rmeier@star.arpa Bob (rmeier@star) ------ 7-Jun-85 12:44:39-MDT,2076;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 7 Jun 85 12:39:54-MDT Received: from rand-unix.arpa by AMSAA.ARPA id a013970; 7 Jun 85 13:38 EDT Received: by rand-unix.ARPA; Fri, 7 Jun 85 10:35:04 pdt From: Bridger Mitchell Message-Id: <8506071735.AA25531@rand-unix.ARPA> Date: 07 Jun 85 10:34:47 PDT (Fri) To: info-cpm@AMSAA.ARPA Subject: Why WordStar can't Run ... ... some bios-calling programs. The WordStar "R" (run) command protects high memory, installs a program loader there, and attempts to load the requested COM file. Before doing so it copies the system bios jump vector to that area, sets warmboot and bdos function 0 traps, and changes 0001h to point to the warmboot entry in this new vector. This causes at least two problems for some software: 1. The new vector is NOT aligned on a page boundary. Many (most?) applications software assumes the bios vector is aligned, and call a bios function by code such as: lhld 1 mvi l,9 ;bios conin function pchl To work with WS the code needs to do the arithmetic: lhld 1 mvi a,9-3 add l mov l,a jnc pchl1 inr h pchl1: pchl 2. By changing 0001, WS has broken the (unwritten?) rule that the system's addresses can be determined at runtime. WS's loader overlay should, instead, patch itself into the warm-boot chain at the bios warmboot address. That way, resident system extensions and other software that needs to locate the system will be able to function under "R". About the best the applications program that needs this information can do is to search for a string of jmps that begin on a page boundary (taking care to note that some bios's replace jmps with in-line code for a few entries). I looked into this after a user noted that some DateStamper utilities wouldn't run inside WS. The new versions do, now. But I imagine there are a lot of our PD utilities that don't. Perhaps revisors could keep this in mind as versions get updated. --bridger mitchell 7-Jun-85 13:39:50-MDT,1158;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 7 Jun 85 13:36:17-MDT Received: from simtel20.arpa by AMSAA.ARPA id a015620; 7 Jun 85 14:33 EDT Date: Fri, 7 Jun 1985 12:33 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: "William G. Martin" Cc: ABN.ISCAMS@USC-ISID.ARPA, cal@THINK.ARPA, wmartin@ALMSA-1.ARPA, Info-Cpm@AMSAA.ARPA Subject: power supply protectors. In-reply-to: Msg of 7 Jun 1985 09:41-MDT from William G. Martin Old houses frequently suffer from loose connections in the fusebox. If the neutrals are loose, you'll have wildly fluctuating voltages on your 110 volt circuits. A friend once found 140 volts on one of his outlets. After tightening the neutrals it returned to normal. Turn off the main breaker so there is no power, then carefully tighten all screws with an INSULATED screwdriver. DANGER!!! the 220 feed is still hot. If you're not comfortable working with hot circuits, leave it alone! Get an electrician. --Keith 9-Jun-85 20:20:40-MDT,692;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 9 Jun 85 20:16:37-MDT Received: from mit-multics.arpa by AMSAA.ARPA id a000186; 9 Jun 85 19:23 EDT Date: Sun, 9 Jun 85 17:34 EDT From: AALevy@MIT-MULTICS.ARPA Subject: Power Problems To: info-cpm@AMSAA.ARPA Message-ID: <850609213458.054624@MIT-MULTICS.ARPA> A previos message mentioned loose neutrals and grounds in old houses. That goes double if you have aluminum wiring. You need to know what you are doing to fix this problem but as I remember there is some sort of paste one uses for aluminum. Houses built during 1970 time period used aluminum. Be carteful, Allan 10-Jun-85 12:12:31-MDT,749;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 10 Jun 85 12:08:35-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a005199; 10 Jun 85 9:06 EDT Received: from usenet by TGR.BRL.ARPA id a001802; 10 Jun 85 8:57 EDT From: Mark Mallett Newsgroups: net.micro.cpm Subject: TOPS20 style parser posting Message-ID: <405@sii.UUCP> Date: 8 Jun 85 17:38:12 GMT To: info-cpm@AMSAA.ARPA Howdy I have posted CMD003, edit level 003 of COMND-TOPS20 style parsing for personal computers, to net.sources. It is in 6 parts plus an introduction which is part 0. Thanks to everybody who responded to my original query. Mark Mallett decvax!sii!mem or ittvax!sii!mem 10-Jun-85 12:17:28-MDT,1843;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 10 Jun 85 12:17:06-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a006222; 10 Jun 85 9:26 EDT Received: from usenet by TGR.BRL.ARPA id a001976; 10 Jun 85 9:02 EDT From: egb Newsgroups: net.micro.cpm Subject: Need Help on CP/MUG Volume 89. Message-ID: <735@burl.UUCP> Date: 8 Jun 85 20:33:28 GMT To: info-cpm@AMSAA.ARPA [] I need some help. Has anyone used the Business Master software on CP/MUG volumes 086 to 090? I'd like to use it to set up an accounting system for our local church, but the crc test on 4 files on Disk 089 show an error. Following are the results on the four files in error: Should Be My copy Filename CRCKLIST.089 CRCKLIST.CRC CRJOTRAN.BAS BA DC OA E2 CRLABELS.BAS FF 91 70 DB CRPPINV .BAS 4E 13 61 23 CRSORT .BAS 8E BB 25 78 All of the other files on all five disks check out OK, but these four files seem to have a problem compared to the CRCKLIST.089 on the disk. The set of disks came from CP/MUG on the West Coast, and I don't know whether it's a problem in the CP/MUG disk-set, or from this particular source. Does anyone have a set so that they could check their copies of these four files and let me know whether I should order a new volume from CP/M Users Group in New York City ? Has anyone used this program set and found it worthwhile ? Many thanks in advance, Ed Baldwin, ihnp4!burl!egb OR akgua!burl!egb 3007 S. Fairway Drive Burlington, N.C. 27215 919-584-5743 10-Jun-85 13:10:19-MDT,533;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 10 Jun 85 13:09:52-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a001235; 10 Jun 85 14:27 EDT Received: from usenet by TGR.BRL.ARPA id a002191; 10 Jun 85 14:06 EDT From: steveh%hammer.uucp@BRL.ARPA Newsgroups: net.micro.cpm Subject: cancel <1296@hammer.UUCP> Message-ID: <1322@hammer.UUCP> Date: 9 Jun 85 00:36:19 GMT Control: cancel <1296@hammer.UUCP> To: info-cpm@AMSAA.ARPA <1296@hammer.UUCP> cancelled from rn. 10-Jun-85 14:49:19-MDT,6177;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 10 Jun 85 14:46:26-MDT Date: Mon, 10 Jun 85 16:02:50 EDT From: David Towson (SECAD) To: info-cpm@AMSAA.ARPA, info-micro@brl.ARPA Subject: OMTI disk controller query - summary of replies. Fellow CP/Mers and other Micronauts - A while ago, I posted to info-cpm and info-micro a request for information on the OMTI 20C winchester disk controller now being sold by the John Meshna surplus house for $150. The response was really super, and I'd like to thank all of you who provided information. For the benefit of anyone looking for a cheap mini-winchester controller, here is a summary of the information I received: The OMTI controller is being offered for $150 by John Meshna in Lynn Massachucetts, (617)595-2275. They have had it in their catalog for quite a while at $250, but they have just lowered the price. I guess the boards weren't moving. Here is what the ad says: "The OMTI 20C board we offer is unused, late style surplus and will handle two (2) 5-1/4" Winchester type drives. Some features of the controllers are: single +5VDC and +12VDC supplies, buffered slew/seek modes, overlapped seeks, auto seek and verify, extensive fault detection, auto head and cylinder switch- ing, full sector buffering 256/512 bytes/sector, 33 or 18 sectors/track (jumper selectable), programmable disc parameters and much more. Price is for the controller card only ... does not include the disc drives or the host adapter for your particular system. We include data on using these boards with Seagate ST506 disc drive in TRS model III & IV, plus a copy of the factory manual." ------------------------------------------------------------------------------ OMTI is very much in business and offers excellent SCSIbus controllers in their 5xxx series. [We] were certainly pleased and pleasantly surprised at the quality of their design (allows many parameters to be set by user thus accom- modating field installation of unanticipated drives etc.) The 20C is an earlier unit from the period when they were principally a second source for DTC controllers. ------------------------------------------------------------------------------ Omti was purchased by Scientific Micro Systems (SMS), and they now make the 5{1,2,3,4}00 series which have 1-1 interleave & write pre-comp for the floppy. The original 20c (which I was using at my house for a few years), works with winchesters fine, but does not have write pre-comp for floppies. A new Omti 5300 is $269. ------------------------------------------------------------------------------ I am responding to your message about the omti controllers. You are probably referring to the ones from Meshna. I have one working one. The other is not known to work, yet. The OMTI's are SASI and the manual that you get will not have enough info on how to program them. There is a well defined protocol that all OMTI controllers use. I am told that the protocol works on these controllers, and it seems to in the system that we have. The price of $150 each makes them very attractive. There are several things that you must be aware of, though. These boards will not support write precompensation at all. Many drives work OK without it, though. The controllers are "high performance" and are reputed to read a track in two revolutions. Presumably write one, also. The one that we have works well with a Maxtor drive (which needs no write precomp.) If you are thinking of using a Maxtor, note that only the "little" drive (65 meg) can be used. The controller will not select enough heads for the bigger ones. It is a microcoded controller using a 2910. It can address 8 heads. By the way, Meshna was very prompt. It took about a week to get the boards. They do run very warm (due to the 2910 and proms,) though. ------------------------------------------------------------------------------ The OMTI controller you mentioned is used in an Alcyon 68K unix box which I have had the pleasure to use for the past year and a half. We have had no problems at all with the controller or disks. The controller has some special features which can come in very handy: Support for DMA 5/5 (5 M fixed, 5 M removable) disk drive fully programmable step rate selection I am considering buying some to replace the western digital controllers which hang occasionally. ------------------------------------------------------------------------------ A friend and I recently bought several surplus OMTI 20D's (same as the 20C except for an added floppy controller chip). We've been running them for >6 months now, and both of us have been quite satisfied with them, as far as they go (they're a bit out-of-date by today's standards). We've written drivers for V7, BSD2.9, and RT11 with no problems (the SASI interface is very similar to the better-known XEBEC controller). They interface with 2 standard ST412 drives and a SASI host adapter, do 256 and 512-byte sectors, up to 2-to-1 interleave, automatic ECC check and correct, etc, etc. They do bad-track replacement in the usual way by marking an alternate track in the bad track's headers - slow, but software-transparent. The various drive-specific delay parameters are all programmable, so it should work with almost any ST412-type drive. Also, the 20C's microcode supports some of the earlier cartridge wini drives (IOMEGA Beta and DMA Systems 5/5) which have been showing up as surplus lately. OMTI still exists - they've been bought by SMS (Scientific Microsystems), although they still use their old name as a trade name. They now have a newer, higher-performance line of controllers - check their ads in recent issues of Electronics Week and other such journals. ------------------------------------------------------------------------------ The bottom line (as they say in the parlance): I ordered one. Thanks again to all who provided the above information. Dave towson@amsaa.arpa 10-Jun-85 22:50:28-MDT,2598;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 10 Jun 85 22:46:40-MDT Received: from aerospace.arpa by AMSAA.ARPA id a009848; 11 Jun 85 0:02 EDT Date: Mon, 10 Jun 85 20:58:43 PDT From: "Richard K. Jennings" To: heath-people@mit-mc.ARPA CC: info-pascal@brl-voc.ARPA, info-cpm@AMSAA.ARPA, info-hz100@radc-tops20.ARPA Subject: Z-89 and TURBO Pascal Problems (ver 3.00A) This is a summary of the problem I seem to be having with the Turbo Pascal version 3.00A for 16 hard Sector CP/M. The problem occurs on Zenith a Z-89 computer of 1978-9 vintage computers. Any help would be most appreciated. 1) The terminal has been installed as per the instructions, to a 'Zenith', which was one of the preset options, and microprocessor speed set to 2MHz, correct for H/Z89. 2) The commands were subsequently also installed, the only problem arising was the inability to create two keystroke commands. As a result I settled with Wordstar secondaries. 3) During experimentation with the editor, two problems arose. The first and most bothersome, was when using the 'insert line' function (IL on my keypad, as well as the Wordstar secondary), the editor would take the current line and place it at the top of the page, leaving a blank line in its place. This always seemed to happen on the first try. On succeeding trys the editor would alternately either correctly insert a line, or place a blank line at the top of the screen, shifting the text between the top of the screen and the cursor, down one line. As a new text line shifted onto the same line as the cursor, it would be blanked out, and this whole thing seems to happen on a purely random basis, sometimes the insert line worked, sometimes it didn't. Also, by refreshing the screen, all text is returned to the screen and any blank lines correctly inserted. The second problem resulted in using the block commands. After marking a block then leaving it, the cursor could only be returned to the block while both were on the same page, (using ~Q~B), also, movement could only be made to the begining of the block, not to the end as indicated by the documentation. This concludes the description of the problem. Please foward any comments to: Richard Jennings ARPA: jennings@aerospace AV: 799-6427 COMM: 408-744-6427 11-Jun-85 08:58:44-MDT,849;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 11 Jun 85 08:55:13-MDT Received: from simtel20.arpa by AMSAA.ARPA id a018987; 11 Jun 85 10:10 EDT Date: Tue, 11 Jun 1985 08:11 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: [STORK: Overlay for RadShack] Date: Sunday, 9 June 1985 19:41-MDT From: Eric Stork To: INFO-MODEM7 at MIT-MC.ARPA Re: Overlay for RadShack Trying to help a friend who has a Radio Shack Model 16, running Pickles & Trout CP/M 2.2 and is getting a modem. Is there an overlay for his system? Of for a system sufficiently similar? Advice will be appreciated, especially by my friend. Eric STORK at MIT-MC 11-Jun-85 10:05:04-MDT,754;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 11 Jun 85 10:03:57-MDT Received: from xerox.arpa by AMSAA.ARPA id a022014; 11 Jun 85 11:25 EDT Received: from Cabernet.MS by ArpaGateway.ms ; 11 JUN 85 08:25:48 PDT From: ssalzman.es@XEROX.ARPA Date: 11 Jun 85 8:24:51 PDT Subject: random numbers To: info-cpm@AMSAA.ARPA Message-ID: <850611-082548-1111@Xerox> Somone has made several files available for FTP that are supposed to be good random number generators for 8 bit machines. I lost the message that said where the stuff was, spo can someone please forward that info to me. Sorry about sending this out to all of info-cpm. THanks in advance... Isaac Salzman (SSalzman.es@Xerox) 11-Jun-85 12:36:54-MDT,1580;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 11 Jun 85 12:33:14-MDT Received: from simtel20.arpa by AMSAA.ARPA id a026436; 11 Jun 85 13:50 EDT Date: Saturday, 8 June 1985 11:38-MDT Message-ID: Sender: Mark Mallett From: Mark Mallett Subject: TOPS20 style parser posting (now on Simtel20) ReSent-From: KPETERSEN@SIMTEL20.ARPA ReSent-To: Info-Cpm@AMSAA.ARPA ReSent-Date: Tue 11 Jun 1985 11:50-MDT I have posted CMD003, edit level 003 of COMND-TOPS20 style parsing for personal computers, to net.sources. It is in 6 parts plus an introduction which is part 0. It is also available via FTP from SIMTEL20 as: Filename Type Bytes CRC Directory MICRO: CMDOSS.CPM.1 ASCII 1889 B172H CMDPF1.C.1 ASCII 19180 0FFDH CMDPF2.C.1 ASCII 9839 C130H CMDPFD.C.1 ASCII 8927 9FFDH CMDPSD.C.1 ASCII 1986 80D1H COMND.C.1 ASCII 21248 47C5H COMND.DOC.1 ASCII 34945 3094H COMND.EDT.1 ASCII 815 882EH COMND.H.1 ASCII 4068 2CBCH COMND.R.1 ASCII 28462 8BDDH COMNDI.H.1 ASCII 1394 419DH CPM.H.1 ASCII 2726 4F6BH DATE.CPM.1 ASCII 4295 485BH MEM.H.1 ASCII 734 1AB4H TEST.C.1 ASCII 11638 40E2H For those who want the whole package and can FTP binary files: COMND003.LBR.1 BINARY 100736 6A5DH Thanks to everybody who responded to my original query. Mark Mallett decvax!sii!mem or ittvax!sii!mem 11-Jun-85 13:23:27-MDT,6449;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 11 Jun 85 13:21:08-MDT Received: from simtel20.arpa by AMSAA.ARPA id a027634; 11 Jun 85 14:24 EDT Date: Thursday, 6 June 1985 05:55-MDT Message-ID: Sender: Donn Seeley From: Donn Seeley Subject: Need help stopping telephone harrassment ReSent-From: KPETERSEN@SIMTEL20.ARPA ReSent-To: Info-Cpm@AMSAA.ARPA ReSent-Date: Tue 11 Jun 1985 12:12-MDT I have a friend (who shall remain nameless, for reasons that will become obvious below) who has been subjected to some very sophisticated telephone harrassment. He doesn't have net access and has asked me to try to use some of the immense combined experience of the net to help him get to the bottom of his problems. My friend has a son of high school age who likes to play with computers. The family has an Apple computer and a modem at home, and the son uses it to dial in to various bboards in the area of his suburban home in California. It seems that one day the son attempted to bluff his way onto a phone phreak bboard. This was a mistake -- the boy was in way over his head, and when the bboard operators learned this, they decided to teach him a lesson. My friend's long distance access code very rapidly propagated around the state and some ridiculous charges began appearing on his monthly bills. At the same time he began receiving harrassing phone calls -- the phone would ring during dinner or in the middle of the night, and when someone answered it, no one would be on the other end. After a couple months of this, my friend asked Pac Tel to trace the harrassing phone calls. The nature of the calls changed; perhaps the son bragged about it to classmates or acquaintances on bboards, but the bad guys heard about it and the callers began to say things. They said that they would vandalize my friend's property and that they would assault his son, and eventually they began making death threats. Pac Tel stalled on the traces; in the end they said that they couldn't release the information that they had gathered because regulations required that at least three of the calls had to originate from the same number, and somehow this was not the case. My friend was puzzled about the rule, but he was even more puzzled about the fact that the calls seemed to come from different numbers... He and his family began to get rather nervous, although the violence remained verbal. My friend decided to do some investigating of his own and called up some of the numbers that appeared on his long distance bill. Many of them turned out to be recordings of various kinds, such as 'dial-a-porn'; a few of them turned out to be homes with teenagers, and the latter readily admitted that they had been given the access code and told to 'get this guy', and to spread the number far and wide. Since it was clear that the original perpetrators could not be traced through the long distance company, my friend changed his access code and managed to convince the company to forgive the bogus charges. Following this move the problems with long distance went away. At about this time the harrassing phone calls stopped too. My friend isn't sure whether this was a result of the bad guys hearing about his investigation through the grapevine, or whether Pac Tel was getting warm, but he was grateful regardless. Unfortunately this wasn't the end of his problem. When he got his phone bill at the end of the month, he discovered that he was being charged for hundreds of dollars worth of bogus toll calls through Pac Tel, all made in his local area code. Apparently all of the many numbers called were recordings, so there was no one on the other end who could be asked about the calls. Pac Tel said that the calls originated from his residential phone, but it was quite clear that no one in the household could possibly be doing it. The family kept logs of where all its members were for periods of weeks at a time, and these showed that the calls were being made when the house was empty, or when the family was eating dinner and so on. Peculiarly, some of the numbers were called as many as 8 times in a single minute, which suggested that the caller was using an auto-dialer (my friend does not own one) and that the calls were being made to accumulate charges rather than to listen to the recordings. On the basis of this evidence Pac Tel traced the house's local loop, but could find no indication that it had been compromised in any way. Pac Tel now steadfastly maintains that there is no other way of making a call appear to originate from the residence's phone. After several months of wrangling, Pac Tel sent its own investigator to look at the case. After one phone call to my friend and three days of 'investigation', Pac Tel's man announced that my friend's son was responsible for all the calls, and that my friend was liable for the thousands of dollars worth of bogus calls that had been made over the previous eight months. My friend, at his wits' end, tried contacting the FBI. They heard him out and told him that because none of the bogus calls at any stage of the case had crossed state lines, they had no jurisdiction. (My friend's heart sank when he realized that that the bad guys must have thought of this in advance...) The FBI suggested that my friend call the PUC. This turned out to be a joke -- my friend couldn't even get past the secretary. My poor friend is now at the stage of hiring a lawyer and preparing for the inevitable... Meanwhile the bogus calls continue, taunting him. My friend and I can use any information you might have on how a stunt like this could be perpetrated -- how can you make calls appear to come from another number? We don't need or want precise details on how to beat the system; we just need enough to convince Pac Tel (or (sigh) a judge) that there is an alternative explanation for the calls... Any help you can give would be deeply appreciated, Donn Seeley University of Utah CS Dept donn@utah-cs.arpa 40 46' 6"N 111 50' 34"W (801) 581-5668 decvax!utah-cs!donn PS -- If you have something you'd prefer to communicate in person, and you'll be attending the Usenix conference, by all means contact me there. 11-Jun-85 23:27:57-MDT,923;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Tue 11 Jun 85 23:26:53-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a004665; 12 Jun 85 0:50 EDT Received: from usenet by TGR.BRL.ARPA id a001842; 12 Jun 85 0:45 EDT From: "Bruce K. Martin" Newsgroups: net.micro,net.micro.cpm Subject: Hard Disk Query Message-ID: <266@ucdavis.UUCP> Date: 11 Jun 85 02:26:48 GMT Xref: seismo net.micro:11362 net.micro.cpm:4578 To: info-cpm@AMSAA.ARPA *** I DID REPLACE THIS LINE WITH MY MESSAGE *** I am looking to upgrade my faithfull Eagle IIe with a harddisk and am having trouble finding the equipment. Can anyone out in netland tell me of an independant company (Eagle made disks are few and far between) that makes an Eagle II compatible system. Something on the order of 10 to 20Mb would be great! Thanks in advance! 12-Jun-85 09:36:11-MDT,1632;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 12 Jun 85 09:33:48-MDT Received: from simtel20.arpa by AMSAA.ARPA id a020565; 12 Jun 85 10:56 EDT Date: Wed 12 Jun 85 08:57:08-MDT From: Rick Conn Subject: ZCPR3 updates To: info-cpm@AMSAA.ARPA MICRO: and MICRO: contain several updates to ZCPR3 files. I have just placed Z3NEWS.204 in Z3NEW and ZCPR3. The other 6 LBR files are in both dirs, and all files in Z3NEW are subject to deletion after a week or so. Z3NEW is for the convenience of quickly identifying updates. Keith will announce the updates presented in the LBR files. I am planning to release a set of updates to ZCPR3 to SIG/M. The archives on SIMTEL20 will receive these updates as SIG/M does. These updates represent the current versions of all ZCPR3 tools which have changed since the initial release. They will serve to bring the archives on SIMTEL20 and SIG/M up to date with Echelon. As the toolset continues to evolve, updates will probably be released periodically in the future. Rather than releasing an update every time a tool changes, updates to tools will be collected and released on a periodic basis. In the meantime, the Echelon newsletter can be used to be kept informed of updates as they occur, and the Z-NODES will be kept current with Echelon while SIMTEL20 will be kept more-or-less current as time and workload permits. SIMTEL20 is currently in a good state, lacking only a few updates. This distribution will bring it up the rest of the way. Rick ------- 12-Jun-85 13:16:20-MDT,848;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Wed 12 Jun 85 13:14:16-MDT Received: from cmu-cs-c.arpa by AMSAA.ARPA id a028075; 12 Jun 85 14:23 EDT Received: ID ; Wed 12 Jun 85 14:23:35-EDT Date: Wed 12 Jun 85 14:23:28-EDT From: Thomas.Finholt@CMU-CS-C.ARPA Subject: Kaypro II upgrades To: info-cpm@AMSAA.ARPA I would like to hear from anyone that has done the 16-bit upgrade for the Kaypro II. I believe the package is made by a company in Texas (ASWP?). They claim that the upgrade will run CP/M-86 and MS-DOS. What are the limitations? How IBM compatible will this upgrade be? Can anyone give me price information? The best I have done so far is $550 - $600. Thanks. Respond here or to: finholt@cmu-cs-c.arpa ...!ucbvax!finholt@cmu-cs-c.arpa ------- 14-Jun-85 22:32:47-MDT,1095;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 14 Jun 85 22:30:42-MDT Received: from ucb-vax.arpa by AMSAA.ARPA id a015006; 15 Jun 85 0:03 EDT Received: from ucbjade.CC.Berkeley.ARPA (ucbjade.ARPA) by UCB-VAX.ARPA (4.24/4.46) id AA20026; Fri, 14 Jun 85 21:00:16 pdt Received: from ucbopal.CC.Berkeley.ARPA (ucbopal.ARPA) by ucbjade.CC.Berkeley.ARPA (4.19/4.35.2) id AA08534; Fri, 14 Jun 85 21:04:31 pdt Received: by ucbopal.CC.Berkeley.ARPA (4.19/4.35.3) id AA01191; Fri, 14 Jun 85 21:03:33 pdt Date: Fri, 14 Jun 85 21:03:33 pdt From: CS Consulting Message-Id: <8506150403.AA01191@ucbopal.CC.Berkeley.ARPA> To: info-cpm@AMSAA.ARPA Subject: Unix/Z80 cross-assember Cc: anamaria%ucbopal.CC@ucb-vax.ARPA, owicki%ucblapis.CC@ucb-vax.ARPA and would like to know if there are any Z80 development systems or cross-assemblers that will run under 4.2 BSD Unix. Bill Wells Please reply to the above addresses directly. Thanks. 14-Jun-85 23:08:20-MDT,962;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Fri 14 Jun 85 23:07:13-MDT Received: from simtel20.arpa by AMSAA.ARPA id a015034; 15 Jun 85 0:39 EDT Date: Fri, 14 Jun 1985 22:39 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Brindle.Wbst@XEROX.ARPA Cc: Info-Cpm@AMSAA.ARPA Subject: TOPS20 style parser posting (now on Simtel20) In-reply-to: Msg of 12 Jun 1985 11:52-MDT from Brindle.Wbst at Xerox.ARPA Would you place COMND003.LBR from MICRO: on your royal oak rcpm system. I do not have access to Simtel. The Tops20 style parser COMND003.LBR is now available from RCPM Royal Oak (313-759-6569) on the B: drive. --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 15-Jun-85 11:56:19-MDT,680;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sat 15 Jun 85 11:54:22-MDT Received: from xerox.arpa by AMSAA.ARPA id a016332; 15 Jun 85 13:28 EDT Received: from Barbera.ms by ArpaGateway.ms ; 15 JUN 85 10:28:36 PDT Date: 15 Jun 85 12:28:29 CDT (Saturday) From: pencin.Dlos@XEROX.ARPA Subject: Re: TOPS20 style parser posting (now on Simtel20) In-reply-to: To: Keith Petersen cc: Brindle.Wbst@XEROX.ARPA, Info-Cpm@AMSAA.ARPA Message-ID: <850615-102836-1414@Xerox> This file is also on THE DALLAS CONNECTION 300/1200/2400 baud (214)238-1016 24 hours. 16-Jun-85 15:33:05-MDT,697;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Sun 16 Jun 85 15:32:41-MDT Received: from brl-tgr.arpa by AMSAA.ARPA id a020339; 16 Jun 85 17:04 EDT Received: from usenet by TGR.BRL.ARPA id a022580; 16 Jun 85 16:59 EDT From: Ted Medin Newsgroups: net.micro.cpm Subject: Re: NULU 1.1 bug reports - et all Message-ID: <962@noscvax.UUCP> Date: 11 Jun 85 16:37:35 GMT To: info-cpm@AMSAA.ARPA Another problem which exists with nulu111. I did an extract (or was it unsqueeze) with a file name like "a?*.*" and got lower case characters in the directory extension. Not using wild cards works correctly. 17-Jun-85 05:52:47-MDT,4911;000000000000 Return-Path: Received: from AMSAA by SIMTEL20.ARPA with TCP; Mon 17 Jun 85 05:50:27-MDT Received: from simtel20.arpa by AMSAA.ARPA id a000677; 17 Jun 85 1:21 EDT Date: Sun, 16 Jun 1985 23:22 MDT Message-ID: Sender: KPETERSEN@SIMTEL20.ARPA From: Keith Petersen To: Info-Cpm@AMSAA.ARPA Subject: Sanyo inverse video Relayed from my RCPM Royal Oak: June 12, 1985 To: All Sanyo 1200/1250 owners From: E. Mark Kothe RE: Sanyo inverse video If you are one of the proud owners of a Sanyo 8-bit machine (probably ALL Sanyo's) I really don't have to tell you that the documentation for these machines leaves a little to be desired. Hopefully this document will help, maybe it is common knowledge? The Sanyo 1200/1250 (maybe others?) has four possibilities for video character display: Standard Inverse video Underlined Overlined These character types may also be combined for other effects (except for inverse and standard) Here is the description on how to use this feature in the Sanyo MBC-1200 series users guide escape code section (incidentally MBC stands for.....ya ready ?... My Business Computer) If you ha