Info-IBMPC@USC-ISIB.ARPA (Info-IBMPC Digest) (11/19/85)
Info-IBMPC Digest Monday, 18 November 1985 Volume 4 : Issue 132
This Week's Editor: Eliot Moore <Elmo@USC-ISIB.Arpa>
Today's Topics:
Late-Model 8088's
LIST60.ASM & GETMEM.PAS
EEL Subdirectory
FAX Machines
Olivetti Ink-Jet
Freeing Memory
Hardware Upgrade for Some Professional Graphics Controllers
ASMGEN SEQ files
EGA via C
IBM Dos 3.1 date rollover
PC-AT, XENIX, troff, and LaserWriter
Floating-Point Errors in MS Fortran (2 Messages)
Underflow Interrupts (2 Messages)
Today's Queries:
Tool Evaluation
XENIX and Epson Printers
Graphics Editor
Bernoulli Box Host Adapter Board
WORDSTAR
----------------------------------------------------------------------
Date: Mon 18 Nov 85 18:36:58-EST
From: Steve Berlin <BERLIN@MIT-XX.ARPA>
Subject: Late-Model 8088's
I have written a program that runs without problems on new PCs, that is,
those with 'new' 8088 chips. I have actually swapped chips in the same
machine and seen the program fail with the older chip only. The symptom,
of course, is that the machine hangs completely and needs to be rebooted.
The only difference that I know between the older and newer revs of the
processor is the old failure to guard SS after a move to it; my code
explicitly guards SS/SP in these cases.
The program is a fairly complex system, written in ASM and Lattice-C large
memory model; and incorporating a simple non-preemptive multi-tasking
package that I wrote, int_pkg, com_pkg, and lpt_pkg from the INFO-IBMPC
library, and a very simple clock interrupt handler that I wrote.
The failure always (recently, anyway) occurs in an UNLINK call to the
Lattice library; which calls DOS function 41 to unlink a file. I am
running DOS 3.1.
Any details on differences between the chips, or other ideas that might
lead to a resolution of this problem, would help save my sanity...
Steve Berlin
Berlin@mit-xx
-------
------------------------------
Date: Mon 18 Nov 85 22:53:24-EST
From: Steve Berlin <BERLIN@MIT-XX.ARPA>
Subject: Late-Model 8088's
To: INFO-IBMPC@USC-ISIB.ARPA
Regarding my earlier message about a program which works on late-model 8088s
only; I found the bug.
It turns out that Lattice, in their infinite wisdom, decided to implement the
int86 library routine (defined as "generate 8086 software interrupt") as
a CALL to the specified 'interrupt routine' instead of actually generating
an interrupt. Thus, when the routine in question, assuming it was already
running with IF clear, modifies SS....
Simplest fix: wrap a CLI/STI pair around the int86 call.
Or, re-write the int86 routine to generate a real interrupt (why, oh why,
did they write it as they did???)
-- Steve
-------
------------------------------
Date: 17 Nov 1985 21:30:32 PST
Subject: LIST60.ASM & GETMEM.PAS
From: Koji Okazaki <swg.KOJI@USC-ISIB.ARPA>
To: Info-IBMPC@USC-ISIB.ARPA
cc: Koji@USC-ISIB.ARPA
The following programs have been added to our library:
LIST60.ASM This handy hack, also called LIST, allows many
ways of displaying ASCII text files. It's good
to use when using an editor is overkill (I know
some people will disagree with that statement
but...) and TYPE is too lame!
<Peter Galvin, CC.GALVIN@R20.UTEXAS.EDU> 11/17/85
GETMEM.PAS A leetle teeny weeny demo program written in Turbo
Pascal that shows available memory by looking at
page 0 (the PSP, field 2) of the currently running
program, grabbing "size of memory" integer (16-byte
paragraph count). 'Tis useful as an instructional
sample for young Turbo Pascal hamsters.
<David Kirschbaum, ABN.ISCAMS@USC-ISID> 11/17/85
-------
------------------------------
Date: 18 Nov 1985 00:00:53 PST
Subject: EEL subdirectory created
From: Koji Okazaki <swg.KOJI@USC-ISIB.ARPA>
To: Info-IBMPC@USC-ISIB.ARPA
cc: Koji@USC-ISIB.ARPA
The subdirectory <INFO-IBMPC.EEL> has been created in anticipation of
many contributions of EEL code by Epsilon users for Epsilon users.
EEL This subdirectory serves as the home of orphan
(subdirectory) Epsilon EEL code. EEL code may be snarfed by
Epsilon owners only. Contributions are welcome.
Please refer to the file EELCODE.LIST in this
subdirectory to see brief descriptions of each
EEL program.
["EEL" stands for Epsilon Extension Language.]
<Billy Brackenridge, BRACKENRIDGE@USC-ISIB> 11/17/85
* Our first contribution, LISPMODE.E, written by Rob Pettengill
<CAD.PETTENGILL@MCC> makes Epsilon a nice environment for developing
Lisp applications.
** We usually don't create subdirectories in anticipation of contributions
but we decided to make an exception for Epsilon and EEL programs
because reports from Epsilon 3.0 beta-sites have been very encouraging.
- Koji
-------
------------------------------
Sender: "Allan H. Wax.OsbuSouth"@Xerox.ARPA
Date: 18 Nov 85 10:17:26 PST (Monday)
Subject: FAX Machines
From: Wax.OsbuSouth@Xerox.ARPA
To: MBJ@MIT-XX.Arpa
cc: INFO-IBMPC@USC-ISIB.Arpa, Wax.OsbuSouth@Xerox.ARPA
The Xerox 495 and 295 FAX machines area ll abale to be connected to a
PC at speeds up to 19.2K The will also function as a printer if you
just send ASCII to them.
Allan Wax
Wax.ES@Xerox.ARPA
Wax.OsbuSouth@Xerox.ARPA
------------------------------
Date: Monday, 18 November 1985 13:29:27 EST
From: Joe.Newcomer@a.sei.cmu.edu
To: info-ibmpc@usc-isib.arpa
Subject: Olivetti Ink-Jet
I bought one of these from DAK for $200 back in January when we acquired
our second PC and needed a second (and cheap) printer in a hurry.
Not impressive. It is quieter than a pin-style printer, but screeches
at a different (and I find annoying) frequency. The quality of the
output is marginal, to be charitable, and is sort of a smudgy brown
color. I never did get double-height printing to work. While I think
we got our $200 of use out of it, it was down for almost 2 months
because we couldn't get any replacement ink jet ampoules (it uses a
solid ink cartridge). I keep it as a backup in case one of our other
printers breaks, but I'd recommend looking at almost anything else,
even slightly higher in price, before compromising on this one. DAK
has another printer available, and I'd suggest checking out Radio
Shack as well (but be careful...most of their printers are not
control-sequence compatible with IBM and many features such as screen
print don't always work).
joe
------------------------------
Date: Mon 18 Nov 85 07:22:01-CST
From: Pete Galvin <CC.GALVIN@R20.UTEXAS.EDU>
Subject: Freeing Memory
To: info-ibmpc@R20.UTEXAS.EDU
See the STAYRES package in <info-ibmpc> for an example of going resident,
handling the invoking interrupt, cleaning up after the interrupt, and
clearing oneself our of memory. It's written in TURBO, but most
of the pertinent code is INLINE (machine language).
I'd have mailed you a copy, but our mail system can't figure out
where you're from... (although I could play with the address a little).
--Pete
-------
------------------------------
Date: 17 November 85 15:46-PST
From: Don Pelton (415) 854-3300 x2901 <DEP%SLACVM.BITNET@WISCVM.ARPA>
To: INFO-IBMPC@USC-ISIB.ARPA
Subject: Hardware Upgrade for some Professional Graphics Controllers
If you have bought, or plan to buy, IBM's Professional Graphics
Controller and Display, you may be interested in this. Several of us
who bought this board early this year discovered, through some
painstaking research, that there was a hardware bug on the board that
caused it to interfere with ANY terminal emulation program making use
of the asynch port. When we found that IBM acknowledged this bug and,
in fact, had a fix available, we requested them to accept the boards
back for service. IBM's reply was that we must return THE ENTIRE
SYSTEM! After some further struggle, we finally convinced them to take
the boards only, which they did, and returned them in due time with
the hardware upgrade applied. I felt at that time that, if the
problem should come up for anyone else, that we had a precedent for
how the service should be handled.
Thus, when Bob Kirby here discovered last week that he seemed to be
having the identical problem, I told him that all he would have to do
is call IBM and they would come out and pick up the board. What
happened, though, was that the IBM rep said Bob would have to bring
the entire system in because, he said, "that problem occured only with
the early boards and has since been fixed." We seemed to be back to
square one.
I then put the following question to IBM's ASKINFO database in Dallas
(the answer follows). I expect we can use this information to convince
IBM to give us the same deal we got when the problem came up the first
time. I hope this will be of use to anyone else who may experience the
problem.
End of Item:149VM Copyright IBM Corp 1983 Panel: Last of 1
Abstract: Serial numbers of flawed Professional Graphics
Controllers.
Q: We need to know the range of serial numbers for the
Professional Graphics Controllers containing the bug
relating to interference with asynchronous communications.
Or, if there is no serial number, some other marking
which will allow us to identify these boards.
=-=-=-=> 11/08/85 <=-=> 15:30:17 <=-=> DP/CPC146L <=-=-=-=
R: The old PGC cards have the numbers 6323697 and 6323698 on
the top left of the memory card. The new cards have these
two numbers inked out and the number 6448811 replaces them.
The two old numbers are not always inked out and if your
board has the 6448811 number , you have a new board.
=-=-=-=> 11/11/85 <=-=> 14:29:52 <=-=> BPW/NSC-DCS <=-=-=-=
------------------------------
Date: Mon 18 Nov 85 12:27:41-PST
From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA>
Subject: ASMGEN SEQ files
To: info-ibmpc@USC-ISIB.ARPA, abn.iscams@USC-ISID.ARPA
Phone: (714)961-3393; Mail:Beckman Instruments, Inc.
Mail-addr: 2500 Harbor Blvd., X-11, Fullerton CA 92634
... need to be terminated with EOF (control-Z).
Ted.
-------
------------------------------
Date: Mon, 18 Nov 85 13:36:52 EST
From: Kenneth E. Van_Camp (LCWSL) <kvancamp@Pica-Lca.ARPA>
To: LICHTENBERG.PA@xerox.arpa
cc: info-ibmpc@usc-isib.arpa
Subject: EGA via C
The Graphics Development Toolkit from IBM is the only package I know of
that supports the Enhanced Graphics Adapter using Lattice C.
------------------------------
From: ihnp4!scgvaxd!pelican!pete@ucbvax.berkeley.edu
Date: Mon, 18-Nov-85 09:02:41 PST
Subject: IBM Dos 3.1 date rollover
To: info-ibmpc@usc-isib.arpa
On seeing the note about 3.1 date rollover problems, I looked into
IBMBIO.COM with debug and found that the 2.1 date rollover fix was,
indeed, gone. In its place, all of the int 1a calls in the disk
drivers incremented the date if needed. That is all well and good
unless some other code is used which does int 1a calls (e.g. OEM
floppy drivers, etc.). These will not increment the date, but will
reset the indication of rollover. More ROM bios 'features'.....
--
Pete
...!{vortex, scgvaxd, ihnp4}!pelican!pete
------------------------------
From: bierma@nprdc.arpa (Larry Bierma)
Date: 18 November 1985 1236-PST (Monday)
To: laser-lovers@washington
Subject: PC-AT, XENIX, troff, and LaserWriter
Cc: info-unix@brl, info-ibmpc@isib
I am now successfully using the Apple LaserWriter as a printer for
the IBM PC-AT running IBM XENIX. The LaserWriter works as both
a VERY flexible line printer and as an excellent troff output
device.
Making it all work required porting the major parts of Adobe Systems
TranScript package and porting/rewriting the 4.1BSD line printer
spooling software to XENIX. Since the software is licensed material
I cannot make it available, but I would be willing to discuss what
the major problems/changes were.
--Larry ARPA: bierma@nprdc.arpa
UUCP: {decvax,ucbvax,ihnp4}!sdcsvax!sdcsla!nprdc!bierma
PSTN: (619) 225-2161
------------------------------
Date: Sun, 17 Nov 85 20:52:43 cst
From: cody@anl-mcs.ARPA (Jim Cody)
To: Info-IBMPC@USC-ISIB.ARPA
Subject: Floating-Point Errors in MS Fortran
The 8087 chip is an implementation of draft 8.0 of the IEEE Standard
754 for Binary Floating-Point Arithmetic. The "strange" number you
found with a "zero" exponent and a "mantissa" (we prefer the word
significand) of "1.5" is a denormalized number. The least exponent
for which the corresponding significand carries the implicit bit
corresponding to "1" is "1". Zero exponents are reserved for numbers
that have underflowed. Underflow is treated more humanely in IEEE 754
than you are probably used to. Instead of abruptly wiping the
significand out (flushing it to zero) when the exponent becomes to
small to represent, the exponent is pegged at 0 and the significand is
right-shifted as necessary, thus pushing one bit at a time over the
precipice. This procedure retains as much significance as the
circumstances warrant. Subsequent operations on denormalized numbers
may trigger exceptions, depending on what flags, etc. have been set.
All of this is discussed in a paper in IEEE Computer (March, 1981),
and in a second paper in IEEE Micro, (August, 1984). The latter
discusses a generalization of IEEE 754 that has been prepared by a
committee I chair.
With the 8087, you should be able to set the interrupt controls to
flush underflow to zero, in the old familiar way, if that is what you
want. Then your "problem" will disappear.
------------------------------
Date: Mon, 18 Nov 85 08:08:16 PST
From: USER=DMG%UBC.MAILNET@MIT-MULTICS.ARPA
To: INFO-IBMPC@USC-ISIB.ARPA,
steven@BRL-TBD.ARPA
Subject: Floating Point Error Control in MS Fortran
Steven Segletes <steven@BRL-TBD.ARPA> reports problems with
small reals in MS FORTRAN. The problem appears to be that the numbers
in question are in fact denormalised. To quote from Richard Statz's
"8087 Applications and Programming for the IBM PC and other PCs"
(Brady, 1983):
'Real numbers are usually stored in the normalized format... An
under- flow occurs when the result of an operation would require a
negative biased exponent. Rather than merely set the result to zero,
the 8087 "stretches" the precision of the result by setting the
exponent field equal to zero and shifting the significand right the
appropriate number of places. Thus denormal numbers can be
recognized, when stored in memory, by the zero exponent field together
with a non-zero significand field. ... Denormals are perfectly
acceptable as operands for arithmetic instructions. (With the critical
exception of transcendental operations which assume without checking
that operands are normals.)'
Hope this is of assistance,
Ivan D. Reid.
------------------------------
Date: Mon, 18 Nov 85 15:32:52 cst
From: cody@anl-mcs.ARPA (Jim Cody)
To: steven@brl.arpa
Subject: Underflow Interrupts Again
Cc: INFO-IBMPC@USC-ISIB.ARPA, cody@anl-mcs.ARPA
Now that I have had a chance to look at the manual and
play a bit, I suspect that your problem is more subtle than
you thought. I have Ver 3.20 of MS Fortran 77 running on an
XT with an 8087 chip. According to Appendix G of the manual,
the default for underflow is to mask off the interrupt and
return denormalized or zero results, depending on how small
the true exponent is. This is the friendliest response you
could want.
The following test program compiled and ran with the
results given.
DO 10 I = 74, 75
WRITE (*,*) ' '
J = -I
B = -1.*2.0**(J)
WRITE (9,*) ' B = ',B
C = B*B
WRITE (9,*) ' C = B*B = ',C
D = 1.0E10*C
WRITE (9,*) ' 1.0 * C = ',D
E = C/B
WRITE (9,*) ' C/B = ',E
E = C/C
WRITE (9,*) ' C/C = ',E
F = C+C
WRITE (9,*) ' C+C = ',F
10 CONTINUE
STOP
END
B = -5.293956E-023
C = B*B = 2.802597E-045
1.0 * C = 2.802597E-035
C/B = -5.293956E-023
C/C = 1.0000000
C+C = 5.605194E-045
B = -2.646978E-023
C = B*B = .0000000
1.0 * C = .0000000
C/B = .0000000
? Error: REAL Indefinite (unitialized or previous error)
Error Code 2136
P7 = 0D32: 009B; SS = 0E36, FP = F5C4, SP = F5BC
Note that the Error 2136 was not generated until the
program tried to compute 0/0. Replacing the operation C/B
with the operation B/C generated the expected division by zero
error, and specifically invoking 0/0 again generated Error 2136.
Thus, your problem appears to be associated with a 0/0 condition
which would persist regardless of how underflow were handled.
If you are still interested in the references, I have
lots of reprints of the article from Computer, and a limited
supply of those from Micro. I need a mail address, though.
Hope this helps.
Jim
------------------------------
Date: Mon, 18 Nov 85 21:10:24 EST
From: Steven Segletes <steven@BRL-TBD.ARPA>
To: Jim Cody <cody@ANL-MCS.ARPA>
cc: steven@BRL-TBD.ARPA, info-ibmpc@USC-ISIB.ARPA
Subject: Underflow Interrupts
My problem is indeed subtle, but I believe it is one of
multiplication, not zero by zero division. In my programs which bomb
out, the bomb out always results from a multiplication. I modified
your program to show my point. In it, I multiply a very small (but
representable) number by zero, which results in the REAL Indefinite
number to be generated. Such a number, if subsequently operated on,
bombs things out. If I understood your first letter correctly, a
number like 2.8E-45 is considered denormalized by virtue of the fact
that the binary exponent field is zero. It would thus seem that
numbers in the following ranges are considered as:
... > x > ~5.8E-39 is an OK number
~5.8E-39 > x > ~1.4E-45 is *always* a denormalized number
~1.4E-45 > x > ... is an underflow (results in either zero or
denormalized result depending on status masks)
If this is so, then it would seem that I am destined to have
difficulties if ever an arithmetic result falls in the range 5.8E-39
to 1.4E-45. I fear that this can not be avoided with MS Fortran V3.2.
If it is impossible to have a number in this mid-denormalized range be
flushed to zero, then this compiler (and others with similar
limitations) are next to useless for my application, where small
number round-offs probably happen thousands of times in any given run
of my program.
DO 10 I = 74, 75
WRITE (*,*) ' '
J = -I
B = -1.*2.0**(J)
WRITE (0,*) ' B = ',B
C = B*B
WRITE (0,*) ' C = B*B = ',C
d = 0. * c
write (0,*) ' D = 0*C = ',d
10 CONTINUE
STOP
END
B = -5.293956E-023
C = B*B = 2.802597E-045
D = 0*C = *#IND*********
B = -2.646978E-023
C = B*B = .0000000
D = 0*C = .0000000
Stop - Program terminated.
-Steve
------------------------------
Date: Mon, 18 Nov 85 10:23 CDT
From: Jerry_Baskette <baskette%ti-eg.csnet@CSNET-RELAY.ARPA>
To: info-ibmpc@usc-isib.arpa
cc: french%ti-eg.csnet@CSNET-RELAY.ARPA
Subject: Tool Evaluation
Folks:
I am involved in a tool evaluation for a Distributed Software Development
System. I am primarily interested in automated tools and tool sets that run
either on a VAX/VMS system or an IBM PC compatible.
Tools categories of main concern are the following:
Data Base
Project Management
1750A Architecture
Array Processor
Ada Compilers
Requirements Analysis
Design
Testing
Configuration Management
If you have any experiences with such tools, I would like to hear from you.
Please send me the tool name, system, distributor, and your opinion.
Please respond directly to me at: baskette%ti-eg@csnet-relay
Thank You,
Jerry Baskette
------------------------------
Date: 17 NOV 85 00:37-EST
From: PHYGONS%SUNYABVA.BITNET@WISCVM.ARPA
To: info-ibmpc@isib.ARPA
Subject: XENIX and Epson Printers
How does one get XENIX running on an IBM-PC-AT to drive an Epson FX-85
dot matrix printer. I have been unable to get output from the Text
Formatting System to print on the Epson. ASCII text prints OK, but
Escape sequences give garbage. I am not on the IBM-PC mailing list,
so I would appreciate receiving any suggestions at
PHYGONS@SUNYABVA.BITNET. Thanks!
------------------------------
Date: Mon, 18 Nov 85 0:46:21 EST
From: Dave Swindell <dswindel@BBN-LABS-B.ARPA>
To: info-ibmpc@usc-isib.ARPA
Subject: Graphics Editor
I am involved with the support of a large, mainframe-based, scientific
data management and analysis system called PROPHET. Our software
supports a large number of terminals, including the Tektronix 4010 and
4100 series. Although PROPHET supports a large number of graphical
applications which can be tailored by our users based on their needs,
several users have recently expressed interest in capturing PROPHET
graphics images on local PC's and performing additional editing using
PC-based software.
Many of our users have IBM PC's and are using programs such as PCPLOT
III to communicate with PROPHET as a 4010, and we ourselves have
looked at TGRAF-07 from Graphpoint which allows a PC to emulate a Tek
4107. We have also developed tools which convert PROPHET graphical
displays into Hewlett-Packard 7475A compatible plot files which can be
downloaded and plotted locally.
My question is this: is anyone aware of graphics software for the IBM
PC which allows images to be captured or downloaded from a host system
and manipulated locally? Examples of thee kinds of editing our users
are interested in include adding additional annotation to PROPHET
graphs and molecular displays as well as merging PROPHET displays into
documents generated on their PCs. We already support tools which
allow tabular data to be exchanged in DIF, SYLK, dBASE, and ASCII
format, and are aware of programs such as ChartMaster and BPS
Graphics. What we are interested in are "MacPaint" style programs
which can use as input a captured screen image from a graphics terminal
emulator or a downloaded HP plot file. Any references, thoughts,
observations, or condolences would be appreciated!
Thanks,
Dave Swindell
BBN Laboratories Incorporated
10 Moulton Street
Cambridge, MA 02238
ARPA: dswindell@bbn
Phone: (617)-497-3395
------------------------------
Date: Mon, 18 Nov 85 18:32:29 PST
From: Dave Flamm <flamm@AEROSPACE.ARPA>
To: info-ibmpc@usc-isib
Subject: Bernoulli Box Host Adapter Board
Has anyone deduced what the various ports on the B-Box host adapter
board do? I have some manuals for the drives, but Iomega refuses to
give out technical information on the adapter bod.
Thanks in advance.
Dave Flamm
------------------------------
Date: Mon 18 Nov 85 07:45:47-PST
From: CRESWELL@SRI-AI.ARPA
Subject: WORDSTAR
To: INFO-IBMPC@USC-ISIB.ARPA
cc: Creswell@SRI-AI.ARPA
We are considering purchasing additional Wordstar software..anyone
have comments/opinions about Wordstar 3.3 vs Wordstar 2000????
-------
------------------------------
End of Info-IBMPC Digest
************************
-------