Info-IBMPC@WSMR-SIMTEL20.ARMY.MIL (02/14/89)
Info-IBMPC Digest Mon, 13 Feb 89 Volume 89 : Issue 21
Today's Editor:
Gregory Hicks - Chinhae Korea <COMFLEACT@Taegu-EMH1.army.mil>
Today's Topics:
RPICICGE.Bitnet Listing DIRs of files
Closing files left open by TSR
UNIX on NEC V20; 3.5" drives; DiskManager PC
RE: Memory parity interupt error
RE: Memory parity interupt error on a Zenith AT (IBM clone)
More on random number generators
Hard Disk Info Wanted
Hard Disk Interleave
Important update to DSZ fixes bug
I/O on an Epson Equity II
Waveform Editors for PC's
Lotus 123 behaviour problem
millisecond timing on PC
More 4107 questions
Re: Data acquisition for IBM PS2 model 80
SIMTEL20 index and CRC list files now available archived
sound for ibm
vga pallete
X windows (server) for PC
----------------------------------------------------------------------
Date: Mon, 06 Feb 89 12:41:26 EST
From: "John S. Fisher" <FISHER%RPICICGE.BITNET@VM.ECS.RPI.EDU>
Subject: RPICICGE.Bitnet Listing DIRs of files
To get a directory list of files more than 30 days old, the user needs to
put a number (>30) after the file name pattern. For example,
/PDDIR PD:<msdos.asmutl>*.* 9999
Note that there is a space before the 9999.
------------------------------
Date: Fri, 3 Feb 89 18:11 GMT
From: "Barry Redmond" <BREDMOND%dit.ie@CUNYVM.CUNY.EDU>
Subject: Closing files left open by TSR
Can anybody tell me if there is a way to close a file that has been
accidentally left open by a TSR? The file is a configuration file only
required when the TSR is loaded, but it doesn't close it when it is
finished using it.
The TSR is loaded from a network file server, so the open file causes
difficulties with trying to manipulate links to the server.
Perhaps it is possible to track down the FCB? All suggestions welcome.
Thanks in advance,
Barry Redmond BREDMOND@DIT.IE
Dept of Electronics & Communications
Dublin Institute of Technology
Kevin St
Dublin 8
Ireland
------------------------------
Date: Sun, 5 Feb 89 19:25 EDT
From: <J_KAZURA@UNHH>
Subject: UNIX on NEC V20; 3.5" drives; DiskManager PC
Greetings All,
I just read Info-IBMPC Digest V89 #17, and I wanted to respond to
a few questions and comments.
1) Don Meredith had a question about a UNIX system for a PC with an
NEC V20. The Computer Science deptartment here at the University of New
Hampshire uses a program called MINIX. It barely runs on the AT&T
PC6300's but runs fine on my clone with an NEC V20 (8Mhz). It does
emulate UNIX just fine. Janna Stevens here could give you more help on
the matter if anyone is interested. JL_STEVENS@UNHH.
2) James Massey commented that he had had problems with 3.5" drives.
He said that there were problems going from high density to low density
and so forth. I thought I'd just say that we have had no problems (as
yet) with switching media and drives. We have IBM PS/2's all models.
Using DOS 3.3
3) A note about the DiskManager PC. We have a public cluster with 15
IBM Mod 30/286 E21 (20meg) running DiskManager PC the programs is a pain
in the bottom for advanced users, but works great. Contact Janna Stevens
for actual experience with the program. <JL_STEVENS @ UNHH>
Joe Kazura
University of New Hampshire
J_KAZURA@UNHH
------------------------------
Date: Sun, 5 Feb 89 20:19 EST
From: "Speed kills..." <INS_AJDC@JHUVMS>
Subject: RE: Memory parity interupt error
> I'm working on a project in the physics department. I'm trying to debug
>an error of the form "memory parity interrupt." The code in which the
>error occurs is a data acquistion program.
> Data is input from a photosensor which records the intensity of light.
>The data is written into memory via a D.M.A. (Direct Memory Access)
>operation. The first time the data is manipulated in the code produces
>the "memory parity interrupt." Actually, the error doesn't occur all the
>time, only some of the time but at the same point of the code.
>Can you tell be any information about the nature of this error? Ie, when
>is the memory parity tested? What tests the parity?
Steve,
A parity error is displayed when the computer realizes that the
memory has an error. Specifically it holds one extra bit per byte that is
set to either a 1 or 0 depending on what the other 8 are set to. This is
used as a checksum. And when the check fails, the computer "crashes".
Possible sources of error are, a faulty DMA chips (they are not setting
the parity bit right), a faulty memory chip (it loses some data), or
faulty power supply (the power to the chips is unstable and the data
"fades"), also the way you write to memory, if you by-pass certain steps
(I don't know the exact procedure) you could be skipping the parity
(unlikely, otherwise you would get lots of errors), and lastly large
amounts of data will eventualy produce an error (the laws of probability).
As a solution you might want to have the hardware checked, or try to break
down the amounts of data you send. There is a short term software
"solution", PC Magazine ran an article that contained a TSR program that
would keep the computer from "crashing" when it detected a parity error,
but alas I don't remeber what issue.
-- Speed (Justin Chandler)
INS_AJDC@JHUVMS
G49I1930@JHUVM
------------------------------
Date: Sun, 5 Feb 89 18:51:23 PST
From: madler@Hamlet.Bitnet (Mark Adler)
Subject: RE: Memory parity interupt error on a Zenith AT (IBM clone)
In response to:
>> Data is input from a photosensor which records the intensity of
>> light. The data is written into memory via a D.M.A. (Direct
>> Memory Access) operation. The first time the data is manipulated
>> in the code produces the "memory parity interrupt." Actually, the
>> error doesn't occur all the time, only some of the time but at the
>> same point of the code.
>>
>> Can you tell be any information about the nature of this error?
>> Ie, when is the memory parity tested? What tests the parity?
>>
>> Steve Zelazny (v055l9y3@ubvms.bitnet)
Parity checking provides single-bit error detection. An extra parity bit
is saved every time a byte is written, and checked every time a byte is
read. This applies to 16 bit reads and writes as well---two parity bits
are generated or checked, one for each byte. All of this is done in the
memory hardware. If the parity is wrong, a non-maskable interrupt is
generated and the BIOS will service this interrupt and report a parity
error. This is usually considered an extremely fatal error, since the
byte that was read might have been an instruction.
A parity error on a read indicates that one of the nine bits went wrong
either when the byte was written, when it was read, or sometime in
between. If it was sometime in between, that means that something is
wrong with one of the memory chips that the nine bits are stored in. If
it happened during the read or write, it may indicate that there is
something wrong with the timing, most likely not enough time was allowed
for the read or the write.
In your case, since you have been using the memory for other things and
haven't had any problem with it before, the parity error is probably not
occuring during the read, or the interval before the read. I would guess
that the timing of the DMA write operation being generated by your data
acqusition hardware is not compatible with the Zenith memory for some
reason. Assuming that the DMA device was designed and tested with a real
IBM, the incompatibility probably can be blamed on your Zenith.
Of course, blaming Zenith doesn't solve anything. I would first see if
your data acqusition hardware has any adjustments for its memory
timing---perhaps the insertion of a wait state. If it does, then do this
and if my guesses are correct, your problem should go away. If not, and
you have an 8 MHz Zenith, try lowering the clock rate to 6 MHz. This
should also make the problem go away. If you can't do that, then the only
thing left that doesn't require a digital hardware designer is to put in
faster memory chips. That is, go from 150 ns RAM's to 120 ns RAM's.
Unfortunately, that can be pretty expensive nowadays. If your problem is
marginal (which it sounds like it is), this should make the problem go
away as well.
If you are, or have access to, someone who can design digital hardware,
then there is the possiblilty of modifying the timing of the DMA writes
from your data acqusition board. This is extremely difficult though and
is frought with peril. (A fix for one problem can sometimes cause other
unforseen problems.) It may be worth checking to see if the manufacturer
of the board has a fix like this.
There is one more thing you can do, but it doesn't solve the problem: you
can disable the parity errors. Port 61 hex controls the speaker and
parity error actions. The following code will ignore parity errors that
are generated either on the system board or on the bus (from an assertion
of the -I/O CH CK line):
in al,61h
or al,00001100b
out 61h,al
To turn parity checking back on:
in al,61h
and al,11110011b
out 61h,al
This would be the equivalent of accepting noise in your data that consists
of occasional bit flips. It may not be so bad, since the most likely bit
to be wrong out of the nine is actually the parity bit, which isn't part
of your data anyway. The reason for this is that it takes a tiny bit more
time to generate the parity bit, so it gets to the RAM's a little later
than the other eight data bits. Therefore, if there is not quite enough
time to get that parity bit written, it will cause a parity error even
though the other eight bits (the data) are correct.
Mark Adler
bitnet: madler@hamlet
arpa: madler@hamlet.caltech.edu
------------------------------
Date: Mon, 6 Feb 89 13:12:52 PST
From: madler@Hamlet.Bitnet (Mark Adler)
Subject: More on random number generators
This is a comment on John Levine's contribution on random number
generators ...
He quotes the article by Park and Miller in Communications of the ACM
volume 31, number 10 (October 1988): "Random Number Generators: Good Ones
Are Hard To Find". Quite true. Upon looking up the article, however, I
was dissapointed to find no new results beyond what is in Knuth
(Seminumerical Algoithms, 2nd ed.) The authors, who teach a computer
simulation course, have found that the random number generators in many
computer science textbooks are remarkably bad. They therefore propose a
generator, with several desireable features, as a "standard" generator, at
least for teaching purposes. Among those features are: randomness (of
course), portability, and repeatability. This is to facilitate checking
the results of students and independence from random number generators
that come with particular languages or machines (which are also usually
bad).
The random number generator they suggest in the article, the one that John
included in his contribution, has the great virtue of being portable
across machines and languages that have 32 bit (or larger) signed
integers. It is the linear conrguential method (x'= ax mod m) with
m=2^31-1, the multiplier a=5^7=16807, and coded to avoid integer
arithmetic overflow. The choice of the multiplier is the only thing I
would question here. The multiplier they give does provide the longest
sequence possible for that m, but so does about 534 million other
multipliers. So how do we know if 16807 is better than any other
multiplier? Knuth provides a test, the Spectral Test, for the "a" used in
the linear congruential method to see how good such a generator would be.
According to Knuth: "... not only do all good generators pass this test,
all generators now known to be bad actually fail it. Thus it is by far
the most powerful test known, ...". I ran the spectral test on the
multiplier 16807 and also on the multiplier 314159269, which is the only
multiplier Knuth ran the spectral test on for m=2^31-1. The results were:
a=314159269 a=16807 Minimum for "passing with
flying colors"
v2^2 1,432,232,969 282,475,250 (bigger is better)
v3^2 899,290 408,197
v4^2 36,985 21,682
v5^2 3,427 4,439
v6^2 1,144 895
lg v2 15.2 14.0 15.0
lg v3 9.9 9.3 10.0
lg v4 7.6 7.2 7.5
lg v5 5.9 6.1 6.0
lg v6 5.1 4.9 5.0
u2 2.10 0.41 1.00
u3 1.66 0.51 1.00
u4 3.14 1.08 1.00
u5 1.69 3.22 1.00
u6 3.60 1.73 1.00
So, 16807 is a pretty good multiplier, but it doesn't "pass with flying
colors" (based on Knuth's criterion), especially for v2 and u2 which
indicate the correlations of any two successive random numbers in the
sequence. Since it is common to sample the points in a plane in a
simulation or Monte Carlo calculation, this could make the results
sensitive to the random number generator. Except for five-dimensional
correlations, the multipier 314159269 is clearly better than 16807.
Of course, out of the half a billion possible, there may be better
multipliers than 314159269, but it would take a while to find one. I use
my own random number generators written in assembler that are not only
very fast, but also use multipliers with better results than either of
those above. However they use m=2^32 and depend on the way multiplication
overflows, and so do not lend themselves to portability. I also switch
between a linear congruential method and a completely different random
number generator (the additive method, which unfortunately cannot be
subjected to the spectral test), just to make sure that any calculations I
do are not dependent on the random number generator. Since no random
number generator can be proved to be good, the idea of a "standard" random
number generator for other than teaching purposes seems foolish to me.
You would want several so that you can have some confidence that your
results are real and not an artifact of the random number generator
itself.
Mark Adler
bitnet: madler@hamlet
arpa: madler@hamlet.caltech.edu
------------------------------
Date: Mon, 6-FEB-1989 22:30 +0100
From: "UBMJS2::RMEYER" <U0018%DGOGWDG5.BITNET@CUNYVM.CUNY.EDU>
Subject: Hard Disk Info Wanted
>The manufacturer is MICROPOLIS, The type is HDA#30059 (at least I found
>that number on the case).
>
>The media defect table - also on the case - reports no less than 27
>errors. Least and highest numbers that occur are
>
> 0 .. 4 Hd
> 3 .. 826 Ctl
>and 98 .. 10370 BFIND
I found, that a MICROPOLIS 1303 has this Parameters:
5 heads
830 cylinders
17 sectors
I think you can use this, on my Commodore PC 60 it is drive type 27. You
can use the drive number even if it is not exact the drive you have. I
use a CDC WREN 94155-86 (925 cylinders, 9 heads ) as drive type 46 (1024
cylinders, 9 heads). At system start time I get a hard disk failure, but I
don't nedd CDCs DMDRVR.BIN ( needs 150k of system memory).
Reinhold Meyer
Abt. Forstliche Biometrie u. Informatik
Buesgenweg 5
D-3400 Goettingen
BITNET: U0018@DGOGWDG5
------------------------------
Date: 5 Feb 89 23:07:00 EST
From: <smedleyr@wpafb-info2.arpa>
Subject: Hard Disk Interleave
I have recently had the opportunity to reset my hard disk interleave
factor. I have an old NEC 20MB D3126 3.5 inch (about 80 ms access). The
following table applies:
Interleave Disk Index (from Norton SI)
2:1 2.3
3:1 1.9
4:1 1.6
6:1 1.3
The last line was the default value of my hard disk for the past three
years. I have run the system at 2:1 for the past month with no ill
effects.
Found similiar results on Seagate ST-251 and ST-8096.
There are a couple of packages that will allow you to change the
interleave without having to perform a low level format. The only one I
can remember off the top of my head is OPTUNE by Gazelle Systems (standard
disclaimer).
Mark Meaders
[Another one that I've used on 'clone' is ILEAVE.arc, available from the
archives here at Simtel20 in file: PD1:<MSDOS.DSKUTL>ILEAVE16.ARC (Version
I used was ILEAVE15...) gph]
------------------------------
Date: Tue, 7 Feb 1989 01:20 MST
From: Keith Petersen <w8sdz@WSMR-SIMTEL20.ARMY.MIL>
Subject: Important update to DSZ fixes bug
The latest version of DSZ, the x/y/zmodem protocol communications program,
is now available via stadnard anonymous FTP from Simtel20. This is a
"must get" if you are using the 0117 or 0202 version. It fixes a bug that
caused garbled file transfers under some conditions.
These files were obtained directly from Chuck Forsberg's BBS just a few
hours before this message was posted.
Filename Type Bytes CRC
Directory PD1:<MSDOS.ZMODEM>
DSZ0205X.ARC BINARY 46276 8F6AH <--EXE version
DSZ0206.ARC BINARY 81686 FAE0H <--COM version
--Keith Petersen
Maintainer of the CP/M & MSDOS archives at wsmr-simtel20.army.mil [26.0.0.74]
DDN: w8sdz@wsmr-simtel20.army.mil
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz
------------------------------
Date: Mon, 6 Feb 89 10:19:10 EST
From: "Nelson R. Pardee" <SASMAINT@SUVM.ACS.SYR.EDU>
Subject: I/O on an Epson Equity II
Peter DeFrisse writes about the I/O on an Epson Equity II, feeling it is
slow due to the Epson DMA. Two responses:
-the II is no longer sold. The II+ is a 286 machine.
-I have benchmarks for SAS/PC 6.02 on about 25 PC's, including the II. SAS
is sensitive to both CPU and disk speed. Time for a vanilla PC with a 65
ms drive was 22:30. The II with the RLL version of the same drive was
13:30. Another clone running at 8 mhz and a similar drive clocked in at
about 17. A Zenith 158 running at 8mhz(which I believe doesn't have DMA)
clocks in at 21.
All those numbers indicate the II has pretty standard performance for a 10
mhz machine.
I wonder if something else is wrong. For example, that's the behavior I'd
expect if the interleave on the hard drive were set too *low*. We have a
couple of II's and have been generally pleased.
--Nelson R. Pardee, Academic Computing Services, Syracuse University--
--215 Machinery Hall, Syracuse, NY USA 13244-1260 (315)443-4505 --
------------------------------
Date: Mon, 6 Feb 89 09:09 MST
From: GORDON_A%CUBLDR%VAXF.COLORADO.EDU@CUNYVM.CUNY.EDU
Subject: Waveform Editors for PC's
regarding waveform editors for PC's: you might try ASYST, which is quite
comprehensive. It has reasonably good graphics drivers as well as a
complete analysis pkg. It is programmed in a subset of FORTH. You can
reach them at 800-348-0033. It is somewhat costly but institutional
discounts (25%) are available.
Allen Gordon
Univ of Colorado
------------------------------
Date: Mon, 06 Feb 89 12:57:33 CST
From: David Benson <C09800DB%WUVMD.BITNET@UICVM.uic.edu>
Subject: Lotus 123 behaviour problem
> My mother is a physician in the Veteran's Administration hospital
>system, and has received from them a government-release version of Lotus
>1-2-3. This version has a special title-page which explains how it's not
>copy-protected, etc. .
It sounds like someone has used the Lotus Value Pack to take the copy
protection off the Lotus disk. I wonder if they have then made multiple
copies? I doubt Lotus would like that much
> Now a very odd thing has started happening. After about 5 minutes in
>Lotus (sometimes more, sometimes less), whatever one is doing, the screen
>suddenly goes blank, a message is posted in the middle saying the drivers'
>set file 123.SET can't be found (even though it has to have been loaded
>for Lotus to get this far), and when you try to advance beyond the message
>Lotus promptly quits.
Sounds as though the installation of the Value Pack copy protection
removal may have been mis-done. That would be easy since Lotus gives very
misleading documentation for it. If this is true, I am not sure there is
a recourse. (Has anyone elese had this problem?
[Sounds like your mother has a beef with Lotus since the version sold to
the Government should not have any sort of 'protection' built in...]
- Dave Benson BITNET:C09800DB@WUVMD
Associate Director (314) 889-5313
Educational Computing Services
Washington University
St. Louis, MO
Disclaimer: I don't work for Lotus. I am just another of the victims.
------------------------------
Date: Mon, 6-FEB-1989 22:47 +0100
From: "UP200::SCHARFE" <U0158%DGOGWDG5.BITNET@CUNYVM.CUNY.EDU>
Subject: millisecond timing on PC
Hello,
time measurements on a PC is a problem for us, to. We need a millisecond
timer for a physical experiment (MICHELSON Interferometer).
So I'm very interested, if anyone has a solution for this problem.
My suggestion is (on PC/AT): try the "cassette interupt" 15h. There are
two nice functions, which may be helpful.
INT 15 AH=83h EVENT WAIT
AL=0 set interval
ES:BX pointer to byte in callers memory
that will have the high order bit set as soon
as possible after the interval expires
CX,DX number of microseconds to elapse befor posting
AL=1 Cancel
AH=86h WAIT
CX,DX number of microseconds to elapse before return
to caller
(Source: IBM Technical Reference PC/AT, BIOS-Listing page 5-147)
But I'm not very happy with this solution, because on most PC's this
functions are not implemented correctly (as on our TANDON PCA). For short
times (e.g. below a few milliseconds) this method fails.
Now I'm looking forward to a better solution on timing problems at the IBM
PC.
BYE Walter
Universitaet Goettingen Walter Scharfe
II.Physikalisches Institut Bitnet: U0158@DGOGWDG5
Bunsenstrasse 7-9
D-3400 Goettingen
Federal Republic of Germany
------------------------------
Date: Mon, 6 Feb 89 09:02:44 CST
From: lantz@skvax1.csc.ti.com
Subject: More 4107 questions
I have had some response to my question about 4107 emulators and now I
have another question. Has anyone used the Grafpoint emulator with a high
resolution (1024 X 750 or greater) graphics board in a PC. I have
evaluated the package using standard EGA and would like to have some idea
how it performs at the higher resolutions. Also, if anyone has a
recommendation for a high resolution board, I would like their input.
Thanks
Bernie Lantz
------------------------------
Date: Sun, 5 Feb 89 18:07 EST
From: Richard Ohrbach <ORMOHRBH@ubvmsc.cc.buffalo.edu>
Subject: Re: Data acquisition for IBM PS2 model 80
Kumar--
I am not yet using the DT A/D board, but know of others who are using it
or similar boards for EMG data collection and analysis. A strong
recommendation has been made by them for the software Assyst (or Asyst, I
forget the spelling) by a company in Rochester, NY. They make two software
programs: Asyst, and Asystant; the latter is easier to use, the former
requires programming but provides for more flexibility. The programs are
compatible with a variety of A/Ds and preamplifiers.
If you are interested in more information on them, I can send you the
address and telephone number (I don't have it at home).
Richard Ohrbach
------------------------------
Date: Tue, 7 Feb 1989 02:04 MST
From: Keith Petersen <w8sdz@WSMR-SIMTEL20.ARMY.MIL>
Subject: SIMTEL20 index and CRC list files now available archived
The CRC lists and IDX files in Simtel20 top-level directories <CPM>,
<MSDOS> and <MISC> are now also available in archive format to save
downloading time.
Example:
Filename Type Bytes CRC
Directory PD1:<MSDOS>
MSDOSCRC.ARC BINARY 44844 B859H <--MSDOS.CRCLST
MSDOSIDX.ARC BINARY 59332 CAD5H <--FILES.IDX
The <MISC> and <CPM> filenames are:
MISC-CRC.ARC, MISC-IDX.ARC, CPM-CRC.ARC, CPM-IDX.ARC
--Keith Petersen
Maintainer of the CP/M & MSDOS archives at wsmr-simtel20.army.mil [26.0.0.74]
DDN: w8sdz@wsmr-simtel20.army.mil
Uucp: {ames,decwrl,harvard,rutgers,ucbvax,uunet}!wsmr-simtel20.army.mil!w8sdz
------------------------------
Date: Mon, 6 Feb 89 08:15 EDT
From: <P_GEREMI%UNHH.BITNET@MITVMA.MIT.EDU>
Subject: sound for ibm
I was just wondering if anyone knows of a digitizing/playback system
that can be used on the IBM. I would like to be able to digitize sound
and then play it back (to be used in batch files). I was looking for a
system which has good quality sound and does not use the speaker system on
the IBM. The IBM's sound capabilities are very limited and I was looking
for something which could reproduce sound and record sound like the Mac.
Any help would be Appreciated.
Peter P. Geremia
University of New Hampshire
IBM Student Representative
P_Geremi@UNHH
PS, When I try to sell IBM computers at the University Computer store, the
mac has the advantage because of the "NEAT" sound. If the IBM had the
sound the MAC would not have a chance!
------------------------------
Date: Mon, 6 Feb 89 02:54:02 est
From: Lawrence C Foard <lfoard%wpi.wpi.edu@RELAY.CS.NET>
Subject: vga pallete
Does any one know how to access the VGA pallete directly without using
BIOS? I need to be able to use pallete animation and the BIOS routines
take to long to change the pallete. By the way does any one know if VEGA
VGA has a 640X480 256 color mode, and if so how can it be accessed?
------------------------------
Date: TUE, 7 FEB 89 12:43:49 MEZ
From: Raymond Koluvek <R02RDK%DHHDESY3.BITNET@CUNYVM.CUNY.EDU>
Subject: X windows (server) for PC
I am looking for a distributor of PC Xsight (X windows for a pc) from
Locus Computing Corp in Europe, or simular procduct. We have a great
number of PC's and would like to try out the concept.
Thanks, Ray
Raymond D. Koluvek
(Deutsches Eletronen - Synchrotron, DESY)
Buggy
Mail : DESY - Dept. R2, Notkestrasse 85
D-2000 Hamburg 52, West Germany
Voice : +49-40-8998-2362
FAX : +49-40-8998-3282
Email : R02RDK@DHHDESY3.BITNET
------------------------------
End of Info-IBMPC Digest
************************
-------