Info-IBMPC@C.ISI.EDU.UUCP (02/11/87)
Info-IBMPC Digest Tuesday, February 10, 1987 Volume 6 : Issue 8
This Week's Editor: Eliot Moore <Elmo@C.ISI.EDU>
Today's Topics:
New Info-Modems Mailing List
UPDATE.C Revision
Inexpensive Expanded Memory (EMS)
PKX34A20 Archiver Bug
THRASHER.ARC - Program Determines Optimum Setting of BUFFERS
PC-Write Version 2.72 Now Available from SIMTEL20
W-4 Tax Withholding Form Calculator Available from SIMTEL20
Minix Mailing List (2 Msgs)
123 Pgraph Problem
DOS 4.0 vs. 5.0 vs. 286-DOS
Fix to PKARC Bug
Ruggedized AT (3 Msgs)
LA-50 Printer
Saving Turbo Pascal Programs
Absolute Pointer Addresses in MSC
Another Archiver Problem
1987 Academic Microcomputer Conference
360k Floppy Disk Drives on PC/AT
Queueing Simulation Software
MS-DOS on PRO-350
WordPerfect + TOPS + AppleTalk + LaserWriter!
COM3 Driver (2 Msgs)
Major Bug in All versions of MS-DOS
Today's Queries:
Tektronix 40XX Emulation Software and Display Adapter
NEC V30 in Compaq Deskpro
Telink and Ymodem Batch Transfer Protocols
9 Track Tape Drives
Public Domain vi
Timing Code
Problems with Mace Utilities
YACC
----------------------------------------------------------------------
Date: Fri, 6 Feb 1987 23:43 MST
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To: INFO-HZ100@RADC-TOPS20.ARPA, INFO-IBMPC@C.ISI.EDU
Subject: New Info-Modems Mailing List
Announcing a new Internet mailing list INFO-MODEMS@SIMTEL20.ARPA, a
discussion group of special interest to modem users. Info-Modems is
gatewayed to/from Uucp's "comp.dcom.modems".
The mail archives on SIMTEL20 for this list are:
<ARCHIVES.MODEMS>MODEMS-ARCHIV.TXT for the current messages
<ARCHIVES.MODEMS>MODEMS.ARCHIV.ymmdd for the older messages
The files are available via ANONYMOUS FTP for those with TCP/IP access
to the Internet.
Submissions to the group should be addressed to Info-MODEMS@SIMTEL20.ARPA
and administrative requests to Info-MODEMS-Request@SIMTEL20.ARPA.
--Keith Petersen <Info-Modems-Request@SIMTEL20.ARPA>
------------------------------
Subject: UPDATE.C Revision
Date: Sat, 07 Feb 87 20:55:43 EST
From: James R. Van Zandt <jrv@mitre-bedford.ARPA>
Version 2.00 of UPDATE.C has been added to the library. UPDATE copies
new or updated files from one directory to another. It is intended to
help unload a ramdisk before powering down.
JCM@ORNL-MSR.ARPA (James A. Mullens) fixed some bugs and made the
following revisions: reliable updating of system and hidden files,
print useage message if no arguments were specified on the command line.
In addition, this version will: Optionally copy only updated files
(where a file of the same name already exists in the destination
directory), accept a generic file name and move only matching files,
and create the destination subdirectory if it doesn't exist. It also
has an option to recursively visit subdirectories of the source
directory and move files into corresponding subdirectories of the
destination, creating the subdirectories if needed. This option can be
used to copy an entire directory subtree.
[UPDATE.C has been "updated" in the INFO-IBMPC Lending library -wab]
------------------------------
Date: Sat, 7 Feb 87 22:21 CST
From: Brick Verser <BAV@KSUVM>
Subject: Inexpensive Expanded Memory (EMS)
To: <INFO-IBMPC@C.ISI.EDU>
cc: <NESCC@NERVM>
In INFO-IBMPC Vol. 6 No. 6, Scott Crumpton asks for experience with
inexpensive EMS boards. While it certainly isn't the right solution for
everybody, an alternative to buying hardware is to run one of the
software EMS simulators. If performance isn't a major concern, and
provided you have some extra disk space or AT-style extended memory, the
software simulators provide a very cheap way to run EMS applications.
One such product is V-EMM (Virtual Expanded Memory Manager, $89.95)
from Fort's Software (913-537-2897). VEMM can convert AT-style expanded
memory into much more useful extended memory, and it can also page to a
hard disk if no expanded memory is available. The obvious shortcoming
of the simulators is that they perform considerably more poorly than
real EMS memory. A review of several EMS simulators is supposed to
appear in issue 6 of PC magazine.
--Brick
------------------------------
Sender: KPETERSEN@SIMTEL20.ARPA
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To: davidsen%kbsvax.tcpip@GE-CRD.ARPA
Cc: Info-IBMPC@C.ISI.EDU
Subject: PKX34A20 Archiver Bug
In-reply-to: Msg of 6 Feb 1987 12:19-MST from davidsen%kbsvax.tcpip at ge-crd.arpa
From the author of PKX34A20... (not me).
--cut-here--DISSQASH.PAT--cut-here
By default, PKARC 2.0 will "squash" a file if this compression
technique would appear to be optimal for that file. While I
personally do not think it is desirable to change this, this patch is
presented at the request of others who disagree.
However, PLEASE DO NOT distribute PKARC 2.0 if it has been patched as
shown in this document. Not only can this create problems for
recipients of the program that are not aware that the program has
been patched, but it is also in strict violation of the license
agreement in PKARC to distribute the program in modified form.
PKWARE INCORPORATED RESERVES THE RIGHT TO FIND ANYONE WHO DISTRIBUTES
PKARC IN MODIFIED FORM WITHOUT EXPRESS WRITTEN CONSENT FROM PKWARE
INCORPORATED TO BE IN VIOLATION OF THE SOFTWARE LICENSE AGREEMENT AND
LIABLE FOR DAMAGES.
Using DEBUG, change the byte at offset F25 hex in the file PKARC.COM,
version 2.0, dated 12-15-86. The value in the distribution copy is
75 hex.
Changing this value will yield the results shown:
Byte at F25 Program Behavior
------------ ----------------
75 This is the 'normal' value. Squashing will be
performed by default, when it is optimal.
74 Reverses the meaning of the "/oc" flag. By default
squashing will NOT be performed. Specifying "/oc"
on the command line will ENABLE squashing when it
is optimal.
EB Permanently disables squashing. Squashing will
never be performed, regardless if the "/oc" flag is
specified or not.
WARNING: Changing the value of this byte to any other value will cause
unpredicatble program operation.
The following example session with debug will change the value to 74.
Enter
debug pkarc.com<CR>
where <CR> means the enter key. Debug will display a "-" prompt. Then enter
ef25<CR>.
Debug will display something like "xxxx:0F25 75.". The xxxx value will
vary from computer to computer. Debug should display the number 75 as
above. If this value is not 75, then you do not have PKARC 2.0 and
should not continue. Enter
74<CR>
followed by
w<CR>
and then
q<CR>.
The result should appear similar to:
A>debug pkarc.com
-ef25
xxxx:0F25 75.74
-w
Writing 4430 bytes
-q
A>
-Phil Katz 1/14/87
------------------------------
Date: Sun, 8 Feb 1987 07:47 MST
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To: INFO-HZ100@RADC-TOPS20.ARPA, INFO-IBMPC@C.ISI.EDU
Subject: THRASHER.ARC - Program Determines Optimum Setting of BUFFERS
If you've ever wondered how to determine the optimum setting of the
BUFFERS=xx in your CONFIG.SYS, you'll want to try a new program just
uploaded to SIMTEL20...
Filename Type Bytes CRC
Directory PD:<MSDOS.DISK-UTIL>
THRASHER.ARC.1 BINARY 43136 0F92H
This program and its files are placed on the A: drive on a disk with a
system on it. It automatically reboots itself, changing the
BUFFERS=xx line in CONFIG.SYS each time until it reaches the maximum
you specify. As it goes along, it adds information to a report file
that tells you how long it takes to write a 1000 record file and read
it in several ways (random access, etc.). The difference when
changing the BUFFERS size by even one are astounding. The program can
be told to test any drive, thus making it possible to check
performance differences for floppies and hard disks. The optimum
BUFFERS=xx will usually be different for floppies than for hard disks.
When you decide to run this program be prepared to go eat dinner or
watch TV. It takes quite a long time to run.
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie Mail: W8SDZ
------------------------------
Date: Sun, 8 Feb 1987 07:55 MST
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To: INFO-HZ100@RADC-TOPS20.ARPA, INFO-IBMPC@C.ISI.EDU
Subject: PC-Write Version 2.72 Now Available from SIMTEL20
The latest version (2.72) of PC-Write, the popular sharware text
editor/word processor/spelling checker is now available from SIMTEL20
as:
Filename Type Bytes CRC
Directory PD:<MSDOS.TEXT-EDITOR>
PCWR272A.ARC.1 BINARY 268416 91E1H
PCWR272B.ARC.1 BINARY 238592 ACB9H
Yes, almost two diskettes worth! You need both ARCs to have the
complete package.
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie Mail: W8SDZ
------------------------------
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
To: INFO-HZ100@RADC-TOPS20.ARPA, INFO-IBMPC@C.ISI.EDU
Subject: W-4 Tax Withholding Form Calculator Available from SIMTEL20
The 1987 version of the W-4 tax withholding form is said to be very
complex and confusing. A new program, available from SIMTEL20, may
help make things easier.
Filename Type Bytes CRC
Directory PD:<MSDOS.CALCULATOR>
W-4.ARC.1 BINARY 18816 E696H
It's a BASIC program that asks questions and when you're done
calculates your withholding exemptions for the W-4 form.
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {bellcore,decwrl,harvard,lll-crg,ucbvax,uw-beaver}!simtel20.arpa!w8sdz
GEnie Mail: W8SDZ
------------------------------
Date: Sat, 7 Feb 87 21:04:44 MET
From: Andy Tanenbaum <mcvax!cs.vu.nl!ast@seismo.CSS.GOV>
To: Billy <BRACKENRIDGE@c.isi.edu>
Subject: Minix Mailing List
ReSent-Date: 8 Feb 1987 15:18:52 PST
ReSent-From: Billy <BRACKENRIDGE@C.ISI.EDU>
ReSent-To: info-ibmpc@C.ISI.EDU
I live entirely in the USENET world. I have no idea about how the internet
etc organizes its news groups. Isn't there any way to gateway things between
USENET groups and internet groups? There is no mailing list as such, just
a newsgroup. Projecting the last USENET arbitron ratings out to February,
I would estimate the readership of the comp.os.minix group at over 7000 and
growing fast, so a news group makes more sense than a mailing list anyway.
You probably know more than I do about how USENET groups are gatewayed to
the internet etc. I know that several groups are gatewayed, so it must be
possible. If you don't know about these things, you might ask Gene Spafford
spaf@gatech.edu) who is one of the news administrators. Brian Reid
(redi@decwrl.dec.com) is another.
Let me know what you find out.
Andy Tanenbaum
------------------------------
Date: Sun, 08 Feb 87 11:34:23 EST
From: Scott Campbell <SCOTT%UTORONTO.bitnet@wiscvm.wisc.edu>
Subject: Minix Mailing List
To: BRACKENRIDGE@C.ISI.EDU
cc: Erone Quek <QUEKE@QUCDN>
ReSent-Date: 8 Feb 1987 15:18:53 PST
ReSent-From: Billy <BRACKENRIDGE@C.ISI.EDU>
ReSent-To: info-ibmpc@C.ISI.EDU
I have set up a bitnet mailing list for people interested in the minix
operating system that hopefully will be gatewayed to/from the comp.os.minix
USENET newsgroup... I got a note from Andy Tanenbaum mentioning that you
were interested in something similar. Do you have a mailing list? If so,
is it gatewayed to the newsgroup? and also, would you be interested in merging
the two lists?
scott
scott@utoronto.bitnet
------------------------------
Date: Mon, 9 Feb 87 08:58:31 EST
From: jpp@ORNL-MSR.ARPA (J. L. Patton)
To: info-ibmpc@usc-isib
Subject: 123 Pgraph Problem
A manager in our department came to me with an interesting problem
with 1-2-3 Release 2.01 and Print Graph. He was trying to construct a
bar chart with 5 legends. Everything looked good when previewed with
1-2-3 but when the picture was saved then viewed or plotted with
Pgraph only two and a half of the legends were visible or plotted. I
experimented with a fewer number of legends only to find a similar
truncation problem. A quick call to Lotus revealed that it was a
known problem with a driver and unofficially will be corrected in the
next release. However, the following guidelines were given for
reference as a maximum number of characters for legends:
Line & XY Bar & Stacked
# of legends Total chars # of legends Total chars
1 19 1 19
2 38 2 38
3 36 3 33
4 30 4 27
5 24 5 21
6 18 6 15
Hope this saves someone some frustration!
------------------------------
Date: Mon, 9 Feb 87 08:15:00 EST
From: John Owens <john@xanth.cs.odu.edu>
To: BRACKENRIDGE@C.ISI.EDU
Subject: DOS 4.0 vs. 5.0 vs. 286-DOS
Cc: info-ibmpc@C.ISI.EDU
MS-DOS 4.0 was released last fall to OEMs, but most American OEMs followed
IBM's lead in waiting for what was then to be called MS-DOS 5.0, but will
now be called 286-DOS. (IBM will call it Advanced DOS.) Apparently
several European and British OEMs are using 4.0.
And yes, 4.0 does provide multitasking for any 8086-family processor.
John Owens Old Dominion University - Norfolk, Virginia, USA
john@ODU.EDU old arpa: john%odu.edu@RELAY.CS.NET
+1 804 440 3915 old uucp: {seismo,decuac,cbosgd,uvacs}!xanth!john
------------------------------
Date: Sun, 8 Feb 87 22:50:25 EST
From: johnl@ima.ISC.COM (John R. Levine)
To: info-ibmpc@usc-isib.arpa
Subject: Fix to PKARC Bug
Reply-To: ima!johnl@harvard.HARVARD.EDU (John R. Levine)
The following message from the author of PKARC probably addresses the
PKARC bug described in issue 7 of INFO-IBMPC. It certainly works for
me.
It is true that PKARC will produce archives that ARC cannot unpack, but
the PKARC manual explains that if you care about that, there's a switch
to produce backward-compatible archives. I have found that PKARC is
uniformly better than ARC on the PC. ARC, being written in C, has the
advantage that it can be ported to other machines than the 808X series.
I'd be interested to hear if anybody has tried to port it to a big-
endian machine such as the 68000 or the RT PC.
John Levine
--- following message was scarfed from Compuserve ---
Using PKARC 2.0 with a DOS environment larger than 236 bytes may cause
PKARC to abort with an "Insufficient Memory" error. This problem
can be fixed as follows.
Using debug, change the byte at offset 417D hex in the file PKARC.COM,
version 2.0, dated 12-15-86. The value in the distribution copy is 8.
Changing this value will yield the results shown:
Byte at 417D Maximum environment size
------------ ------------------------
8 236 bytes
7 492 bytes
6 748 bytes
5 1004 bytes
4 1260 bytes
A value of 6 should be sufficient for most situations. Using a value
less than 4 may cause unpredictable program operation and is therefore
NOT recommended.
The following example session with debug will change the value to 6:
Enter
debug pkarc.com<CR>
where <CR> means the enter key. Debug will display a "-" prompt. Then enter
e417d<CR>.
Debug will display something like "xxxx:417d 08.". The xxxx value will
vary from computer to computer. Debug should display the number 08 as
above. If this value is not 08, then you do not have PKARC 2.0 and
should not continue. This patch is only necessary for PKARC 2.0.
Enter
6<CR>
followed by
w<CR>
and then
q<CR>.
The result should appear similar to:
A>debug pkarc.com
-e417d
xxxx:417d 08.6
-w
-q
A>
-Phil Katz 12/29/86
--
John R. Levine, Javelin Software Corp., Cambridge MA +1 617 494 1400
{ ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something
Where is Richard Nixon now that we need him?
---
John R. Levine, Javelin Software Corp., Cambridge MA +1 617 494 1400
{ ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something
Where is Richard Nixon now that we need him?
------------------------------
From: cds@atelabs.UUCP (David Shanks)
Subject: Ruggedized AT
Date: 9 Feb 87 17:13:43 GMT
Organization: AT&E Laboratories, Beaverton, OR
IBM makes a ruggedized version of their AT. It comes in either a floor
mount version or a rack mount version. The floor version is called the "IBM
7531 Industrial Computer" and the rack version is the "IBM 7532 Industrial
Computer." Price for either was ~$6000 when we were looking at them a year
ago. IBM also has industrial displays to go with these computers. I
can't tell you much more about them because we decided to use a multibus
box for our project. You can contact Kierulff Electronics in Kent, WA for
more info. Their phone number is (206) 575-4420.
I-Bus systems in San Diego also makes industrial PC's. They didn't have an
AT clone when we were looking, but who knows what they have now. Their
phone number is (800) 382-4229.
These were the only ruggedized PC's that we found. I hope one of them meets
your needs.
--
Dave Shanks ..!tektronix!tessi!atelabs!cds
AT&E Laboratories cds@atelabs.UUCP
1400 NW Compton Suite 300 (503) 690-2000
Beaverton, OR 97006
------------------------------
Date: Sun, 8 Feb 87 21:39 CST
From: Wilkinson@HI-MULTICS.ARPA
Subject: Ruggedized AT
To: info-ibmpc@C.ISI.EDU
GE makes a ruggedized AT called a CIMSTAR which is a very impressive
machine for harsh environments. Contact your local GE-Fenuk sales rep
for more info.
Richard {Wilkinson@HI-MULTICS.ARPA}
------------------------------
Date: Tue, 10 Feb 87 07:18:55 cst
From: mlw@ncsc.ARPA (Williams)
To: info-ibmpc@c.isi.edu
Subject: Ruggedized AT
Another source of a ruggedized AT is CyberResearch, Inc.
5 Science Park Center
P.O.Box 9565
New Haven, CT 06536
They have rackmount and floor-standing ATs, ruggedized displays, and
ruggedized printers. All the stuff can be rackmounted if desired.
Not too cheap, but interesting anyway. The folks have a WATS number
"For Applications Assistance or Ordering: Call The CyberResearch Toll
Free Hot Line 1-800-341-2525." Sorry, but I have never dealt with
these folks, other than to receive and dig through their catalog, so
I can't comment on their corporate performance.
Mark L. Williams
(mlw@ncsc.arpa)
------------------------------
Date: 9 Feb 87 13:25:00 EST
From: "ANTHONY CATONE" <catone@wharton-10>
Subject: LA-50 Printer
To: "info-ibmpc" <info-ibmpc@c.isi.edu>
Reply-To: "ANTHONY CATONE" <catone@wharton-10>
>
>Has anyone had any luck connecting a DEC LA-50 to
>the serial port of a PC/XT/AT??? I can have the printer
>echo things I type on the screen via procomm. but I cant
>get DOS to recongize the printer.
> thanks
> nick
>
Since the LA-50 is a serial device, you must explicitly inform DOS that you
wish to use it as a printer. The command "mode lpt1:=com1:" should do the
trick. You will also need to initialize the baud rate, etc. The command
"mode com1:4800,n,8,1" will set the serial port to 4800 baud, no parity, 8
data bits and one stop bit, which, if I remember correctly from my Rainbow
days, are the LA-50 defaults (although you need to check your dip switches to
be sure). Since I presume you wish to use the printer for word processing,
just one more small hint: the LA-50 is actually a brain damaged version of the
C. Itoh 8510, with DEC's much inferior customized ROM. In particular, the
LA-50 ROM doesn't correctly account for half line feeds; this can create
problems with super- and sub-scripting, as a form feed will ofttimes not
correctly set the next page to its beginning. The solution is to tell your
software to use actual line feeds instead of form feeds.
- Tony
catone@wharton.upenn.edu
catone@dsl.cis.upenn.edu
------------------------------
Date: 9 Feb 87 13:26:00 EST
From: "ANTHONY CATONE" <catone@wharton-10>
Subject: Saving Turbo Pascal Programs
To: "info-ibmpc" <info-ibmpc@c.isi.edu>
Reply-To: "ANTHONY CATONE" <catone@wharton-10>
>From: Jim Anderson <bilbo.jta@LOCUS.UCLA.EDU>
>Subject: Saving Turbo Pascal Programs
>
>One known source of problems with Turbo "COM" files involves
>constants. Constants in Turbo are really more like initialized
>variables, and they can be assigned within the program.
>
A quick test, using Turbo 3.01A, shows that this assertion is incorrect. Only
typed constants reflect this behavior, for as the manual states, "a typed
constant is actually a variable with a constant value." Regular constants
generate a syntax error if assignment within a program is attempted. The
author, however, is correct in that, despite the obvious intent of the typed
constant construct, the Turbo compiler does nothing to ensure that typed
constants' values remain constant, and will not flag assignments to typed
constants as illegal.
In the same issue:
>From: Omar Wing <ELENG@CS.COLUMBIA.EDU>
>Subject: Saving Turbo Pascal Programs
>
>Now when the program is executed from within Turbo Pascal, all the data
>memory space (where the array and other variables get stored) is
>automatically initialized to 0.
This also is incorrect. Data memory space is never automatically initialized
to zero in Turbo Pascal. The built in procedure FillChar is designed to be
used if variables must be initialized to zero's or blanks (useful in Turbo
Database Toolbox for insuring correct matches of key strings, and discussed in
that manual).
- Tony
catone@wharton.upenn.edu
catone@dsl.cis.upenn.edu
------------------------------
Date: Tue, 10 Feb 87 07:57:08 cst
From: mlw@ncsc.ARPA (Williams)
To: info-ibmpc@c.isi.edu
Subject: Absolute Pointer Addresses in MSC
Jonathan Brandon inquired about retrieving a value from an absolute
location under Microsoft C. He needs to read the address at segment
0, offset 0x42. The following advice is just that: I haven't tried
this stuff out yet, but I believe it to be correct.
The first requirement to obtain the address is to set a pointer to the
absolute address. The problem may be that the default situation under
MSC is the "small" memory model. In this case, all pointers are 16-bit
values; actually, only offsets into a standard segment that the programmer
has no direct control over. One solution is to declare a far pointer,
thereby establishing a segment/offset combination that can be initialized
to the desired value. The only thing you may still need to watch out for
is the order of the high and low significance bytes in the address.
Once the referencing pointer problem is addressed, the nature of the
address being read must be considered. If a vector table of offsets starts
at 0x42, then the original far pointer can be pointing to an array of
char *, for instance. On the other hand, if the vector table includes
segments and arrays, the far pointer must point to an array of far pointers.
The method above utilizes the small memory model with specific mixed
pointers. This approach, if applicable, will produce the fastest-running
code. On the other hand, if the program needs some other memory model,
the standard pointer size may be affected anyway. For detailed
information, check chapter 8, "Working with Memory Models," in the MSC
User's Guide.
Mark L. Williams
(mlw@ncsc.arpa)
P.S. Some libraries (like the C Utility Libary, among others) provide
special functions to help you access specific memory locations. If you
have a general-purpose MS-DOS function library, it may contain a function
you can use.
------------------------------
Date: 10 Feb 87 15:44:00 EST
From: "DYMOND, KEN" <dymond@icst-ecf>
Subject: Another Archiver Problem
To: "info-ibmpc" <info-ibmpc@c.isi.edu>
cc: dymond
Reply-To: "DYMOND, KEN" <dymond@icst-ecf>
Bill Davidsen's message in Info-IBMPC Vol. 6 Issue 7 about the bug in
the PKX34A20 Archiver ("program aborts with 'not enough memory to run
program'") reminded me of a similar problem with ARC51 from SIMTEL20.
Attempting to run ARC51 on a vanilla IBM AT (512 KBytes) or a vanilla
XT (640 KBytes) produced a similar message ("program too big to fit
in memory").
Can anyone offer any help on why this is happening ? As far as I know,
there were no environmental variables to set in ARC51 as there were in
the PKX Archiver.
Thanks,
Ken Dymond
dymond@icst-ecf
dymond@icst-se
------
------------------------------
Date: Fri, 30 Jan 1987 07:17 EDT
From: Jim Griffin <IJDG400@INDYCMS>
Subject: 1987 Academic Microcomputer Conference
To: Info-ibmpc digest <INFO-IBMPC@C.ISI.EDU>
The 1987 Academic Microcomputer conference will be held in
Indianapolis on April 20-22, 1987. Registration fee is $75 and
includes a reception the evening of April 20, luncheon and dinner on
April 21, luncheon on April 22, coffee and refreshments during the
conference and a copy of the proceedings.
To obtain a registration packet, send a US Postal address to:
IDTZ400@INDYCMS.BITNET
or
Academic Microcomputer Conference
799 W Michigan - ET 1023
Indianapolis, IN 46202
(317)-274-0710
------------------------------
From: unirot!tom@rutgers.edu
Date: 30 Jan 87 16:30:26 GMT
To: mod-computers-ibm-pc@rutgers.edu
Subject: 360k Floppy Disk Drives on PC/AT
To use PC or PC/XT type 360k floppy disk drives in an AT type
machine just tape over pin 34 on the edge card on the drive.
This will allow it to work.
Drives tested so far:
IBM PC FULL HEIGHT DRIVES.
Qume
TEAC
Olivetti (PC-6300 drives)
Chinon
Fujitsu
JVC
Maple
------------------------------
Date: 9 Feb 87 10:07:52 PST (Monday)
From: Wilson.ES@Xerox.COM
Subject: Queueing Simulation Software
To: Kevin Sullivan <kjs%tufts.csnet@RELAY.CS.NET>
cc: Info-IBMPC Digest <Info-IBMPC@C.ISI.EDU>
The market leader (according to them) in Simulation Software (with 60%
share, according to them) is 'SLAM' from Pritsker & Associates, which
runs on quite a few types of computers including the IBM PC. Software
costs ~$1200 for PC, which has a little less capacity than, say, uVax
Call 'em at (800) 428-7636 and get what you can. I can lend you a copy
of their text ($35) through a friend, prue@fji.isi.edu. This book gives
a real good feel as to how their software works and what it does. Call
me at 333-6495 if you'd care for some personal opinions. (I will be
tough to catch this week.)
Rick
------------------------------
Date: Mon, 9 Feb 87 09:57:20 est
From: harvey@nems.ARPA (Harvey)
To: pa_fastdraft%vaxe.coe.northeastern.edu@relay.cs.net
Subject: MS-DOS on PRO-350
I went to a product demonstration by DEC about 18 months ago
for a board for the PRO-350 that allowed the PRO-350 to use MS-DOS
software. The board was called MS-BRIDGE and I think it was manufac-
tured by a company called BRIDGE. Unfortunately, I have misplaced the
propaganda sheets on the board. This is the only product that I have
seen that allows the PRO-350 to use MS-DOS software.
I hope this helps.
Betty Harvey
------------------------------
Date: Wed, 11 Feb 87 01:03:34 EST
From: matthews@tcgould.tn.cornell.edu (David Matthews)
Subject: WordPerfect + TOPS + AppleTalk + LaserWriter!
Summary: It works! Here's how:
Organization: Dept. Plant Pathology, Cornell University, Ithaca NY
Apparently-To: info-ibmpc@c.isi.edu
Wordperfect and the Laserwriter
WordPerfect Corporation's announcement that WordPerfect 4.2 would support
the Apple LaserWriter made me rush right out and get an update. When it
arrived, I was disappointed to find that the 4.2 update pages contained only
about two paragraphs regarding the LaserWriter support. Since then, setting up
the PC half of a small Appletalk network with one Mac Plus, one LaserWriter+
and one IBM/PC has been interesting. Having recently completed (?) this task,
I offer the following notes. The system under discussion was set up in the
Department of Plant Pathology at Cornell University. I have no affiliation
with WordPerfect Corporation or Centram Systems West (makers of TOPS and TOPS
PRINT) except as a satisfied customer.
First a word about interfaces. WordPerfect Corporation presently supports
only the serial interface. The telephone support people at WP Corp. seem to
know little or nothing about the alternative: TOPS. If you are using your
Laserwriter with MS/DOS machines only, the serial interface is simpler to deal
with and has official support. If the LaserWriter is shared with one or more
Macs, the situation becomes more complicated. Since the Mac can only use the
Appletalk interface, a serial interface to the PC would mean switching the
printer between serial and Appletalk input. This is even more undesirable than
it sounds since the switching involves software as well as hardware. The file
INITLWRT.PS, part of the WP 4.2 package, when sent from the PC to the
LaserWriter, enables hardware handshaking between the two devices. This change
is made in the persistent memory of the LaserWriter and lasts until it is
reversed by other software or until the printer ROM is replaced. Turning the
printer off and on won't do it. Before you send INITLWRT.PS to your printer,
be sure you have its alter ego, XONXOFF.PS. This file returns the Laserwriter
to its original mode of communication. This is essential if you are ever again
to address the printer from a Mac. Either of these files may be sent to the
LaserWriter with the DOS copy command (e.g.: copy a:initlwrt.ps com1).
The alternative to all of this is to use TOPS and TOPS PRINT. TOPS is a
network adapter board (and software) for the PC which enables the PC to be
connected as a node of an Appletalk network. In addition, it will translate
output designed for an Epson FX-80 into Postscript before sending it on to an
Appletalk connected LaserWriter. (This translation is not needed with WP.)
The TOPS PRINT program adds the further refinement of intercepting output to
LPT1 from any application and rerouting it to the LaserWriter through
Appletalk. When Wordperfect 4.2 is used with this system, no switching of
the printer is needed, and INITLWRT.PS is not used. There is a change which
must be made to one WordPerfect file. Releases of WP 4.2 prior to 12-18-86
include a file called LASERWRT.PS; in more recent releases, it's called
PSCRIPT.PS. These are both versions of a Postscript program called
"PtrEmulate". As distributed, these files have a <ctrl>D character at the
beginning and/or end of the file. These <ctrl>D characters must be deleted
if present in order for jobs to pass through the TOPS/Appletalk system. This
is the only modification needed for the Appletalk interface. WordPerfect
should be set up to use one of the LaserWriter printer definitions and route
print output to LPT1.
The PtrEmulate program enables the LaserWriter to recognize and respond to
low ascii control characters just like any other printer. Regardless of
interface, this file is sent as a prolog to each job printed from WordPerfect
using one of the LaserWriter printer definitions. When any of the LaserWriter
printer definitions is installed from the Printer 1 diskette to a program
diskette, the file containing PtrEmulate is automatically copied also. (In
some copies released after the PtrEmulate file was renamed from LASERWRT.PS
to PSCRIPT.PS, the printer selection routine was not changed accordingly.
Hence, a file not found error occurs when the program tries to copy LASERWRT.PS
to the program disk. To get around this, rename PSCRIPT.PS to LASERWRT.PS on
the Printer 1 diskette before you begin installing printer definitions. After
the installation has completed successfully, go to the working diskette and
re-rename LASERWRT.PS to PSCRIPT.PS.) With PtrEmulate resident in the
LaserWriter, you can use the "Insert Printer Command" option of the WP
Print Format menu to insert control codes for the usual motion controls, set
number of copies, change orientation, or change font. By this means, you have
access to all of the resident fonts of the LaserWriter. If you have a
LaserWriter+, you will need the more recent version of PtrEmulate distrubuted
as PSCRIPT.PS in order to access all of its fonts.
Documentation for PtrEmulate is contained in the file PSCRIPT.DOC.
Unfortunately, this file has not been distributed with all copies of WP 4.2.
The most reliable way of obtaining it is from WordPerfect Corp.'s bulletin
board (801-225-4414, <= 2400 baud, N parity). You'll have to answer a
questionaire the first time you call which includes your WP license number.
About three working days after that you will have access to the file area where
PSCRIPT.DOC resides and be able to download it. This bulletin board also has a
lot of other up-to-the-minute information, including XONXOFF.PS should you be
without it.
Now a word about fonts. WordPerfect uses character tables (contained in
WPFONT.FIL) to look up the width of each character of any proportionally spaced
font. WP 4.2 has character tables for Times and Helvetica font families only.
Thus, although you can access the other fonts, things like underlining and
right justification won't work right. You can make your own printer
definitions and character tables for these additional fonts by using
WordPerfect's own Printer program (PRINTER.EXE, usually on the Printer 2
diskette). This program allows you to create a definition by using an
existing one as a model and tinkering from there. You must change the control
sequences to begin each of the eight fonts, and create character tables
containing the correct widths, again by copying and modifying an existing
table. The Adobe Font Manual, published as Appendix C of Apple's "Inside
LaserWriter" gives character widths of 1 point type, i.e. width as a proportion
of height. These must be converted to widths in dots at the desired type size.
(72 points = 1 inch = 300 dots). I have access only to the October 1984
revision of the Adobe Font Manual, hence the only other font I have widths
for is Courier; not very thrilling since Courier is not a proportional font.
Since I'm not even conversant with the Macintosh, I'm not well acquainted
with the variety of fonts which are available on disk for downloading to the
LaserWriter. It seems like it would be very easy to download a font from a
Mac to the printer, then access it while printing a WordPerfect document from
the PC. It looks like another font would mean a slight addition to PSCRIPT.PS
to associate a font identifier (part of the change font control sequence) with
the font in memory and size the font for use. The process of developing a
printer definition for a downloaded font would be the same. Actually, I assume
those nice people at WordPerfect Corp. are working on much of this at present
and that we may see very substantial improvements in version 5.0.
In summary, the combination of WordPerfect, TOPSPRINT, and the
LaserWriter seems like a very viable combination. The one disadvantage I must
point out is speed. On an unaccelerated IBM/PC with floppies only,
WordPerfect's PRINTER.TST document takes over two minutes from <shift>F7 to
emergence from the LaserWriter as a printed page. On the other hand, the
LaserWriter's Postscript orientation gives it more power and flexability than
other non-Postscript laser printers. Where each of the fonts of an HP LaserJet
has a fixed size, the LaserWriter can resize any of its fonts to meet the need.
Centram Systems West recommend that their product be used with a hard disk, and
it is awkward with only floppies. Nonetheless, it will work; you'll just have
to ignore the error reading drive C when you boot up.
Please respond to: TL6J@CORNELLC (Barr Ticknor, Cornell University
Department of Plant Pathology).
------------------------------
Date: Tue, 10 Feb 87 11:10:55 est
From: Jay Weber <jay@rochester.arpa>
To: info-ibmpc@c.isi.edu
Subject: COM3 Driver
Has anyone written a device driver or otherwise figured out how to
have more than two serial ports on a regular IBM-PC? Do you need
special hardware that generates a unique interrupt? I'd appreciate
any suggestions ...
Jay Weber
Computer Science Department
University of Rochester
Rochester, NY 14627
jay@rochester.arpa
------------------------------
Subject: COM3 Driver
From: Billy <BRACKENRIDGE@C.ISI.EDU>
To: Jay Weber <jay@ROCHESTER.ARPA>
The digicom board has been mentioned in several recent digests. It allows up
to 32 serial lines on a PC. It also includes software that allows use of
the standard DOS device naming. ie. COM16:. They also include software for
various flavors of unix/xenix.
Digicom cards have either 4 or 8 serial ports on a full length card. They have
a 96 pin connector, and a Medusa like cable that expands to 4 or 8 standard
25 pin RS232 connectors.
I just got delivery of a Digicom 4 board and will be running Dick Gillmann's
DLX bulletin board system which supports up to nine users on a PC.
The DLX software interrupt drivers were based on the routines written by
John Romkey and later modified by many others. These serial drivers can
be found in the <info-ibmpc> lending library. (See COM_PKG2.ASM and
GLASSTTY.ASM) This software supports two terminal lines simultaneously.
The tough part is making the code reentrant so it can support more than one
serial port. It isn't a difficult modification to support more ports.
The digicom board has a status register which tells which port caused
a given interrupt. Once that has established the base address of the I/O
port hardware programming is identical to a standard serial Port.
I know Dick looked at several multi port cards before choosing the Digicom.
Other cards either used "more modern" (read incompatible) serial chips
or refused to supply adequate technical documentation.
------------------------------
Date: Sat, 7 Feb 87 19:48:45 EST
From: Russell Nelson <bh01@clutx.BITNET>
To: b-davis%utah-cai@utah-cs.arpa, info-ibmpc@c.isi.edu
Subject: Major Bug in All versions of MS-DOS
Brad Davis is trying to open a file twice in MS-DOS, and he thinks it a
bug, and encloses software that demonstrates the bug.
Unfortunately, this is not a bug. As an optimization, MS-DOS (all
versions >=2) uses delayed writes so long as [a, the] (I don't know
which, but 'the' is more probable) file is still open. The effect of
this is what Brad noticed. To summarize, if you create a file, write to
it, (don't close it), open the file, and read from the file, you won't
be able to read what you just wrote.
Fortunately, there is a solution. Use the 'dup' handle call (I'm pinned
down by a sleeping baby at the moment) to create a copy of the handle
for the 'write' copy of the file, and close the copy of the handle. This
will cause the fat and directory entry to be updated. The advantage of
this technique over a 'close and open' sequence is that the overhead of
file opening is averted.
Speaking of file opening, MS-DOS searches directories linearly. Keep
the number of files in your subdirectories low or suffer long delays in
opening files.
-russ
GEnie: BH01
BITNET:BH01@CLUTX
uucp: decvax!sii!trixie!gould!clutx!bh01
------------------------------
Date: Sat, 7 Feb 87 18:44:21 PST
From: kneller@cgl.ucsf.edu
To: info-ibmpc@b.isi.edu
Subject: Major Bug in All Versions of MS-DOS
>From: b-davis%utah-cai@utah-cs.arpa (Brad Davis)
>; Here is a probable bug (or feature?) in MS-DOS. Does anyone know a
>; work around (without closing the first file)? Would Gordon Letwin at
>; Microsoft care to comment? This bug appears on PC-DOS 2.0, PC-DOS 3.0,
>; and MS-DOS 3.1. (Unix has no problems with this algorigthm.)
>; The test goes like this:
>; Create a file with name 'xxx'. Call this file FD1.
>; Write 80 bytes to FD1.
>; Open the file named 'xxx' a second time. Call this file FD2.
>; Note that NO errors have happened yet.
Right -- the file exists in the directory entry. No problem here.
>; Try to read 80 bytes from FD2. No bytes are read.
>; Note that NO error is reported.
What do you mean NO error? You ask for 80 bytes and read 0. That says
the read failed. Read returns the number of bytes read.
>; If in symdeb push to a new shell. See that the file 'xxx' has
>; been created but has a size of 0.
>; Exit the program. See that the file 'xxx' is now 80 bytes long.
File hadn't been closed. Until it is closed, the size stored in the
directory is *not* the number of bytes written to the file. Imagine
the disk overhead if the directory was updated each time you wrote to
a file.
>; If FD1 is closed at POINT A (see source) then FD2 will perform the read.
Yes, close the file, the directory entry is updated and the *next* open
will get the file size information from the directory and it will be
correct.
>; If FD1 is closed at POINT B (see source) then the read of FD2 still fails
>; even though the disk has been updated before the read happens.
Yes, but the file size is read when the file is opened! And it was zero then!
[ source deleted ]
The crux of the matter is that the open causes the file size to be read
from the directory entry. If you have two separate file handles, one
for reading and one for writing, they have separate file pointers. When
you write to the file with one handle, neither the other file pointer
nor other file size get changed. (When I say "file pointer", I mean
the number that tells the position in the file in bytes).
If you are simply trying to read and write from the same file, open the
file with read/write access and position the file pointer back to the
beginning of the file with the "lseek" function call (int 21h, ah=42h)
before doing the read. Then you don't have to close the file before
reading.
One more thing. If you want to force DOS to update the directory entry
so subsequent opens will work, use "dup" (int 21h, ah=45h) on the file
handle and close the duplicate handle. Then you won't have to reopen
the file.
-----
Don Kneller
UUCP: ...ucbvax!ucsfcgl!kneller
ARPA: kneller@cgl.ucsf.edu
BITNET: kneller@ucsfcgl.BITNET
------------------------------
Date: Tue, 10 Feb 87 08:30:14 cst
From: mlw@ncsc.ARPA (Williams)
To: info-ibmpc@c.isi.edu
Subject: Major Bug in All Versions of MS-DOS
Regarding the question about reading with a second file handle...
I implemented the test in MSC (4.0), and it failed as reported. Next
I investigated the dup() function, which "cause(s) a second file handle
to be associated with a currently open file." I thought perhaps this
function would implement the objective better. Reading on, though, I
found, "Operations on the file can be carried out using either file
handle, since all handles associated with a given file use the same
file pointer." This remark caused me to wonder if the second open was
attempting to access the test file with the same pointer as the first.
That would account for the observed behavior, since the pointer would
be at EOF. So...I trotted out the lseek function and sought BOF with
the second handle. The read worked fine then. This can cause interesting
problems, because I would assume that the first handle will end up pointing
to the new position, rather than its original position, as in the case
where reading proceeds by character with handle2 and writing proceeds by
string with handle1. Anyway, that's what happened.
Mark L. Williams
(mlw@ncsc.arpa)
------------------------------
Date: Sat, 7 Feb 87 12:33:32 PST
From: Allan_Davison%SFU.Mailnet%UBC.MAILNET@MIT-MULTICS.ARPA
To: INFO-IBMPC%C.ISI.EDU%MIT-MULTICS.ARPA@UBC.Mailnet
Subject: Tektronix 40XX Emulation Software and Display Adapter
For some time now I have hesitated to buy a package which will
allow me to preview TELLAGRAF (ISSCO Product) graphs on my PC
screen. Any faithful Tektronics emulator would be an improvement on
the VT52 emulation I am using now - even if resolution was
marginal. (When I had an APPLE II, I used Tekterm or Tekalike -
quite usable despite marginal resolution and occasional
unpredictable responses). Presumably a Hercules compatible or EGA
compatible product would have better resolution. In any event, I'd
like to hear from someone who has done some comparison shopping
before I commit myself. Can someone update me?
------------------------------
Date: Mon, 9 Feb 87 18:34:16 PST
From: Mike_Gertsman%UBC.MAILNET@MIT-MULTICS.ARPA
To: INFO-IBMPC@C.ISI.EDU
Subject: NEC V30 in Compaq Deskpro
Does anyone have any idea why a program which emulates CP/M
on a V20 should not work on a V30? I just put a V30 in a
Compaq Deskpro and it seems to work fine, but the CP/M emulation
program just crashes the computer completely (this is the V20-80
program found on a local BBS - it seems to work well on a V20).
------------------------------
From: Michael Mclagan <PP136727%CARLETON.BITNET@wiscvm.wisc.edu>
Date: 10 Feb 87 14:31:00 EST
Subject: Telink and Ymodem Batch Transfer Protocols
Hello there. I was wondering if anyone had any information on the
TELINK or YMODEM batch file transfer protocols. All I need is the
specs for the file information packets, and how to signal the next
file, and how to signal transfer complete. Thanks for any help.
Michael McLagan
[YMODEM.DOC is in the info-ibmpc lending library. -wab]
------------------------------
Date: Tue, 10 Feb 87 17:10 EST
From: slade.wbst@Xerox.COM
Subject: 9 Track Tape Drives
To: INFO-IBMPC@C.ISI.EDU
cc: slade.wbst@Xerox.COM
I think I am going to have to add a standard IBM magnet tape
compatible drive to my PC clone (too much data to use one of the
conversion services). Anybody have any recommendations on a unit or
what to look out for. Minimum specifications : DOS compatible, some
high level language drivers, 1600BPI, ASCII, etc. So far I have sent
for literature on the Qualstar and Flagstaff units, anyone have one of
these?
A few months back there was a review in, I think, PC Tech Journal. In
addition to that article, can anyone point out any other reviews or
other articles that I should be looking at?
Thanks.
Michael Slade
Arpanet: slade.wbst@xerox.com
------------------------------
From: rjb@mitre-bedford.ARPA
Subject: Public Domain vi
Date: Mon, 09 Feb 87 10:33:33 EST
Sender: rjb@mitre-bedford.ARPA
i would like to know if there is a public domain (freeware or
shareware) clone of the unix vi editor that runs under PC/DOS that
runs on an IBM PC/XT. i am trying to reduce the number of editors that
i need to use to do word processing, program development, etc.
thanking you in advance, i remain, yours truly, ross bettinger.
[Several commercial vi editors have been mentioned in the digest -wab]
------------------------------
From: mdjones%castor.usc.edu@usc-oberon.arpa (Mitch Jones)
Date: 29 Jan 87 16:24:43 GMT
To: mod-computers-ibm-pc@seismo.CSS.GOV
Subject: Timing Code
I'm looking for code that will allow me to count from 0-n in milliseconds
where n is the point at which the user presses a key. The code must be
able to pass the millisecond count and the key pressed to basic since the
program will be a subroutine for a basic program. Does anybody know of some
similar code, or could someone set me on the right track. BTW, it also needs
to work on pc's and compatibles.
Thanks,
Mitch Jones
mdjones@castor.usc.edu.UUCP
------------------------------
From: <ptsfa!uucp@ames.arpa>
Date: 2 Feb 87 06:59:45 GMT
Subject: Problems with Mace Utilities
I have just purchased a copy of Paul Mace's Utilities version 4.0.
I have a problem in that I cannot get it to recognize my hard disk. I'm
trying to create the BACKUP.M_U file in my root directory (Option F8)
but, after doing a few disk accesses, the program says:
"Incompatible device...sorry"
I have an Adaptec 2070A controller with a Seagate ST-238 drive. I thought
that this was a pretty standard configuration and that there was no difference
in the way MS-DOS accesses it (vice a standard MFM controller/drive). My disk
is less than 32MB formatted, and I am using MS-DOS 3.2.
Has anyone out there had a similar experience with this package?
Has anyone had success using the Mace Utilities with an RLL controller?
Thanks,
Neil Smith
nsmith@well.uucp -or- ...ihnp4!lll-lcc!well!nsmith
------------------------------
Date: Sat, 31 Jan 87 13:17:14 EST
From: "Peter J. Laughton" <PJL%MX.LCS.MIT.EDU@MC.LCS.MIT.EDU>
To: info-ibmpc@C.ISI.EDU
Subject: YACC
Quoting Len Tower (tower@mit-eddie.MIT.EDU) from issue 4 of
Info-IBMPC, "BISON, a YACC compatible parser generator, is out there."
Has anybody attempted to port it to an IBM PC? Please relay
information about your success.
Thanks.
Pete Laughton
------------------------------
End of Info-IBMPC Digest
************************
-------