wcs@ho95e.UUCP (10/08/87)
We have a couple of ancient HP-150 PCs lying around (mainly bought as terminals), and I'd like to try using one for DOS. I realize the disk drives are different, but can work around that. - Are file systems the 3.5" disks compatible with the current 3.5" file systems used for laptops? - Is the system BIOS compatible? 90%? etc? - Is the display CGA or MDA compatible, or neither? (hardware-level would be nice, BIOS-level good, DOS-only boring.) - What else should I know? -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
NU070156@NDSUVM1.BITNET (Glen Overby) (10/09/87)
In article <1768@ho95e.ATT.COM>, wcs@ho95e.ATT.COM (Bill.Stewart) says: >- Are file systems the 3.5" disks compatible with the > current 3.5" file systems used for laptops? Not that we have found. It does not appear to be compatable with those on the IBM PS/2. The 5.25" drive works OK if you format the disk on a full PC Clone. >- Is the system BIOS compatible? 90%? etc? No ROM BIOS; only DOS. Lets say "1%" compatable. Generic MSDOS Turbo Pascal runs (use the HP terminal configuration setting), Turbo C runs in line mode (not extensively tested), there is a set up for the 150 in MicroEmacs3.8i, but I couldn't get 3.8i to work on anything but Unix and MSDOS/IBMPC. There is also a MS-Kermit for it. >- Is the display CGA or MDA compatible, or neither? > (hardware-level would be nice, BIOS-level good, DOS-only boring.) Only DOS. It does terminal emulation for DOS the same way as it does to your remote host as a terminal. Its not what you want if you need a full PC Clone, but it is useful if what you need runs on it. The touch-screen is neat! Glen Overby Bitnet: nu070156@ndsuvm1 UUCP: psuvax1!ndsuvm1.bitnet!nu070156 ihnp4!umn-cs!ndsuvax!ncoverby
jack@csccat.UUCP (Jack Hudler) (10/09/87)
In article <1768@ho95e.ATT.COM>, wcs@ho95e.ATT.COM (Bill.Stewart) writes: > We have a couple of ancient HP-150 PCs lying around (mainly bought as > terminals), and I'd like to try using one for DOS. I realize the disk > drives are different, but can work around that. > > - Are file systems the 3.5" disks compatible with the > current 3.5" file systems used for laptops? > - Is the system BIOS compatible? 90%? etc? > - Is the display CGA or MDA compatible, or neither? > (hardware-level would be nice, BIOS-level good, DOS-only boring.) > - What else should I know? > Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs To answer your questions: The disk drives are not compatable.... The 0% compatable with BIOS ladden programs. The display is not like anything on the market.. BUT! it does have some very nice features in the screen department. The line drawing stuff in the firmware is the greatest stuff, I don't know why Microsoft or IBM hasn't taken there lead. You can draw lines with patterns to them and varing thickness also has polygon fill with user definable patterns. Text can be displayed in all sorts of sizes and rotated! The screen firmware buffers stuff to be written out and updates the screen when it gets a slice of time, this to is kinda neat to have the cause screen output doesn't boog down the program. You can alos write to the screen in HPGL <the language of HP's plotters>. The Keyboard is handled differently, It sends back a keycode and Qualifier and the touch screen <if it still works> is handled like a hit from the keyboard. Also you can define touch areas on the screen to act like keys on the keyboard and you can set the up sense when touched or released.. and a bunch of other stuff I can't remember. And get this... It's very fast and the graphics,alpha,keyboard can be accessed through IOCTL channals! It has been >3 years since I worked with one but I still to this day wish I could have all the built-in stuff. One which comes to mind is seperate Alpha and Graphics. Graphics and Alpha can co-exist without destroying the other and either or both can be turned off showing graphics wih alpha, alpha only, graphics only, or nothing at all. Our company was one of the first alpha/beta locations for the 150 and the source for the firmware is 11x14 compressed and took 23 2" binders to contain all of it and that really wasn't all of it! It's and 8088 I think it's running at 6 or 8 Mhz but I don't remember, and 8087 co-processor cannot be installed <little *&^*$#@ on the design team gave all the lines that where needed on the expansion bus except one>. Wow what a mouthfull.. Hope this answered all your questions.. I am sure it's didn't. If you like email me and maybe I can answer any further questions. Jack Hudler Computer Support Corp. ihnp4!killer!csccat!jack -- See above (214)661-8960
stevev@uoregon.UUCP (Steve VanDevender) (10/09/87)
In article <1768@ho95e.ATT.COM> wcs@ho95e.UUCP (46133-Bill.Stewart,2G218,x0705,) writes: >We have a couple of ancient HP-150 PCs lying around (mainly bought as >terminals), and I'd like to try using one for DOS. I realize the disk >drives are different, but can work around that. > >- Are file systems the 3.5" disks compatible with the > current 3.5" file systems used for laptops? The file systems are compatible with other HP drives. They probably aren't compatible with IBM 720K disks. >- Is the system BIOS compatible? 90%? etc? The HP 150 has no IBM PC BIOS emulation whatsoever. The built-in ROMS and the AGIOS provide lots of wonderful features but are in no way compatible with the PC BIOS. I have heard of BIOS emulators for the 150, and if anyone out there knows more I'd love to hear about it. >- Is the display CGA or MDA compatible, or neither? > (hardware-level would be nice, BIOS-level good, DOS-only boring.) Neither. The graphics are nice (and the built-in graphics primitives are quite nifty) but once again incompatible. >- What else should I know? I own a 150 and find it quite adequate for my needs, but I don't need PC compatibility and I have all the software I'm likely to ever use on it, either purchased through HP or obtained from PD sources (although once again, it's hard to find things that don't use the PC BIOS). >-- ># Thanks; ># Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs -- Steve VanDevender uoregon!drizzle!stevev stevev@oregon1.BITNET "Bipedalism--an unrecognized disease affecting over 99% of the population. Symptoms include lack of traffic sense, slow rate of travel, and the classic, easily recognized behavior known as walking."
bruce@ektools.UUCP (Bruce D. Nelson ) (10/11/87)
The diskette format for the original 150's is completely different from the IBM-PC 3.5 format. If you have an HP-150-II, you can get an MS-DOS v3.2 which can read/write v3.2 PC-DOS disks. The HP-150 BIOS is different from the IBM's. However, some well-behaved PC programs run on the 150. I've sucessfully run ARC, PKXARC, TOUCH, SDIR, and a bunch of others. Using the PC-shells available from INTEREX, I've run Norton Utilities and some others. Bruce D. Nelson | UUCP: ...!rutgers!rochester!kodak!ektools!bruce Eastman Kodak Company | Voice: 716-726-7890 901 Elmgrove Road | Company Mail: Dept 420 Technical Support Services Rochester, NY 14650 |
cole@sri-unix.ARPA (Susan E. Cole) (10/12/87)
Since many people seem to be familiar with the HP150, I wonder if someone can tell me where to get a Kermit that runs on it? I am making this request for another person; what we would like to find is a place to purchase a ready-to-go diskette, not a place to download from, since she knows nothing about computers and I know nothing about the HP150 and don't want to try to figure out its built-in communications. I looked at columbia's kermit stuff and didn't see anything promising available on diskette. Thanks for any help. Susan Cole cole@unix.sri.com ....!hplabs!sri-unix!cole
Theodore_Ted_Manos@cup.portal.com (10/17/87)
Susan Cole writes: >> /* Written 11:32 pm Oct 11, 1987 by cole@sri-unix.ARPA in >> uxc.cso.uiuc.edu:cp.sys.ibm.pc */ >> Since many people seem to be familiar with the HP150, I wonder >> if someone can tell me where to get a Kermit that runs on it? >... >> I looked >> at columbia's kermit stuff and didn't see anything promising >> available on diskette. >> >> Susan Cole >> cole@unix.sri.com >> ....!hplabs!sri-unix!cole Dan Crimmins replies: >I have here (somewhere...) a version of kermit labelled "for HP portable." >Whether this is for the 150 specifically, I am not sure. Looking in the >Kermit User's Guide, a list dated 22 July 1986 lists versions specifically >for the HP-150 and HP-110. The HP-150 version was developed by Columbia U. >themselves, so you should be able to get it for $10 from the following address > > Kermit Distribution > Columbia Univ. Center for Computing Activities > 612 West 115th St. > New York, NY 10025 > >Needless to say, I would give them a call or write a letter before ordering. >Hope this is of some help. > >---- > Dan Crimmins crimmins@uiucuxc.cso.uiuc.edu > University of Illinois {ihnp4,pur-ee,convex}! > Computing Services Office - Micro Consulting uiucdcs!uiucuxc!crimmins Included below is an copy of the information contained in the AANETW.HLP file distributed by Columbia. This describes some of the other methods available for obtaining copies of Kermit program files, both from Columbia, and from a few other sites. If you were to download the Kermit files from one of the named sources, you would need to get the following files for the HP-150: MSVHP1.BOO, .BWR, .HLP, .DOC, .INI, and .UPD - current production version or MSTHP1.BOO, .BWR, .HLP, .DOC, .INI, and .UPD - current test version MS-Kermit 2.29 is the current version. You might also want to obtain: AA*.HLP - general Kermit distribution help files MSAAAA.HLP - Help file for MS-DOS base Kermit files MSKERM.DOC - Documentation for MS-Kermit MSR229.UPD - Update information for the current version of MS-Kermit Also, if you don't already have a program to convert .BOO files back into executable code, you will need to get MSBPCB.BAS, and may want MSBPCT.BOO as well (it is faster than MSBPCB.BAS once it has been decoded by same). Hope this will help you. -> Ted Manos tmanos@cup.portal.com Alpha Omega Consulting Group, LTD ucbvax!sun!cup!portal!tmanos 400 Springhill Drive CIS - 71250,2761 Roselle, IL 60172 Source - est321 USA Genie - tmanos Office: 1 (312) 980-7919 Portal - tmanos Mobile: 1 (312) 590-0298 -- and others -- ************************** NON-DISCALIMER ************************************ * My company agrees with my views completely - I hold all of the stock! * ****************************************************************************** AANETW.HLP (7 May 87) Accessing Kermit Files Via Computer Network This file describes how to get Kermit files over computer networks, including BITNET, CCNET (a DECnet network), the Internet (Arpanet and the networks connected to it), plus various dialup accesses including UUCP. You should also read AAFILES.HLP if you need more complete descriptions of the Kermit files themselves. * BITNET from the Columbia University CUVMA System: BITNET is a network of IBM mainframes, mostly at universities, connected with leased phone lines, using IBM RSCS protocols (VAX VMS and Unix systems and other systems that can imitate these protocols are also on BITNET). BITNET covers North America and Europe. Information about joining BITNET may be obtained from EDUCOM Networking Activities, P.O. Box 364, Princeton, NJ (USA) 08540, Phone 609-734-1878. KERMSRV at CUVMA is a file server for the BITNET user community which accepts commands via messages or spool files, and sends the requested KERMIT files over the network. Most spool file formats are accepted including those used by SENDFILE, NOTE, PUNCH, PRINT, CARD DUMP, or DISK DUMP commands. To learn how obtain Kermit files from the Columbia IBM mainframes via BITNET, type the following command to your BITNET host: VM/CMS: TELL KERMSRV AT CUVMA HELP (or SMSG RSCS MSG CUVMA KERMSRV HELP) MVS/TSO/E: TELL KERMSRV AT CUVMA HELP (may be site dependent) VMS JNET: SEN/REM CUVMA KERMSRV HELP UNIX UREP: netexec cuvma msg cuvma kermsrv help The Kermit files available from BITNET may be some days or weeks behind the announcements that appear in Info-Kermit (see below). Here is a brief summary of KERMSRV operation; see the HELP message for greater detail: The following file request commands are accepted: SEND, PUNCH, PRINT, DISK, and CARD. These commands expect a file name or "DIR" or "?" as an operand. The DIR operand accepts an optional file name also. File names may contain * or % wildcard characters, but the filename portion may not consist of those characters only. Note that KERMSRV will always respond with some message; if you get a response please do not resubmit your request. If your request was received as a spool file, error messages are sent in a spool file, also. The NEWS command returns news about latest features and changes in KERMSRV. * BITNET from the University of Toledo VAX/VMS system UOFT02: The Kermit file server KERMSRV is not the same one as the one running at Columbia -- this is a VAX, and CUVMA is an IBM mainframe. The collection is maintained by Brian Nelson, author of PDP-11 Kermit, mail to BRIAN@UOFT02 on BITNET. for instance, from VM/CMS: CP SMSG RSCS MSG UOFT02 KERMSRV DIR CP SMSG RSCS MSG UOFT02 KERMSRV SEND K11*.* (or TELL KERMSRV AT UOFT02 DIR, etc.) from VMS Jnet: $ SEN/REM UOFT02 KERMSRV SEND K11*.* Attempts to see if Kermsrv is 'logged in', e.g. SEN/COM UOFT02 CPQ U KERMSRV or SM RSCS MSG UOFT02 KERMSRV CPQ U KERMSRV will ALWAYS fail. This is a VMS node running JNET and JNET treats server processes in a manner unlike VM does. For all pratical purposes, KERMSRV is always running. If a message is sent to it, and for some reason it's not there, JNET will tell you. Secondly, KERMSRV can ONLY respond to interactive messages, it can not process mail. I see several attempts per day to send it mail. Additional "satellite" BITNET KERMSRV sites may be established in the future to relieve congestion at the major US East Coast hubs. The need is particularly great on the West Coast and in Europe. Volunteers? There is also some possibility of converting from KERMSRV to the more general and powerful LISTSERV facility. * Internet from the Columbia University CU20B System: "Internet" means the Arpanet and any network connected to it using TCP/IP protocols, including parts of CSnet, many campus local networks, etc. Access to the Columbia Internet Kermit distribution is through FTP, the Internet File Transfer Program; consult the FTP manual for your own system in order to learn how to use your FTP program. To get Kermit files via the Internet, use FTP (not TELNET), connect to host CU20B (Internet Host number [128.59.32.128]), login as user ANONYMOUS, password KERMIT, and use the GET or MULTIPLE GET commands to retrieve the desired files from the area KER:, e.g. "GET KER:AAAREAD.ME", "MULTIPLE GET KER:CK*.*". Network users may consult the file KER:AAVNEW.HLP from time to time to see what new versions of Kermit have been installed recently. Sites whose FTP programs do not support the DIRECTORY or MULTIPLE GET commands may GET the file AAFILES.DIR from the desired Kermit area (see below) to obtain an up-to-date directory listing. After logging in anonymously, you may also attempt to set your default path to the desired Kermit directory, KER:, K2:, or K3: (see below), using FTP's CWD or CD command. If you are prompted for a password, provide a null one; if a message advises you to send a password, ignore the message. Since our network software is always in a state of transition, this operation may or may not work. The following discussion assumes it does not work; if it does, you can follow the same instructions, but leave off the prefix KER:, K2:, K3:, etc, from any file specifications. Internet access to CU20B is currently unrestricted, but if sufficiently large numbers of anonymous FTP logins occur regularly during prime (eastern) time hours to interfere with our own user community, some restrictions on anonymous logins will have to be imposed. Those accessing CU20B via network should note the existence of several Kermit file areas: KER: - Microcomputer, PC, workstation Kermit implementations, plus Kermit documentation of a general nature. K2: - Mainframe and minicomputer Kermit implementations. K3: - Esoteric and/or European, Asian, etc, versions. KB: - True binary (executable) files for selected implementations. KE: - "Extra", old, redundant, or "limited-edition" Kermit implementations. KT: - Tools -- cross assemblers and linkers, etc., mostly to run on DEC-20. KO: - Old releases superseded by new ones. KER: corresponds to Tape A, K2: corresponds to tape B, K3: to tape C. These areas are "logical device names", which should be used rather than physical DEC-20 DEVICE:<DIRECTORY> names, which may change from time to time as our systems are rearranged. The logical name KER: includes all the others (K2:, KB:, etc) in its search path in the order listed above, so to obtain a single file you should prefix its name by KER:. When getting either single or multiple files, and your own system is a DEC-20, then it is also sufficient to prefix the file specification by KER:. When getting multiple files from CU20B's FTP server from non-DEC-20 systems, you should first change working directory (CWD or CD) to the area containing the files you want to get, e.g. KER: or K2:. If you don't, then each file will be sent back to you with its fully qualified name which in some cases may be longer than the longest permissible filename on your system, which in turn can cause files whose names differ only in the last few characters to overwrite each other as they arrive. Alphabetic case is insignificant in DEC-20 file names (lowercase is mapped to upper). The dot separating the file name and file type is significant; the name and type are separate fields. File groups may be specified in MULTIPLE GET commands using the following "wildcard" notation: * matches any string of 0 or more characters in the current field % matches any single character in the current position For instance, KER:CK*.* matches all files whose names start with CK. KER:CK*.% matches all files whose names start with CK and whose types are exactly one character long (like KER:CKUCMD.C). The dot in DEC-20 filenames is significant, separating the filename from the filetype. KER:* will NOT match all the files in KER: (as Unix users might expect), but rather, all the files in KER: that have null filetypes. Use *.* to match all files. Each implementation of Kermit has a prefix. All files relating to that implementation have names that start with that prefix. Since the dot is significant in DEC-20 file names, the way to refer to all the files in a specific implementation is "KER:xx*.*", where xx is the prefix. A few cautionary words about DEC-20 logical names: the search path is followed only so long as files are not found that match the given file specification. This can cause some confusion; for instance, the command "DIRECTORY KER:" will only list the files in the primary (Tape A) Kermit directory, because when no file specification is given, "*.*" is assumed, and all files in the primary directory match "*.*", so subsequent directories are not searched. Similarly, "KER:C*.*" will not search subsequent directories if the primary directory contains any files that start with "C". Note that "KER:*.DOC" (whose intention might be to refer to all the Kermit documentation files) would only find .DOC files in the primary Kermit directory. Care has been taken to ensure that files are arranged so that if they are referred to by prefix, they will be found in the KER: search path. For instance, the C-Kermit files, having the prefix "CK" will be found if referred to as "KER:CK*.*", even though they are really in K2:. However, this principle applies only to the principal directories, KER:, K2:, and K3:. It does not apply to KB:, which is used to separate binary files from "printable" files. Therefore, KER:MS*.* will find all of the printable MS-DOS Kermit files, but will not find the .EXE files, which are in KB:, and must be referred to separately as KB:MS*.*. Before you attempt to get binary files from the KB: or KT: directories with FTP, you should know something about the way the DEC-20 stores these files: . Native DEC-10 or DEC-20 programs are stored in 36-bit binary format, and will be transferred correctly to other DEC-10 or -20 systems without doing anything special. They probably can't be transferred to other kinds of systems, except maybe 36-bit Honeywells or Sperrys. . "Foreign" 8-bit binary files are stored 4 8-bit bytes left justified within the 36-bit word. You can get these files from another DEC-10 or -20 without doing anything special, but to get them from some other kind of system, you have to give FTP the command "TYPE L 8" or "TENEX" first. If you are originating your FTP requests from a DEC-20 or TENEX system, no special precautions are necessary regarding file types or name conversion. If you are coming from another kind of system, you will probably find that the files you obtain are stored with names contrary to your system's naming conventions. For instance, if you tell Unix FTP to "mget ck*.*", you may find the files stored in your directory with names like PS:<KERMIT>CKAAAA.HLP.2 when you really want stored with names like ckaaaa.hlp A special program is available to Unix sites for doing the appropriate file name conversions, called xxu.c ("get ker:xxu.c"). The recommended procedure for FTP'ing files to a Unix system is to make a new directory for them, cd to it, then get the files, including ker:xxu.c, then build xxu.c (it should run under any version of Unix), then do "xxu *" to convert the names. See the xxu.c source comments for details. USING KERMIT WITH AN INTERNET TERMINAL ACCESS CONTROLLER (TAC). (Thanks to Edward Haines <haines@BBNCCI.ARPA> for these hints) There are some conditions that must be met to successfully use Kermit on a personal computer through a TAC. Flow Control The buffer size for a terminal port on a TAC is typically about 64 bytes. (The size is a configuration parameter.) Since the default packet size in Kermit is about 96 bytes it is quite likely that buffer overflow will occur. Some possible solutions: 1. Enable flow control in Kermit on the PC and on the TAC. Many PC versions of Kermit implement XON/XOFF flow control. In particular, the new MS-DOS version does for the IBM PC. To enable flow control on the TAC issue the TAC commands @Flow Input Start @Flow Output Start These are usually abbreviated @f i s and @f o s. Note that flow control is not compatible with binary mode (except see note below). 2. Make the packet size on the PC Kermit small enough to not overflow the TAC buffer, e.g. 60 bytes. I had patched the old MS-DOS Kermit to do this. On the new MS-DOS Kermit, there is a command to set the packet size. 3. Increase the buffer size in the TAC. This is not usually practical and won't be considered further. TAC Intercept Character. The default TAC intercept character is the AT-sign. The AT-sign is also required by the Kermit Protocol. Solutions 1. Have the PC Kermit automatically double AT-signs on output. This is probably the best solution in general. This feature is available on some PC implementations of Kermit. It is not yet available on the MS-DOS version. [Ed. - It's available in CP/M-80 Kermit 4.0x.] 2. Change the TAC Intercept character with the command @Intercept <decimal ASCII value> I generally use @I 6 which sets the intercept character to Ctrl-F. 3. Put the TAC into Binary mode. This has the side effect of disabling the Intercept character. It also will allow you to transfer binary files without special encoding. The TAC can be put into Binary mode with the commands @Binary Input Start @Binary Output Start Some host systems allow you to engage the binary mode from the host. DEC-20 Kermit has a command for this. There are several problems with binary mode: Some host systems don't support it. You lose the ability to control the TAC from the PC. You lose the ability to do XON/XOFF flow control. Binary Files It is sometimes desireable to be able to transmit an 8-bit binary file between a host and a PC. The TAC (which implements the DDN Telnet Protocol) normally provides just a 7-bit ASCII path. Solutions 1. Enable binary mode (if possible) as described above. 2. Enable 8th bit prefixing (if available) in both Kermits. (This is usually done by enabling parity.) Notes 1. You will probably get the best throughput for ASCII files by keeping the packet size as large as possible and using flow control. 2. There is not much advantage in increasing the baud rate between the PC and the TAC beyond 1200 baud because of the realatively long turnaround time for the acknowledgement packet. 3. You may have problems when going through satellite hops or multiple gateways due to the occasional very long delays. This may result in Kermit giving up. I have also seen Kermit get into a sort of resonant mode where it sends each packet twice but is otherwise succesful. The resonating packets usually happen when one of the Kermit programs is not capable of flushing its input buffer. See the BYTE article for an explanation of this phenomenon. Long delays can be circumvented to some extent by increasing the timeout interval; many Kermits have commands to allow this. 4. Only the first letter of a TAC command is required. 5. It is possible to set binary mode in only one direction. For example you can set Inbound binary and retain input flow control (XON/XOFF flow is in the opposite direction). You probably don't need outbound (input to the PC) flow control when using the Kermit protocol. (More TAC hints from Dave Swindell <dswindel@BBN-LABS-B.ARPA>): I've found that you have to explicitly set the send-packet length to something less than 64 when uploading data from ANY PC over a TAC. The TAC input buffer just isn't big enough to handle the 90 (or is it 94?) character default send-packet size used by MacKermit. As was mentioned in the digest, you also have to use the TAC commands @ B O S and @ B I S (in that order) to allow the Kermit protocol to function correctly over a TAC. * CCnet: CCnet is a DECnet network of cooperating universities. Kermit files may be accessed using NFT to CU20B::KER:xxx, where xxx is the name of the file or file group you want to get. Some sites (regarded as "secure") may specify /USER:ANONYMOUS, but most sites will have to supply a valid CU20B user ID and password. If your system is on CCnet and you cannot get anonymous NFT access to CU20B, you'll have to ask your system manager to get the files for you. Read the Internet section above about device, directory, and wildcard conventions. * United Kingdom (Information from Alan Phillips, Lancaster University): Though there is a central registry of UK site names known as NRS, it is not automatic and many people have no access to it, so include the actual DTE addresses if you can. Details for mail: JANET network : SYSKERMIT @ UK.AC.LANCS.VAX1 (actual address is 000010404000.FTP.MAIL) PSS network : SYSKERMIT @ 234252400101.000010404000.FTP.MAIL or to the JANET address via the Rutherford gateway BITNET : SYSKERMIT%LANCS.VAX1 @ UK.AC ARPA : SYSKERMIT%LANCS.VAX1 @ CS.UCL.AC.UK We do not support file transfer to BITNET/ARPA - users have to log in as a terminal and use KERMIT. Over PSS and JANET we support ftp using Blue Book protocol: For details pull file 00INFO.TXT from user KERMIT, quoting password KERMIT. FTP address is JANET : 000010404000.FTP PSS : 234252400101.000010404000.FTP" Or people can just mail me and I'll send details. Afraid we have no equivalent of the BITNET KERMSRV server or Arpa anonymous ftp over here. Dial-up ports are available; I'll send details to anyone wanting them. While we're very happy for anyone to ftp from us or log in to us from anywhere, and we'll put anyone on the mailing list, we can't handle letters and phone calls from outside the UK and Eire. Nor can we send files to people who can't ftp them. * Mail: There is a network mailing list for Kermit information; it is available to users of BITNET and the Internet and most networks that are connected to them, inclusing CSnet, Usenet, Mailnet, CCnet, and others. To get on the mailing list, send mail: - From - - To - BITNET KERMIT@CUVMA CCNET Info-Kermit-Request@CU20B Arpa Internet Info-Kermit-Request@CU20B.COLUMBIA.EDU CSNET Info-Kermit-Request%CU20B.COLUMBIA.EDU@CSNET-RELAY Mailnet Info-Kermit-Request%CU20B.COLUMBIA.EDU@MIT-MULTICS Usenet ...!seismo!columbia!cu20b!info-kermit-request DEC Easynet DECWRL::"Info-Kermit-Request@CU20B.COLUMBIA.EDU" UK JANET SYSKERMIT@UK.AC.LANCS.VAX1 If your system won't let you use long names or names with dashes in mail addresses, then just substitute "KERMIT" for "Info-Kermit-Request". * Dialup: Several publicly accessible dialup Kermit collections are available. 1. Digital Equipment Corporation, Marlboro, MA. Dial 617-467-7437 or -1120. It's a DEC-20. To login, type "LOGIN LCG.KERMIT KERMIT" The Kermit files are in the area KERMIT:, e.g. KERMIT:AAAREAD.ME. Just type "kermit" to run the Kermit program. NOTE: THIS SERVICE ENDS JUNE 30, 1987. 2. The University of Toledo allows limited dialup access to its UOFT02 VAX/VMS system: (419) 537-4411 Service class VX785A User: KERMIT Password: KERMIT Source and hex files are in KER:, binaries are in KERBIN: 3. Oklahoma State University: UUCP and Kermit access to the complete Kermit distribution is available from the Department of Computing and Information Sciences, Oklahoma State University, Stillwater, Oklahoma. The procedures are somewhat complicated, and are described in a separate file, AANOKS.DOC. [End of AANETW.HLP] . The resonan ar
hoff@hp-sdd.HP.COM (Tom Hoff) (10/19/87)
In article <350NU070156@NDSUVM1> NU070156@NDSUVM1.BITNET (Glen Overby) writes: > >>- Is the display CGA or MDA compatible, or neither? >> (hardware-level would be nice, BIOS-level good, DOS-only boring.) >Only DOS. It does terminal emulation for DOS the same way as it does Not true (I think). There is a piece of software availiable which improves the compatability of the HP150. It is called PC.COM and is availiable on Compuserve in the HP sig. What it does (among other things) is emulate the BIOS calls of the IBM PC. Another emulater that is availiable is DC.COM (Emulates IBM PC datacomm calls) and INT16.COM (emulates IBM PC keyboard interupts). Last time I checked, these were all on Compuserve. Please don't regard this as gospel, it's been quite a while since I've used a 150 and this all comes from semi-volatile memory. --Tom -- Tom Hoff (...!hplabs!hp-sdd!hoff) "Dammit Jim, I'm a programmer not a spokesman!"