Info-IBMPC@WSMR-SIMTEL20.ARMY.MIL ("Info-IBMPC Digest") (07/22/90)
Info-IBMPC Digest Sun, 22 Jul 90 Volume 90 : Issue 113
Today's Editor:
Gregory Hicks - Rota Spain <GHICKS@WSMR-Simtel20.Army.Mil>
Today's Topics:
ANSI.SYS and keyboard configurations
Performance testing of FD/HD controllers & video cards.
Re: Conflicting 'prompt' and 'echo off' commands in BAT-file
Harvard Graphics 2.3 Update
All our AT Disk Controllers are going Bad
Info requested on OKIDATA Laser Printers
LZEXE/UNLZEXE oddity (2 msgs)
Micro-Channel Bus
parallel port input/output
parallel ports
pc hard drive security
request for MS-DOS egrep
Tape Backup units
Send Replies or notes for publication to:
<INFO-IBMPC@WSMR-SIMTEL20.ARMY.MIL>
Send requests of an administrative nature (addition to, deletion from
the distribution list, et al) to:
<INFO-IBMPC-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
The Simtel20 Archives discussed are available from:
WSMR-SIMTEL20.ARMY.MIL (see file PD1:<MSDOS.FILEDOCS>AAAREAD.ME details
on file directories and descriptions.) Problems with files obtained
from the Archives should be addressed to:
<ACTION@WSMR-SIMTEL20.ARMY.MIL>
Archives of past issues of the Info-IBMPC Digest are available by FTP
only from WSMR-SIMTEL20.ARMY.MIL in directory PD2:<ARCHIVES.IBMPC>.
WSMR-SIMTEL20.ARMY.MIL can be accessed using LISTSERV commands from
BITNET via LISTSERV@NDSUVM1, LISTSERV@RPIECS and in Europe from EARN
TRICKLE servers. Send commands to TRICKLE@<host-name> (example:
TRICKLE@TREARN). The following TRICKLE servers are presently
available: AWIWUW11 (Austria), BANUFS11 (Belgium), DKTC11 (Denmark),
DB0FUB11 or DTUZDV1 (Germany), IMIPOLI (Italy), EB0UB011 (Spain),
TAUNIVM (Israel), and TREARN (Turkey). SIMTEL20 is not accessable on
the first Wednesday of each month from 6-8pm Eastern Standard Time.
If you are unable to access SIMTEL20 via Internet FTP or through one of
the BITNET/EARN file servers, most MSDOS SIMTEL20 files, including the
PC-Blue collection, are available for downloading on the Detroit
Download Central network at 313-885-3956. DDC is a networked system
with multiple lines that support 300, 1200, 2400, and 9600 bps (HST).
This system is a subscription system with an average hourly cost of 17
cents per hour. It is also accessable on Telenet via PC Pursuit and on
Tymnet via StarLink outdial. New files uploaded to WSMR-SIMTEL20 are
usually available on DDC within 24 hours.
----------------------------------------------------------------------
Date: Tue, 17 Jul 1990 10:02:15 EDT
From: Kenneth Herron <kherron@ms.uky.edu>
Subject: ANSI.SYS and keyboard configurations
I suppose the purpose of this exercise is to avoid buying a new
keyboard, but most aftermarket keyboards have an AT/XT mode switch on
them.
Kenneth Herron
------------------------------
Date: Tue, 17 Jul 90 18:12 EDT
From: Jeff Gardner <S72TGAR%TOE.TOWSON.EDU@CORNELLC.cit.cornell.edu>
Subject: Performance testing of FD/HD controllers & video cards.
I'm looking for some assistance in several related areas. I'll
give some background to hopefully give perspective to my questions.
I do application development work using Relational Database
packages such as PC-Oracle or R:Base for DOS. My development platform
is an AT-clone/ 12.5Mhz/4MB RAM/EGA/twin Seagate ST251-1 (28Ms) HDs.
The questions I have relate to response time performance for a variey
of LARGE (20MB - 200MB) Relational Database applications. I've been
experiencing a trend with some of the more complex queries where
regardless of host platform/CPU, response time seems to be optimized
only at certain level. Then no matter what, I'm unable to reduce
response time to meet customer preference. I was begining to think
there is some form of hardware limit being encoutered. So I'm
researching PC hardware performance specs.
I just finished reading the "Bus Wars" feature in the June 26, 1990
issue of PC Magazine. It has raised more questions for me than answers
at this point. It seems that the video and controller cards current
capabilities are lagging far behind the capabilities of the 286/386/486
PCs. With that in mind. . . ..
1. Based on the article in PC-magazine I'm not sure if the limiting
factor for I/O is bus architechture on the motherboard, or the design
of the controller card, or a combination of the two. (I know that HD
speed in Ms is directly related as is the Interleave of the controller
card.)
2. I'm looking for additional information on FD/HD controller card
through put capabilities for 286s & 286 VS 386/486s.
3. Also based on the article it appears that video card speed
capabilities can effect the text/graphics display response performance
a PC system.
4. What could I use to test for maximum I/O capability on a
customers PC? Also, testing the I/O during the running of an
application?
5. If you were going to create "the killer RDBMS hardware
platform", what components would you use?
Feedback? Additional information references?
6. Has anyone used the "R:Base for developers" package yet? What's
it like? Good points? Bad points? etc. . . ..
If you have any comments, opinions, suggestions, etc. Please feel
free to mail to me directly or via the news letter. Thanks in advance
for your support and feedback. If my professional background can be of
help to anyone, drop me a note directly. I check my E-Mail daily.
Thanks again,
Jeff Gardner
{* Dr. Jeff Gardner
{* Towson State University *}
{* Cook 29, 301/830-4083 *}
{* Baltimore, MD. 21204 *}
{* Bitnet: S72TGAR@TOWSONVX *}
------------------------------
Date: 18 July 90, 08:51:21 CET
From: Herbert Gasiorowski <GASIOROW@DMRHRZ11.bitnet>
Subject: Re: Conflicting 'prompt' and 'echo off' commands in BAT-file
It is only near to impossible to send the <esc> character to ANSI.SYS!
There are at least two ways to do so:
1. Take an editor who is able to handle special characters and ECHO
just you want in a batch file, e.g:
ECHO <esc>2J will clear the screen
The turbo-pascal-editor allows <ESC> to be entered using ^P followed by
the <ESC> key.
Echo should be OFF and 'TYPE'-ing a file with lines like the one above
will also clear the screen!
2. Some MS-DOS Versions include a simple Command ESC.COM: It works like
E but will send the <ESC> character before showing the rest of the
line, so
ESC 2J will also clear the screen
The turbo-pascal source for such a program might look like:
PROGRAM ESC;
BEGIN
WriteLn( #27,ParamStr(1) );
END.
This program will only 'echo' the first parameter - until a blank is
found.
Herbert Gasiorowski (West Germany,Uni.Marburg)
------------------------------
Date: Tue, 17 Jul 90 10:43:12 MDT
From: ATRC-WDA@WSMR-SIMTEL20.ARMY.MIL
Subject: Harvard Graphics 2.3 Update
I just received the new upgrade to Harvard Graphics. It takes a total
of 6.5 MB of hard disk space to load. There are few improvements over
the current version. I would suggest to all that they wait for the
Windows version or HG 3.0 before upgrading.
------------------------------
Date: Mon, 16 Jul 90 0:54:51 EST
From: "Mark Bramwell" <Mark@ARDSLEY.Business.UWO.CA>
Subject: All our AT Disk Controllers are going Bad
> From: david@wubios.wustl.edu (David J. Camp)
> We have 7 IBM AT (true-blue) computers. They are in the neighborhood of
> 5 years old. We have had to replace 5 of the disk controllers in the
> past few months. The typical symtpom is that the diskettes stop
> operating properly. Some of them only failed when writing in 360K mode,
> but others failed differently. We have also had to replace the disk
> controllers on some old XT's and compatibles.
We have 110 true blue machines. In the past 2 years we have replaced
approx 60+ controllers. Most of them forgot that they had floppy
circuits. Since all of our secretaries have hard drives and network
cards, we usually don't notice the problem until they do a backup.
About every 6 months for most :(
We buy cheap Western digital cards. It is a much better card because
it supports 1.44meg 3.5 floppies (correctly).
Mark Bramwell, VE3PZR Located in sunny London, Ontario
Internet: Mark@ARDSLEY.business.uwo.ca IP Address: 129.100.29.33
Packet: VE3PZR @ VE3GYQ UWO Phone: (519) 661-3714
------------------------------
Date: Tue, 17 Jul 90 10:46:22 EDT
From: "VISHWANATH, H.C." <HVISHWA%UOTTAWA.bitnet@ugw.utcs.utoronto.ca>
Subject: Info requested on OKIDATA Laser Printers
Hi ! I am on the look out for a Laser printer and recently I read PC
magazine's article appreciating OKIDATA's new Laser printer. It's about
$ 850/- which I think is very cheap. However, the printer has 512 k (I
guess) memory which I am sure is not enough to print my architectural
drawings. OKIDATA provides an additional memory cord but it's too
expensive ($ 500/- for the first 1 meg and $ 100 for additional memory
chips.)
Do any of you know of any other company supplying cards compatible
with such printers and if so I would really appreciate some info on
them like their name, cost etc.
Thanks in advance,
Vishwa.
HVISHWA@UOTTAWA.BITNET
------------------------------
Date: Tue, 17 Jul 90 11:45:04 EDT
From: jrv@sdimax2.mitre.org
Subject: lzexe/unlzexe oddity
> I have just started using LZEXE, and have been very happy with the disk
> space I'm saving. So far, all the programs have run fine. However,
> I've run into some strange behaviour when using UNLZEXE to reverse the
> compression....
>
> Volume in drive E is MS-RAMDRIVE
> Directory of E:\
>
> GRAPH OLD 162019 6-14-90 8:42p original program
> GRAPH OLZ 61647 6-14-90 8:42p compressed with LZEXE
> GRAPH EXE 112982 6-14-90 8:42p uncompressed with UNLZEXE
...
> Is Turbo C doing something really dumb, which wastes 50000 bytes?
Jim Groeneveld (GROENEVELD%TNO.NL@cunyvm.cuny.edu) writes...
> ...I can tell
> you that I have had the same experience with .COM and .EXE files
> downloaded from Bulletinboards using the XMODEM protocol. This protocol
> enlarges any file up to the next integer multiple of 128 bytes and
> compressing them with LZEXE yields the same kind of messages on overlays
> that you got.
That's a good point, but I had compiled these files myself, and never
transmitted them. It gives us a clue to how LZEXE treats extra bytes,
though.
Martin Pergler (PT182286@admin.carleton.ca) suggests...
> I can't be sure at a distance, but one explanation that comes to
> mind is this: TC stores debug information at the end of an EXE file
> unless you tell it otherwise. LZEXE notices this, and since it is not
> part of the standard EXE structure, it thinks it might be an overlay
> (some overlay linkers append overlays in such a way to the end of the
> EXE file). NOt knowing what to do with the code, it deletes it. Since
> it does not appear in the LZEXEd file, it cannot be resurrected.
This is apparently the right answer. When I recompile with debugging
off, the file size is 112K, the same as after the the LZEXE/UNLZEXE
sequence. I can treat this behaviour as a feature. When I finish
debugging (:-), instead of recompiling everything with debugging off, I
need only run LZEXE on the .EXE file.
- Jim Van Zandt
------------------------------
Date: Tue, 17 Jul 90 10:38:49 EDT
From: jrv@sdimax2.mitre.org
Subject: LZEXE/UNLZEXE oddity
Jim -
I eventually found that the extra stuff was the debugging information
Turbo C was adding. Thus, instead of recompiling without debugging, I
can merely run LZEXE.
- Jim
------------------------------
Date: Wed, 18 Jul 90 09:20:15 SET
From: Roger Thijs <RTHIJS%BANUFS11.BITNET@CUNYVM.CUNY.EDU>
Subject: Micro-Channel Bus
In Ibmpc-l 90/104 Guven Mercankosk asks for references regarding the
Micro-Channel Bus. Very readable and well illustrated is:
IBM Personal System/2 Seminar Proceedings
The publication for Independent Developers of Products
for IBM Personal System/2
Volume 5 Number 3
IBM Personal System 2, Models 50, 60, 80
Micro Channel Architecture
Hardware Features and Design Considerations
May 1987
v + 83 pages (82 ill.)
Published by IBM Entry Systems Division
I suggest you contact your nearest IBM office, They certainly have a
more recent edition.
Roger Thijs, Antwerp UFSIA University
------------------------------
Date: Wed, 18-JUL-1990 09:49 GMT + 1:00
From: "Thomas Greve, PI Bonn" <GREVE%DBNPIB5.BITNET@CUNYVM.CUNY.EDU>
Subject: parallel port input/output
Just a remark on the "parallel port" diskussion on this list: There is
NO problem reading back the parallel port. But there IS a problem
switching off the output drivers of the parallel port. Usually,
low-cost IO-cards are equipped with a 82C11 Chip, which contains the
whole port logic, output buffers etc. This Chip provides no way to
switch off the output buffers -- so all you can read back is what you
just wrote to it. Only in the PS/2 series, Bit 5 of the control port
switches the output buffers on and off.
The only input lines of the common parallel port are the
handshake-/paper- empty-/... lines, (4 lines total), which can be read
by BIOS call. Is does not seem very useful to me, to have "parallel"
communication through these lines... Thomas
------------------------------
Date: Wed, 18 Jul 90 01:05:21 -0500
From: Wayne Hamilton <hamilton@osiris.cso.uiuc.edu>
Subject: parallel ports
Gerhardt Vogt writes:
> 2. There is a chip 8255 available for parallel communication. It can be
> programmed for either input or output. I thought this chip is built
> into parallel cards for PC's which is not true. To make it cheaper(?)
> something different is in PC's. In principle it's possible to use it
> for input, but you have to use the handshake lines which are normally
> used to tell the computer, if the printer is ready etc. Laplink, for
> example, uses 4 of the 8 datalines to send to 4 status lines on the
> other side. Each byte which has to be sent is sent in two parts with 4
> bits each. If you do some soldering, it's principally possible to use
> all eight data-lines, but ...
>
> 3. I decided to use a self built parallel port with a 8255 chip. It's
> easy to use and to program and I hope I can transfer with about
> 100kByte per second which seams to be feasible after the first few
> tests.
i've noticed that some multifunction cards for XTs come with a MOTO
clock chip interfaced to the PC bus via an 8255; the AT versions of the
same product usually differ only in lacking the 8255 and clock chip,
tho the artwork is still on the PCB (they sometimes substitute 16450
UARTs for the 8250s also). i have considered using one of the XT
boards in my AT, with a little surgery to remove the clock chip and
replace it with a ribbon cable to take the 8255's data and handshake
lines to the outside world.
Rick Beebe says:
> IBM made no provisions for parallel input until the introduction of the
> PS/2. On PS/2's, the diagram is the same except that the data lines are
> IN/OUT. Now, my guess would be that manufacturers *other* than IBM
> probably implemented bidirectional printer ports early on (it may just
> be an undocumented "feature" in IBMs as well).
>
> Printer data goes out (and comes in?) through port 0x387. Ports 0x379
> and 0x37A are used to read the status lines (i.e., they're the input
> ports, 0x387 is the output port).
>
> ...
>
> Data Latch (Hex X78, X7C)
> Writing to this address causes data to be stored in the printer's data
> buffer. Reading this address sends the contents of the printer's data
> buffer to the system microprocessor.
>
> No, I don't really understand what it means, either.
(i'm writing this mostly from memory, with an almost illegible
schematic in front of me.) the standard ibm pc printer port uses a
buffer IC (LS374) for the output port, and a latch (LS244?) for the
input port (ie, WRITEs load the buffer, READs unload the latch). the
outputs from the '374 go to the DB25 connector and thus to the printer.
the inputs to the '244 likewise connect to the same pins on the DB25.
what you get when you READ the data port tends to be whatever you last
wrote (since the printer is probably passive). if you put an active
device in place of a printer, you will read what the device is sending,
mixed with the output of the buffer IC. i haven't tried it, but
perhaps with all zeros or all ones in the buffer, you read the latch
and get just what your external device is sending.
the thing that is really annoying about this arrangement is that the
'374 has an input called /OE (for Output Enable) to control the output
of the IC. it's grounded - output permanently enabled - on the ibm
printer card. also, over on the LS174 that makes up the "control"
port, there is an unused output (the rest go to interrupt enable logic,
or out the DB25 for such functions as strobe and init). it's a
relatively simple job (i did it, and i'm no EE) to cut the trace that
grounds the OE and jumper that OE over to the unused output on the
'174. voila, nice clean, bidirectional parallel port. when you write
a '1'(?) bit to that previously-unused bit in the control register, the
'374 tri-states its outputs so you can read your external device
without interference. it even works out that the initial power-on
state of that bit defaults to the output mode, so the port will pass
any BIOS diagnostics testing your printer port. ibm *could* have built
the board that way in the first place, and given us a world of useful
functions for all those 2nd and 3rd printer ports that tend to
accumulate when one adds multifunction cards. i'm not sure, but i
suspect the PS/2 printer port *acts* as if it were built this way; i've
heard that the direction change control bit is the same (bit 5 in the
control register).
i first saw this surgery described in computer shopper back around
1985, and i think i've seen other descriptions in places like micro
cornucopia (RIP).
(i'm writing this pretty late, so it occurrs to me i may not be saying
all this with my customary lucidity...)
wayne hamilton
U of Il and US Army Corps of Engineers CERL
UUCP: {att,iuvax,uunet}!uiucuxc!osiris!hamilton
I'net: hamilton@osiris.cso.uiuc.edu
Lowtek: Box 476, Urbana, IL 61801; (217)384-4310(voice), -4311(BBS)
------------------------------
Date: Tue, 17 Jul 90 11:34 CDT
From: Eric DeVolder <DEVOLDER@KSUVM.KSU.EDU>
Subject: pc hard drive security
I am looking for a software package, preferably PD or shareware, that
consists of these features:
A device driver that, upon boot-up, calls a program that prompts
for login, and then accordinly assigns read/write capabilities for my
hard drive, and records login. This program needs to be able to handle
multiple users over the course of the day. (i.e. login one person,
then when this person finishes, login other users, and be able to
continuously change the capabilities as each user logs in.) I would
assume that this is easily accomplished by having the program named
LOGIN and in the path, so that the user types LOGIN to obtain his/her
capabilities.
The device driver login program needs to have the ability to edit
a file containing the login names and the corresponding permissions,
and be able to encrypt that file to prevent tampering.
In addition, the program will make use of interrupts that will
prevent read and/or write to/from the hard disk.
And lastly, it will maintain a file containing information such as
the login name and time. Logout is not necessary (and probably
difficult to handle properly on a PC which is easily turned on and off)
The reason for requiring a driver is that it can not be bypassed
at boot-up, although I realize most systems can bypass hard-disk at
boot, though this is something I am able to work with.
I have seen a variety of drivers that prompt for a password, and
programs that can write protect a hard disk, but I have not been able
to find a package that incorporates a login, issues permissions, and
records use. I do not wish to have a menu-type program that prevents
access to programs, but rather a program that prevents access to the
disk!
--Eric J. DeVolder
Computing and Telecommunications Consultant
Kansas State University
------------------------------
Date: Wed, 18 Jul 90 07:10:01 EDT
From: tsilva%aaec1.UUCP@dspvax.mit.edu (Tony Silva)
Subject: request for MS-DOS egrep
I have to believe someone in netland has a real, standalone egrep (not
grep) for MS-DOS (not PC UN*X's, etc.). I would prefer GNU egrep, but
would be grateful for any egrep at this point. Can anyone E-mail me a
copy of the executable (uuencode'd, binhex'd, or otherwise)? My guess
it would only be a few 10's of kB. I don't need the sources or
documentation.
Alternately, I'll FTP it from any location you suggest, although I've
already tried most of the obvious places. Please include info on the
exact directory in which to find it.
Thanks in advance.
Tony Silva
Atlantic Aerospace Electronics Corp. ARPA: tsilva%aaec1.UUCP@dspvax.MIT.EDU
470 Totten Pond Road UUCP: ...!seismo!dspvax!aaec1!tsilva
Waltham, MA 02154
(617)890-4200
------------------------------
Date: Tue, 17 Jul 90 13:06 EST
From: <TLEWIS%UTKVX2.BITNET@pucc.PRINCETON.EDU>
Subject: Tape Backup units
Does anyone have any information on Tape backup units, or removable
hard disk drives that will run through the parallel port of a PS-2?
(Serial port if I have to) At least something that doesn't require an
adapter card of some sort. I'm looking at using it as a backup device
almost exclusively. Any info would be appreciated!
Terry Lewis
University of Tennessee
Martin, Tennessee 38238
TLEWIS@UTKVX
------------------------------
End of Info-IBMPC Digest V90 #113
*********************************
-------