Info-IBMPC@WSMR-SIMTEL20.ARMY.MIL (06/04/89)
Info-IBMPC Digest Sun, 4 Jun 89 Volume 89 : Issue 57
Today's Editor:
Gregory Hicks - Chinhae Korea <COMFLEACT@Taegu-EMH1.army.mil>
Today's Topics:
A slow pc, What's wrong with it?
Technical Book for Video Adapters wanted
Calendar Program Request
Rounding (2 msgs)
HELP with IBM==>MAC data transfer
Hercules and mouse problems.
Integer -> double conversion problems
Leading edge clock/cal
Lotus WKS Format
Memory board problems
PCED (Professional Command EDitor) source
Response to RE:CADKEY
Problems with double->int conversion with Microsoft C
SIMTEL20 tapes available from DECUS
SmartDrive question
Turbo-C: GEM bindings? Accessories?
Zenith key-click
Info-IBMPC Lending Library is available from: Bitnet via server at CCUC;
and from WSMR-Simtel20.army.mil (see file PD1:<msdos>files.idx for listing
of source files)
WSMR-Simtel20.army.mil can be accessed using LISTSERV commands from BITNET
via LISTSERV@RPIECS.BITNET and in Europe from EARN TRICKLE servers as
listed: (send commands to TRICKLE@<host-name> eg: TRICKLE@AWIWUW11)
AWIWUW11 (Austria), BANUFS11 (Belgium), DKTC11 (Denmark), DB0FUB11
(Germany), IMIPOLI (Italy), EB0UB011 (Spain) and TREARN (Turkey)
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>
----------------------------------------------------------------------
Date: Mon, 22 May 89 23:51 EDT
From: <S0703PDB%SEMASSU.BITNET@CUNYVM.CUNY.EDU>
Subject: A slow pc, What's wrong with it?
>I have one of those unidentified clones, entitled with this uninformative
>AGC sign. I'm not too happy with its performance. Norton's CI computation
>index is 1.0, Disk Index (DI) - .4, and Performance Index - .8.
The numbers you're giving sound an awful lot like a straight 8088
running at 4.77 Mhz. I've got a machine with the exact same BIOS (a Whole
Earth Electronics clone machine) and have had absolutely no problems with
it at all. I had them install an NEC V20 in place of the 8088, that
effectively doubles the speed for the cost of about a $12 chip. As for
performance, in non-turbo mode I've managed to squeeze about a 2.1 on the
Norton Speed index, and in turbo (10 Mhz) I can get 4.2 You might
consider the V20, and have your machine checked to see if it is really
going into turbo mode or is just staying in non-turbo. Hope this helps a
bit.
Paul Bienvenue
S0703PDB@SEMASSU.BITNET
------------------------------
Date: Wed, 24 May 89 11:57:05 MEZ
From: Erich Neuwirth <A4422DAB%AWIUNI11.BITNET@CUNYVM.CUNY.EDU>
Subject: Technical Book for Video Adapters wanted
Can anybody give me a reference to a good book about all Video adapters
(up to VGA) with all the technical details about registers and so on.
Thanks
Erich Neuwirth
------------------------------
Date: Tue, 23 May 89 09:30:09 PDT
From: Don Reynolds <reynolds@prandtl.nas.nasa.gov>
Subject: Calendar Program Request
I've never found one of these programs I like in every way, but I use one
by Mark Harris:
Ample Notice from
Granny's Old-Fashioned Software (tm)
Rt. 4, Box 216
Boone, NC 28607
Phone (704)264-6906. I have version 1.22 dated July 1988. It is
shareware, with a $10. charge for the diskette or a $30. charge for
registration (gets you the diskette, a printed manual, a free update for a
future version of "AN", telephone support, and a "reasonable likelihood
that features you request will be added to the package if such features
are deemed practical and of sufficiently general interest." [Sounds
pretty fair to me. DRR]
Best,
Don
------------------------------
Date: Mon, 22 May 89 08:58:45 PDT
From: madler@Hamlet.Bitnet (Mark Adler)
Subject: Rounding
In response to "Problems with double->int conversion with Microsoft C":
It's not a problem with the conversion. If you printed out 'd' to full
precision, you find that its value is not 1000, but 999.99999999999999 (or
some similar value < 1000). The integer conversion is then doing exactly
what is advertised, which is truncating the fraction and giving you 999.
The reason d < 1000 is that there is no exact representation of 0.1 in
binary---it is a repeating fraction just like 1/3 is in decimal. The
result of 100.0 / 0.1 is then not exactly 1000.
The solution is to round the double to an int, rather than truncate the
fraction. To round, you just add 0.5 before truncating the fraction. I
would recommend using floor() to do the rounding, since what it does to
negative numbers is specified in the ANSI C standard, but what double to
int conversion does to negative numbers is not specified. floor(d)
returns a double that is the largest integer less than or equal to d. So,
one way to round and convert to integer is: "(int) floor(0.5 + d)". This
will give the expected result for positive or negative numbers. Assuming,
of course, that the value fits into the int type.
Mark Adler
bitnet: madler@hamlet
arpa: madler@hamlet.caltech.edu
------------------------------
Date: Tue, 23 May 89 10:12:14 PDT
From: madler@CitRomeo.Bitnet (Mark Adler)
Subject: Rounding
In response to:
>> This is just a note on the problem about integer to double conversion
>> that I posted to the net some time ago.
[Text and program deleted...]
You're right. Something is a bit odd here. What's happening is that when
the compiler computes (int) 100.0 / 0.1, it gets 999, but when 100.0 / 0.1
gets stored by the compiler in a double, it ends up being exactly 1000.0.
Now that I see the behavior, I see why.
Floating point calculations are done using an 80 bit format, either inside
the 80x87, or in the 80x87 emulation code. So when 100.0 / 0.1 is
computed in the 80x87, the result is a little less than 1000.0. Then, if
the value is stored in a 64 bit format, the result is rounded to exactly
1000.0. However, if instead the result is truncated to an integer while
still in the 80x87 (or the "virtual" 80x87 in emulation), the result is
999, since it hasn't been rounded.
The reason the two different programs get different results, is that the
optimizing compiler decides it can do the computation at compile time for
one of the programs, but not the other. The compile time calculation
gives 999 for j, but the run time calculation uses the stored 64 bit value
of d, and so gets 1000 for j.
Is this a bug? Well, sort of. The moral is that conversions like this
can be quite dependent on implementation details of the compiler, the
floating point hardware or software, and whether results go through other
implicit comversions (like the 80 to 64 bit conversion). To be safe, you
should round results that are converted from double or float to int or
long. Anything else is asking for trouble. As for if this is a bug: it
is not a bug in the run time double to int conversion. It is a bug in the
logic of the optimizing compiler, since it does not produce the same
results for the two programs. However, I would not consider it a bug if
the compiler gave either j=999 or j=1000 for BOTH programs.
The way I recommend to round in C is "floor(0.5 + ...)" where ... is a
double or float expression. The result of float() is a double that you
can then convert into an int or long if the value is in range. The reason
to use floor() before the type conversion is that the behavior of type
conversion on negative numbers is not specified, but the behavior of
floor() is. Also, adding 0.5 to round something is not a "trick". I have
nothing against tricks; it's just that this doesn't happen to be one. It
is the proper algorithm to round a real number to the nearest integer.
Mark Adler
bitnet: madler@hamlet
arpa: madler@hamlet.caltech.edu
------------------------------
Date: Thu, 25 May 89 12:47:37 EDT
From: formtek!pen@uunet.UU.NET (Philip E. Nickerson, Jr.)
Subject: HELP with IBM==>MAC data transfer
My father has a Macintosh at home (ok, now I've lost 3/4 of you), but
consults with companies using IBM PC machines and clones. His problem is
that he wants to edit files on his MAC and put them on the PC. The origin
of the files may be from any of the various floppy formats on the PC or
they may originate from the MAC. (MS Word on the MAC allows him to save
the files as TEXT files, so there shouldn't be data compatability
problems.)
Here is the dilemma. I have found several products which hook directly to
the MAC which read and write text files from IBM disks, but in order to
read and write all of the IBM formats, two of these would be required
(each one has two drives which handle only one format.) The cost of this
would be much greater than the price of an inexpensive clone. But, all of
the clones come with a drive already in the package, which only reads one
format, so it would have to be trashed and other drives would have to be
purchased. Again, the cost soars.
Does anyone know of an inexpensive clone which comes with either one drive
which reads all of the 5-1/4" formats plus a drive for the 3.5" format, or
one of either of these so we can add the other, or are we destined to
throwing a lot of money at this problem.
I am not an IBM PC user, so I do not know where to go for information, so
I hope you all can help me.
PLEASE E-MAIL REPLIES TO PEN@FORMTEK.UUCP.
If you know of prices/addresses of good places to purchase the equipment,
please include this information also.
Thanx in advance!
-Phil
Philip E. Nickerson,Jr. |UUCP {pitt,psuvax1}!idis!formtek!pen
(412)937-4900|(800)FORMTEK| decvax!formtek!pen
"Programming is simply |Snail Formative Technologies, Inc.,
debugging a blank page! | Foster Plaza VII
| 661 Andersen Dr., Pittsburgh PA 15220
------------------------------
Date: Mon, 22 May 89 08:30:01 PDT
From: bmarsh@cod.nosc.mil (William C. Marsh)
Subject: Hercules and mouse problems.
Well, I am also trying to get a mouse to work with a Hercules graphics
card, but my problem has a little twist: The stated method *ONLY* works
if you *don't* have a color card installed! Otherwise the mouse driver
thinks you have the color card in graphics mode!
Does anybody have any idea about how to get this combination to work? I
think I'll have to draw the cursor myself, but I didn't want to emulate
the entire mouse driver...
Thanks in advance,
Bill Marsh, Naval Ocean Systems Center, San Diego, CA
{arpa,mil}net: bmarsh@cod.nosc.mil
uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!nosc!bmarsh
"If everything seems to be coming your way, you're probably in the wrong lane."
------------------------------
Date: Tue, 23 MAY 89 12:18 N
From: CAVECCHIA%ITNVAX.CINECA.IT%ICINECA2.BITNET@CUNYVM.CUNY.EDU
Subject: Integer -> double conversion problems
This is just a note on the problem about integer to double conversion that
I posted to the net some time ago.
I know that a conversion of this kind implies rounding errors that can be
avoided using some tricks like adding 0.5 to the double before converting
and so on.
What give me the suspect that this could be a bug of the Microsoft v5.1 C
compiler are the following considerations:
1) I compiled and ran the program both on a Vax with VMS and on a Sun, and
obtained the correct (aspected) results, i.e. i=1000, d=1000.00000 and
j=1000.
2) I don't understand why "j" (and not "i") give the correct result (1000)
in the first version of the program.
3) I've looked inside the assembly code produced by the compiler, the
value 999 is not the result of a run time computation, it is computed by
the compiler and assigned to the variable i with the following statement
; Line 5
*** 000009 c7 46 f6 e7 03 mov WORD PTR [bp-10],999 ;i
;|*** d = 100.0 / 0.1;
4) I've written a simple variation of the program (see program 2). I have
simply exchanged two lines and obtained different results.
main() /* program 1 */
{
short int i,j;
double d;
i = 100.0 / 0.1;
d = 100.0 / 0.1;
printf("i = %d\n",i); /* i = 999 (!) */
printf("d = %lf\n",d); /* d = 1000.000000 */
j = d;
printf("j = %d\n",j); /* j = 1000 (!) */
}
main() /* program 2 */
{
short int i,j;
double d;
i = 100.0 / 0.1;
d = 100.0 / 0.1;
j = d;
printf("i = %d\n",i); /* i = 999 (!) */
printf("d = %lf\n",d); /* d = 1000.000000 */
printf("j = %d\n",j); /* j = 999 (!!!) */
}
Thanks to all for any help and suggestion about this problem.
Valter V. Cavecchia | cavecchia@itncisca.bitnet
Centro di Fisica del C.N.R. | itnvax::cavecchia (DECnet, 37.65)
I-38050 Povo (TN) - Italy
------------------------------
Date: Tue, 23 May 89 08:56 CDT
From: Lee Miller <L_MILLER@nuacc.acns.nwu.edu>
Subject: Leading edge clock/cal
> IBM DOS 3.2 cannot find the Leading Edge's clock or calendar.
I don't have the leading edge, but I recently bought a clock/cal card from
a noname electronics supplier, which worked properly with the software
which was included, but not with standard AST type routines. I
unassembled their code, and it turned out there were a couple of
differences which you might try. The standard AST card has a latch in
front of the motorola chip, so that it appears at a single address. You
write a byte, x to the port, then read from the same port, and it returns
the value of the register x. Without the latch, you simply read from the
register at the base address plus x, which was the case with my card. The
other difference was that the base address was 240h rather than the normal
2C0h. I don't know why that was different (I'd be interested if anyone
else does) but you might try that as well.
Lee Miller
L_Miller @ NUACC.bitnet
------------------------------
Date: Thu, 25 May 89 12:27:59 -0400 (EDT)
From: Brian Patrick Arnold <ba0k+@andrew.cmu.edu>
Subject: Lotus WKS Format
We are developing an application to convert "spreadsheet-like" information
into the IBM Lotus 123 "WKS" format, or optionally into a Lotus-importable
format. We need to know where to find published information on this
format or on a compatible format. If anyone has tips or suggestions as to
finding this information, we would appreciate any help you can give.
Thank you.
- Brian
------------------------------
Date: Mon, 22 May 89 10:31 EST
From: <ROSSB%IUBACS.BITNET@UICVM.uic.edu>
Subject: Memory board problems
Greetings.
I'm hoping someone out there more knowledgeable about hardware may be
able to suggest the proper (best) course of action for a problem with a
memory board. We've a 1.5 meg Rampage AT running on an IBM AT, both about
2 and a half years old. Recently one of my software packages (SPSS/PC)
--and no other--has been crashing if I go to the ramdisk and start up the
program (after setting the parameter SET SPSS=C:\SPSS) If I run chkdsk on
the ramdisk after running SPSS/PC I get the "lost clusters" message.
Starting up from the harddisk does not invoke the problem. I ran the
software program RAMTEST and:
(1) with only the REMM.SYS driver loaded I get no errors in expanded memory
(2) with the REMM.SYS driver plus software for a ramdisk load I get
the message "parity error in 3rd 512 bank related to parity chip"
I figure there is a problem with the memory board but don't exactly know
what to do (aside from taking the unit to someone or sending the board
back to AST to check). So I'm wondering (1) will the problem get worse if
I just sit on it (2) is this maybe some simple problem that I can rectify
myself (like, disabling parity--but with what consequence)?
Thanks ahead for any advice. Bev Ross; BITNET: ROSSB@IUBACS
------------------------------
Date: Tue, 23 May 89 09:34:02 PDT
From: Don Reynolds <reynolds@prandtl.nas.nasa.gov>
Subject: PCED (Professional Command EDitor) source
Chris Dunford, the author of CED and PCED, can be reached at
Cove Software
10057-2 Windstream Drive
Columbia, MD 21044
His phone is (301)992-9371 per my latest records. I believe the price of
PCED is $47.00 (US).
Best,
Don
------------------------------
Date: Mon, 22 May 89 13:07 EDT
From: <HGOLDSTE%UDCVAX.BITNET@CORNELLC.cit.cornell.edu>
Subject: Response to RE: CADKEY
i have no connection with COMPUSERVE ... in fact i have, unfortunately
never used COMPUSERVE ... i will get around to it one day ... anyway we
are (at the University of the District of Columbia ... thats UDC) a CADKEY
Training Center and i have a fair amount of contact with CADKEY, the
company, because of that ... anyway that is how i know of the users group
they have on compuserve ....
as far as the small library of patterns we (thats UDC) have he can respond
to me directly ... i tried to GMAIL to the user directly but was
unsuccessful.
thanks much ...
by the way did you notice my note about the problem with SIMIBM.ARC ...
there are 4 errors in the index file that screws up the basic program.
[Not only did we notice it, but it's also being fixed.]
harold Goldstein
------------------------------
Date: Wed, 24 May 89 11:03 EDT
From: Carl <GRECO@Ruby.VCU.EDU>
Subject: Problems with double->int conversion with Microsoft C
In the Info-IBMPC Digest V89 #53, a "problem" converting from double to
short integer using Microsoft C was described.
This is due to the inability of the finite word length computer to exactly
represent all floating point numbers, either as floats or doubles. There
are several methods for representation of floating point numbers; the most
common being the IEEE standard. The conversion from a floating point to
an integer in the sample program was performed by truncation, i.e.,
i = 100.0/0.1;
where i was declared a short int.
In order to obtain the "expected" result it is necessary to round instead
of truncate. The following macro can be used for this purpose.
#define round(x) (int) ((x)+(((x)>0)?.5:-.5))
and
i = round(100.0/0.1);
------------------------------
Date: Wed, 24 May 1989 16:39 MDT
From: Ted Nieland - SRL <TNIELAND%FALCON@AAMRL.AF.MIL>
Subject: SIMTEL20 tapes available from DECUS
The SIMTEL20 MSDOS, ADA, and UNIX-C collections have been submitted to the
DECUS Library. They have been assigned part numbers as listed below.
The MS-DOS collection was broken into two pieces (it would not fit on a
single TK50 tape).
Here are the part numbers:
SIMTEL20 Unix-C Collection VMS BACKUP Format............V-SP-88
SIMTEL20 Unix-C Collection TAR Format...................U-SP-105
SIMTEL20 MSDOS Collection Part 1 VMS BACKUP Format......V-SP-89
SIMTEL20 MSDOS Collection Part 2 VMS BACKUP Format......V-SP-90
SIMTEL20 ADA Collection VMS BACKUP Format...............V-SP-91
I will be attempting to update these collections in the DECUS Library
every six months or so. I will be FTPing all files that changed and
removing the superseded files to get a current copy of the archive,
without having to get the entire archive again.
The address and phone number for the DECUS Library is:
The DECUS Program Library
219 Boston Post Road BP02
Marlboro, MA 01752-1850
Phone: 508 480-3418
Ted
M. Edward (Ted) Nieland - Systems Analyst
| US Snail: | Arpa Internet: |
| Systems Research Laboratories, Inc. | TNIELAND@WPAFB-AAMRL.ARPA |
| 2800 Indian Ripple Road WP 196 | TNIELAND%FALCON@WPAFB-AAMRL.ARPA |
| Dayton, OH 45440 | |
| A T & T: (513) 255-8846/8760/5165 |
------------------------------
Date: Mon, 22 May 89 08:58:19 CDT
From: moore@ncsc.navy.mil (Moore)
Subject: SmartDrive question
The documentation that comes with Windows 2.11/286 states that, when you
use the disk caching driver Microsoft provides (SmartDrive), you should
set your buffers to 20. This seems redundant: if you're using a disk
cache, shouldn't you be able to reduce the buffers to (virtually) 0, since
the device driver is already doing caching?
Thanks for any assistance.
Jim
moore@NCSC.navy.mil
------------------------------
Date: 23 May 89 12:15:53 GMT
From: hafer@infbs (Udo Hafermann)
Subject: Turbo-C: GEM bindings? Accessories?
Can anyone provide me with a pointer to GEM bindings for Borland's Turbo
packages, and for information on how to write Desk Accessories? Please
mail - I'm not a regular reader of this group.
------------------------------
Date: Wed, 24 May 89 10:05:23 CDT
From: steve@ncsc.navy.mil (Mahan)
Subject: Zenith key-click
In response to the query for software for disabling the keyclick on the
Zenith Z-248 machine I have come up with an alternate solution.
It is a fairly simple matter to disconnect the keyboard speaker
permanently. Simply turn over the keyboard, remove the four Philips head
screws securing the steel bottom, and remove the bottom. You will see the
circuit board exposed. Near the 40 pin DIP (there's only one) locate 2
large through holes with the label SP printed near them. Simply cut one
of the traces leading to one of these through holes. Be careful. DO NOT
cut a trace if you are not sure.
To verify that you have found the correct trace remove the 6 Philips
head screws securing the circuit board on each end of the case (3 ea) and
lift up the circuit board. The speaker is the small silver cylinder near
the back center of the board. Reinsert the six screws securing the circuit
board, remembering to reattach the stainless steel strip on the cable side
of the board. Replace the bottom and resecure with the four remaining
screws
This should not take more than 5-10 minutes per board after the first
one. I am typing this on a modified Z-248 keyboard.
WARNING: this will void your warranty on the keyboard. This worked
for me but I cannot claim responsibility for results obtained by any other
person.
Stephen Mahan
Code 5330
Naval Coastal Systems Center
Panama City, FL 32408-5000
(904) 234-4224
ARPA: steve@ncsc.navy.mil
------------------------------
Date: Wed, 24 May 89 13:13:15 CDT
From: FRITZ KEINERT <@CCVAX.IASTATE.EDU:S1.FXK@ISUMVS.BITNET>
Subject: Re: floating point problem in Microsoft C
In digest #53, Cavecchia asks why the lines
i = 100.0 / 0.1;
printf("i = %d\n",i);
in Microsoft C produce the output
i = 999
My guess is that it is simply a round-off problem which has nothing to do
with your particular language. I always spend some time discussing this
sort of stuff when I teach numerical analysis.
As everyone knows, 1/3 = 0.333333... in base 10, so any base 10 calculator
will produce (1/3)*3 = 0.99999999... Typically, there are extra internal
digits, so you don't see that, but it happens.
Likewise, on binary computers, the number 0.1 cannot be represented
exactly. It comes out as 0.000 1100 1100 1100 1100 ... If you store it as
an IEEE standard single precision floating point number, it is cut off
right before one of those 1100 groups and therefore rounded up, so it
comes out as 0.000 1100 .... 1101. The value in base 10 is about
0.10000000149116... The number 100.0 is represented exactly, like all
integers up to 7 or 8 decimal digits.
Therefore, when you calculate 100. / 0.1, you really are calculating 100.0
/ 1.0000000149..., which is more like 999.99999999... By the usual
conversion rules, the conversion real->integer is done by truncating, so
you get your i = 999.
I don't know of any general way to avoid this problem. I have resorted to
constructions like
i = 100.0 / 0.1 + eps
in the past, where eps is a number near the machine epsilon (typically
around 1.e-7 for single precision, 1.e-14 for double precision), when I
suspected similar problems.
Fritz Keinert
S1.FXK@ISUMVS
------------------------------
Date: Wed, 24 May 89 14:33:33 SET
From: Rainer Kleinrensing <RAINER%DBNUAMA1.BITNET@CUNYVM.CUNY.EDU>
Subject: No name clone ans OS/2
Hello,
a friend of mine, who has currently no access to netland, has asked me to
submit the following problem to INFO-IBMPC:
My friend recently bought the following hardware:
- no-name 25Mhz 386 (Chips&Technologies Chips) with 4MB on board,
expandable to 8MB
- Hercules video card
- Seagate ST01 SCSI Host adaptor
- Seagate ST296N 83 MB SCSI hard drive
- WD 1002 A FOX Floppy controller
- 1.2MB Chinon floppy drive.
This machine works fine under DOS. However, when trying to boot the IBM
OS2 1.0 Extended Edition Installation disk, it doesn't boot, but
instantaneously displays 'A disk read error occured'. This message can be
found in the boot sector of the OS2 installation disk. You see no IBM logo
etc., the floppy drive simply reads the first track and you see the
message. After that, the machine hangs. The same is true for IBM OS2
extended edition 1.1 and the MS OS2 1.1 development toolkit. However, if
you physically remove the SCSI host adaptor, the installation disks boot
fine (with the exception that you then have no hard disk to install OS2
on). When you put in a 'normal' AT-style hard disk controller and hard
disk, OS2 installs fine and also boots from the hard disk. (Note that
manually writing a boot sector to the SCSI drive also doesn't work.)
His conclusion is that OS2 doesn't work with a SCSI drive or controller.
The question: has anyone tried to install OS2 on such a machine with SCSI
drive(s) ?
Is there a patch available either from MS or IBM that allows OS2 to
operate on SCSI drives ?
Any hint in that direction (even reports that it works/doesn't work on
other machines) would be greatly appreciated.
Please reply directly to me, I'll summarize to the net.
Rainer Kleinrensing (RAINER at DBNUAMA1.BITNET)
------------------------------
End of Info-IBMPC Digest
************************
-------Info-IBMPC@WSMR-SIMTEL20.ARMY.MIL (07/22/89)
Info-IBMPC Digest Sun, 4 Jun 89 Volume 89 : Issue 57
Today's Editor:
Gregory Hicks - Chinhae Korea <COMFLEACT@Taegu-EMH1.army.mil>
Today's Topics:
A slow pc, What's wrong with it?
Technical Book for Video Adapters wanted
Calendar Program Request
Rounding (2 msgs)
HELP with IBM==>MAC data transfer
Hercules and mouse problems.
Integer -> double conversion problems
Leading edge clock/cal
Lotus WKS Format
Memory board problems
PCED (Professional Command EDitor) source
Response to RE:CADKEY
Problems with double->int conversion with Microsoft C
SIMTEL20 tapes available from DECUS
SmartDrive question
Turbo-C: GEM bindings? Accessories?
Zenith key-click
Info-IBMPC Lending Library is available from: Bitnet via server at CCUC;
and from WSMR-Simtel20.army.mil (see file PD1:<msdos>files.idx for listing
of source files)
WSMR-Simtel20.army.mil can be accessed using LISTSERV commands from BITNET
via LISTSERV@RPIECS.BITNET and in Europe from EARN TRICKLE servers as
listed: (send commands to TRICKLE@<host-name> eg: TRICKLE@AWIWUW11)
AWIWUW11 (Austria), BANUFS11 (Belgium), DKTC11 (Denmark), DB0FUB11
(Germany), IMIPOLI (Italy), EB0UB011 (Spain) and TREARN (Turkey)
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>
----------------------------------------------------------------------
Date: Mon, 22 May 89 23:51 EDT
From: <S0703PDB%SEMASSU.BITNET@CUNYVM.CUNY.EDU>
Subject: A slow pc, What's wrong with it?
>I have one of those unidentified clones, entitled with this uninformative
>AGC sign. I'm not too happy with its performance. Norton's CI computation
>index is 1.0, Disk Index (DI) - .4, and Performance Index - .8.
The numbers you're giving sound an awful lot like a straight 8088
running at 4.77 Mhz. I've got a machine with the exact same BIOS (a Whole
Earth Electronics clone machine) and have had absolutely no problems with
it at all. I had them install an NEC V20 in place of the 8088, that
effectively doubles the speed for the cost of about a $12 chip. As for
performance, in non-turbo mode I've managed to squeeze about a 2.1 on the
Norton Speed index, and in turbo (10 Mhz) I can get 4.2 You might
consider the V20, and have your machine checked to see if it is really
going into turbo mode or is just staying in non-turbo. Hope this helps a
bit.
Paul Bienvenue
S0703PDB@SEMASSU.BITNET
------------------------------
Date: Wed, 24 May 89 11:57:05 MEZ
From: Erich Neuwirth <A4422DAB%AWIUNI11.BITNET@CUNYVM.CUNY.EDU>
Subject: Technical Book for Video Adapters wanted
Can anybody give me a reference to a good book about all Video adapters
(up to VGA) with all the technical details about registers and so on.
Thanks
Erich Neuwirth
------------------------------
Date: Tue, 23 May 89 09:30:09 PDT
From: Don Reynolds <reynolds@prandtl.nas.nasa.gov>
Subject: Calendar Program Request
I've never found one of these programs I like in every way, but I use one
by Mark Harris:
Ample Notice from
Granny's Old-Fashioned Software (tm)
Rt. 4, Box 216
Boone, NC 28607
Phone (704)264-6906. I have version 1.22 dated July 1988. It is
shareware, with a $10. charge for the diskette or a $30. charge for
registration (gets you the diskette, a printed manual, a free update for a
future version of "AN", telephone support, and a "reasonable likelihood
that features you request will be added to the package if such features
are deemed practical and of sufficiently general interest." [Sounds
pretty fair to me. DRR]
Best,
Don
------------------------------
Date: Mon, 22 May 89 08:58:45 PDT
From: madler@Hamlet.Bitnet (Mark Adler)
Subject: Rounding
In response to "Problems with double->int conversion with Microsoft C":
It's not a problem with the conversion. If you printed out 'd' to full
precision, you find that its value is not 1000, but 999.99999999999999 (or
some similar value < 1000). The integer conversion is then doing exactly
what is advertised, which is truncating the fraction and giving you 999.
The reason d < 1000 is that there is no exact representation of 0.1 in
binary---it is a repeating fraction just like 1/3 is in decimal. The
result of 100.0 / 0.1 is then not exactly 1000.
The solution is to round the double to an int, rather than truncate the
fraction. To round, you just add 0.5 before truncating the fraction. I
would recommend using floor() to do the rounding, since what it does to
negative numbers is specified in the ANSI C standard, but what double to
int conversion does to negative numbers is not specified. floor(d)
returns a double that is the largest integer less than or equal to d. So,
one way to round and convert to integer is: "(int) floor(0.5 + d)". This
will give the expected result for positive or negative numbers. Assuming,
of course, that the value fits into the int type.
Mark Adler
bitnet: madler@hamlet
arpa: madler@hamlet.caltech.edu
------------------------------
Date: Tue, 23 May 89 10:12:14 PDT
From: madler@CitRomeo.Bitnet (Mark Adler)
Subject: Rounding
In response to:
>> This is just a note on the problem about integer to double conversion
>> that I posted to the net some time ago.
[Text and program deleted...]
You're right. Something is a bit odd here. What's happening is that when
the compiler computes (int) 100.0 / 0.1, it gets 999, but when 100.0 / 0.1
gets stored by the compiler in a double, it ends up being exactly 1000.0.
Now that I see the behavior, I see why.
Floating point calculations are done using an 80 bit format, either inside
the 80x87, or in the 80x87 emulation code. So when 100.0 / 0.1 is
computed in the 80x87, the result is a little less than 1000.0. Then, if
the value is stored in a 64 bit format, the result is rounded to exactly
1000.0. However, if instead the result is truncated to an integer while
still in the 80x87 (or the "virtual" 80x87 in emulation), the result is
999, since it hasn't been rounded.
The reason the two different programs get different results, is that the
optimizing compiler decides it can do the computation at compile time for
one of the programs, but not the other. The compile time calculation
gives 999 for j, but the run time calculation uses the stored 64 bit value
of d, and so gets 1000 for j.
Is this a bug? Well, sort of. The moral is that conversions like this
can be quite dependent on implementation details of the compiler, the
floating point hardware or software, and whether results go through other
implicit comversions (like the 80 to 64 bit conversion). To be safe, you
should round results that are converted from double or float to int or
long. Anything else is asking for trouble. As for if this is a bug: it
is not a bug in the run time double to int conversion. It is a bug in the
logic of the optimizing compiler, since it does not produce the same
results for the two programs. However, I would not consider it a bug if
the compiler gave either j=999 or j=1000 for BOTH programs.
The way I recommend to round in C is "floor(0.5 + ...)" where ... is a
double or float expression. The result of float() is a double that you
can then convert into an int or long if the value is in range. The reason
to use floor() before the type conversion is that the behavior of type
conversion on negative numbers is not specified, but the behavior of
floor() is. Also, adding 0.5 to round something is not a "trick". I have
nothing against tricks; it's just that this doesn't happen to be one. It
is the proper algorithm to round a real number to the nearest integer.
Mark Adler
bitnet: madler@hamlet
arpa: madler@hamlet.caltech.edu
------------------------------
Date: Thu, 25 May 89 12:47:37 EDT
From: formtek!pen@uunet.UU.NET (Philip E. Nickerson, Jr.)
Subject: HELP with IBM==>MAC data transfer
My father has a Macintosh at home (ok, now I've lost 3/4 of you), but
consults with companies using IBM PC machines and clones. His problem is
that he wants to edit files on his MAC and put them on the PC. The origin
of the files may be from any of the various floppy formats on the PC or
they may originate from the MAC. (MS Word on the MAC allows him to save
the files as TEXT files, so there shouldn't be data compatability
problems.)
Here is the dilemma. I have found several products which hook directly to
the MAC which read and write text files from IBM disks, but in order to
read and write all of the IBM formats, two of these would be required
(each one has two drives which handle only one format.) The cost of this
would be much greater than the price of an inexpensive clone. But, all of
the clones come with a drive already in the package, which only reads one
format, so it would have to be trashed and other drives would have to be
purchased. Again, the cost soars.
Does anyone know of an inexpensive clone which comes with either one drive
which reads all of the 5-1/4" formats plus a drive for the 3.5" format, or
one of either of these so we can add the other, or are we destined to
throwing a lot of money at this problem.
I am not an IBM PC user, so I do not know where to go for information, so
I hope you all can help me.
PLEASE E-MAIL REPLIES TO PEN@FORMTEK.UUCP.
If you know of prices/addresses of good places to purchase the equipment,
please include this information also.
Thanx in advance!
-Phil
Philip E. Nickerson,Jr. |UUCP {pitt,psuvax1}!idis!formtek!pen
(412)937-4900|(800)FORMTEK| decvax!formtek!pen
"Programming is simply |Snail Formative Technologies, Inc.,
debugging a blank page! | Foster Plaza VII
| 661 Andersen Dr., Pittsburgh PA 15220
------------------------------
Date: Mon, 22 May 89 08:30:01 PDT
From: bmarsh@cod.nosc.mil (William C. Marsh)
Subject: Hercules and mouse problems.
Well, I am also trying to get a mouse to work with a Hercules graphics
card, but my problem has a little twist: The stated method *ONLY* works
if you *don't* have a color card installed! Otherwise the mouse driver
thinks you have the color card in graphics mode!
Does anybody have any idea about how to get this combination to work? I
think I'll have to draw the cursor myself, but I didn't want to emulate
the entire mouse driver...
Thanks in advance,
Bill Marsh, Naval Ocean Systems Center, San Diego, CA
{arpa,mil}net: bmarsh@cod.nosc.mil
uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!nosc!bmarsh
"If everything seems to be coming your way, you're probably in the wrong lane."
------------------------------
Date: Tue, 23 MAY 89 12:18 N
From: CAVECCHIA%ITNVAX.CINECA.IT%ICINECA2.BITNET@CUNYVM.CUNY.EDU
Subject: Integer -> double conversion problems
This is just a note on the problem about integer to double conversion that
I posted to the net some time ago.
I know that a conversion of this kind implies rounding errors that can be
avoided using some tricks like adding 0.5 to the double before converting
and so on.
What give me the suspect that this could be a bug of the Microsoft v5.1 C
compiler are the following considerations:
1) I compiled and ran the program both on a Vax with VMS and on a Sun, and
obtained the correct (aspected) results, i.e. i=1000, d=1000.00000 and
j=1000.
2) I don't understand why "j" (and not "i") give the correct result (1000)
in the first version of the program.
3) I've looked inside the assembly code produced by the compiler, the
value 999 is not the result of a run time computation, it is computed by
the compiler and assigned to the variable i with the following statement
; Line 5
*** 000009 c7 46 f6 e7 03 mov WORD PTR [bp-10],999 ;i
;|*** d = 100.0 / 0.1;
4) I've written a simple variation of the program (see program 2). I have
simply exchanged two lines and obtained different results.
main() /* program 1 */
{
short int i,j;
double d;
i = 100.0 / 0.1;
d = 100.0 / 0.1;
printf("i = %d\n",i); /* i = 999 (!) */
printf("d = %lf\n",d); /* d = 1000.000000 */
j = d;
printf("j = %d\n",j); /* j = 1000 (!) */
}
main() /* program 2 */
{
short int i,j;
double d;
i = 100.0 / 0.1;
d = 100.0 / 0.1;
j = d;
printf("i = %d\n",i); /* i = 999 (!) */
printf("d = %lf\n",d); /* d = 1000.000000 */
printf("j = %d\n",j); /* j = 999 (!!!) */
}
Thanks to all for any help and suggestion about this problem.
Valter V. Cavecchia | cavecchia@itncisca.bitnet
Centro di Fisica del C.N.R. | itnvax::cavecchia (DECnet, 37.65)
I-38050 Povo (TN) - Italy
------------------------------
Date: Tue, 23 May 89 08:56 CDT
From: Lee Miller <L_MILLER@nuacc.acns.nwu.edu>
Subject: Leading edge clock/cal
> IBM DOS 3.2 cannot find the Leading Edge's clock or calendar.
I don't have the leading edge, but I recently bought a clock/cal card from
a noname electronics supplier, which worked properly with the software
which was included, but not with standard AST type routines. I
unassembled their code, and it turned out there were a couple of
differences which you might try. The standard AST card has a latch in
front of the motorola chip, so that it appears at a single address. You
write a byte, x to the port, then read from the same port, and it returns
the value of the register x. Without the latch, you simply read from the
register at the base address plus x, which was the case with my card. The
other difference was that the base address was 240h rather than the normal
2C0h. I don't know why that was different (I'd be interested if anyone
else does) but you might try that as well.
Lee Miller
L_Miller @ NUACC.bitnet
------------------------------
Date: Thu, 25 May 89 12:27:59 -0400 (EDT)
From: Brian Patrick Arnold <ba0k+@andrew.cmu.edu>
Subject: Lotus WKS Format
We are developing an application to convert "spreadsheet-like" information
into the IBM Lotus 123 "WKS" format, or optionally into a Lotus-importable
format. We need to know where to find published information on this
format or on a compatible format. If anyone has tips or suggestions as to
finding this information, we would appreciate any help you can give.
Thank you.
- Brian
------------------------------
Date: Mon, 22 May 89 10:31 EST
From: <ROSSB%IUBACS.BITNET@UICVM.uic.edu>
Subject: Memory board problems
Greetings.
I'm hoping someone out there more knowledgeable about hardware may be
able to suggest the proper (best) course of action for a problem with a
memory board. We've a 1.5 meg Rampage AT running on an IBM AT, both about
2 and a half years old. Recently one of my software packages (SPSS/PC)
--and no other--has been crashing if I go to the ramdisk and start up the
program (after setting the parameter SET SPSS=C:\SPSS) If I run chkdsk on
the ramdisk after running SPSS/PC I get the "lost clusters" message.
Starting up from the harddisk does not invoke the problem. I ran the
software program RAMTEST and:
(1) with only the REMM.SYS driver loaded I get no errors in expanded memory
(2) with the REMM.SYS driver plus software for a ramdisk load I get
the message "parity error in 3rd 512 bank related to parity chip"
I figure there is a problem with the memory board but don't exactly know
what to do (aside from taking the unit to someone or sending the board
back to AST to check). So I'm wondering (1) will the problem get worse if
I just sit on it (2) is this maybe some simple problem that I can rectify
myself (like, disabling parity--but with what consequence)?
Thanks ahead for any advice. Bev Ross; BITNET: ROSSB@IUBACS
------------------------------
Date: Tue, 23 May 89 09:34:02 PDT
From: Don Reynolds <reynolds@prandtl.nas.nasa.gov>
Subject: PCED (Professional Command EDitor) source
Chris Dunford, the author of CED and PCED, can be reached at
Cove Software
10057-2 Windstream Drive
Columbia, MD 21044
His phone is (301)992-9371 per my latest records. I believe the price of
PCED is $47.00 (US).
Best,
Don
------------------------------
Date: Mon, 22 May 89 13:07 EDT
From: <HGOLDSTE%UDCVAX.BITNET@CORNELLC.cit.cornell.edu>
Subject: Response to RE: CADKEY
i have no connection with COMPUSERVE ... in fact i have, unfortunately
never used COMPUSERVE ... i will get around to it one day ... anyway we
are (at the University of the District of Columbia ... thats UDC) a CADKEY
Training Center and i have a fair amount of contact with CADKEY, the
company, because of that ... anyway that is how i know of the users group
they have on compuserve ....
as far as the small library of patterns we (thats UDC) have he can respond
to me directly ... i tried to GMAIL to the user directly but was
unsuccessful.
thanks much ...
by the way did you notice my note about the problem with SIMIBM.ARC ...
there are 4 errors in the index file that screws up the basic program.
[Not only did we notice it, but it's also being fixed.]
harold Goldstein
------------------------------
Date: Wed, 24 May 89 11:03 EDT
From: Carl <GRECO@Ruby.VCU.EDU>
Subject: Problems with double->int conversion with Microsoft C
In the Info-IBMPC Digest V89 #53, a "problem" converting from double to
short integer using Microsoft C was described.
This is due to the inability of the finite word length computer to exactly
represent all floating point numbers, either as floats or doubles. There
are several methods for representation of floating point numbers; the most
common being the IEEE standard. The conversion from a floating point to
an integer in the sample program was performed by truncation, i.e.,
i = 100.0/0.1;
where i was declared a short int.
In order to obtain the "expected" result it is necessary to round instead
of truncate. The following macro can be used for this purpose.
#define round(x) (int) ((x)+(((x)>0)?.5:-.5))
and
i = round(100.0/0.1);
------------------------------
Date: Wed, 24 May 1989 16:39 MDT
From: Ted Nieland - SRL <TNIELAND%FALCON@AAMRL.AF.MIL>
Subject: SIMTEL20 tapes available from DECUS
The SIMTEL20 MSDOS, ADA, and UNIX-C collections have been submitted to the
DECUS Library. They have been assigned part numbers as listed below.
The MS-DOS collection was broken into two pieces (it would not fit on a
single TK50 tape).
Here are the part numbers:
SIMTEL20 Unix-C Collection VMS BACKUP Format............V-SP-88
SIMTEL20 Unix-C Collection TAR Format...................U-SP-105
SIMTEL20 MSDOS Collection Part 1 VMS BACKUP Format......V-SP-89
SIMTEL20 MSDOS Collection Part 2 VMS BACKUP Format......V-SP-90
SIMTEL20 ADA Collection VMS BACKUP Format...............V-SP-91
I will be attempting to update these collections in the DECUS Library
every six months or so. I will be FTPing all files that changed and
removing the superseded files to get a current copy of the archive,
without having to get the entire archive again.
The address and phone number for the DECUS Library is:
The DECUS Program Library
219 Boston Post Road BP02
Marlboro, MA 01752-1850
Phone: 508 480-3418
Ted
M. Edward (Ted) Nieland - Systems Analyst
| US Snail: | Arpa Internet: |
| Systems Research Laboratories, Inc. | TNIELAND@WPAFB-AAMRL.ARPA |
| 2800 Indian Ripple Road WP 196 | TNIELAND%FALCON@WPAFB-AAMRL.ARPA |
| Dayton, OH 45440 | |
| A T & T: (513) 255-8846/8760/5165 |
------------------------------
Date: Mon, 22 May 89 08:58:19 CDT
From: moore@ncsc.navy.mil (Moore)
Subject: SmartDrive question
The documentation that comes with Windows 2.11/286 states that, when you
use the disk caching driver Microsoft provides (SmartDrive), you should
set your buffers to 20. This seems redundant: if you're using a disk
cache, shouldn't you be able to reduce the buffers to (virtually) 0, since
the device driver is already doing caching?
Thanks for any assistance.
Jim
moore@NCSC.navy.mil
------------------------------
Date: 22 Jul 89 12:15:53 GMT
From: hafer@infbs (Udo Hafermann)
Subject: Turbo-C: GEM bindings? Accessories?
Can anyone provide me with a pointer to GEM bindings for Borland's Turbo
packages, and for information on how to write Desk Accessories? Please
mail - I'm not a regular reader of this group.
------------------------------
Date: Wed, 24 May 89 10:05:23 CDT
From: steve@ncsc.navy.mil (Mahan)
Subject: Zenith key-click
In response to the query for software for disabling the keyclick on the
Zenith Z-248 machine I have come up with an alternate solution.
It is a fairly simple matter to disconnect the keyboard speaker
permanently. Simply turn over the keyboard, remove the four Philips head
screws securing the steel bottom, and remove the bottom. You will see the
circuit board exposed. Near the 40 pin DIP (there's only one) locate 2
large through holes with the label SP printed near them. Simply cut one
of the traces leading to one of these through holes. Be careful. DO NOT
cut a trace if you are not sure.
To verify that you have found the correct trace remove the 6 Philips
head screws securing the circuit board on each end of the case (3 ea) and
lift up the circuit board. The speaker is the small silver cylinder near
the back center of the board. Reinsert the six screws securing the circuit
board, remembering to reattach the stainless steel strip on the cable side
of the board. Replace the bottom and resecure with the four remaining
screws
This should not take more than 5-10 minutes per board after the first
one. I am typing this on a modified Z-248 keyboard.
WARNING: this will void your warranty on the keyboard. This worked
for me but I cannot claim responsibility for results obtained by any other
person.
Stephen Mahan
Code 5330
Naval Coastal Systems Center
Panama City, FL 32408-5000
(904) 234-4224
ARPA: steve@ncsc.navy.mil
------------------------------
Date: Wed, 24 May 89 13:13:15 CDT
From: FRITZ KEINERT <@CCVAX.IASTATE.EDU:S1.FXK@ISUMVS.BITNET>
Subject: Re: floating point problem in Microsoft C
In digest #53, Cavecchia asks why the lines
i = 100.0 / 0.1;
printf("i = %d\n",i);
in Microsoft C produce the output
i = 999
My guess is that it is simply a round-off problem which has nothing to do
with your particular language. I always spend some time discussing this
sort of stuff when I teach numerical analysis.
As everyone knows, 1/3 = 0.333333... in base 10, so any base 10 calculator
will produce (1/3)*3 = 0.99999999... Typically, there are extra internal
digits, so you don't see that, but it happens.
Likewise, on binary computers, the number 0.1 cannot be represented
exactly. It comes out as 0.000 1100 1100 1100 1100 ... If you store it as
an IEEE standard single precision floating point number, it is cut off
right before one of those 1100 groups and therefore rounded up, so it
comes out as 0.000 1100 .... 1101. The value in base 10 is about
0.10000000149116... The number 100.0 is represented exactly, like all
integers up to 7 or 8 decimal digits.
Therefore, when you calculate 100. / 0.1, you really are calculating 100.0
/ 1.0000000149..., which is more like 999.99999999... By the usual
conversion rules, the conversion real->integer is done by truncating, so
you get your i = 999.
I don't know of any general way to avoid this problem. I have resorted to
constructions like
i = 100.0 / 0.1 + eps
in the past, where eps is a number near the machine epsilon (typically
around 1.e-7 for single precision, 1.e-14 for double precision), when I
suspected similar problems.
Fritz Keinert
S1.FXK@ISUMVS
------------------------------
Date: Wed, 24 May 89 14:33:33 SET
From: Rainer Kleinrensing <RAINER%DBNUAMA1.BITNET@CUNYVM.CUNY.EDU>
Subject: No name clone ans OS/2
Hello,
a friend of mine, who has currently no access to netland, has asked me to
submit the following problem to INFO-IBMPC:
My friend recently bought the following hardware:
- no-name 25Mhz 386 (Chips&Technologies Chips) with 4MB on board,
expandable to 8MB
- Hercules video card
- Seagate ST01 SCSI Host adaptor
- Seagate ST296N 83 MB SCSI hard drive
- WD 1002 A FOX Floppy controller
- 1.2MB Chinon floppy drive.
This machine works fine under DOS. However, when trying to boot the IBM
OS2 1.0 Extended Edition Installation disk, it doesn't boot, but
instantaneously displays 'A disk read error occured'. This message can be
found in the boot sector of the OS2 installation disk. You see no IBM logo
etc., the floppy drive simply reads the first track and you see the
message. After that, the machine hangs. The same is true for IBM OS2
extended edition 1.1 and the MS OS2 1.1 development toolkit. However, if
you physically remove the SCSI host adaptor, the installation disks boot
fine (with the exception that you then have no hard disk to install OS2
on). When you put in a 'normal' AT-style hard disk controller and hard
disk, OS2 installs fine and also boots from the hard disk. (Note that
manually writing a boot sector to the SCSI drive also doesn't work.)
His conclusion is that OS2 doesn't work with a SCSI drive or controller.
The question: has anyone tried to install OS2 on such a machine with SCSI
drive(s) ?
Is there a patch available either from MS or IBM that allows OS2 to
operate on SCSI drives ?
Any hint in that direction (even reports that it works/doesn't work on
other machines) would be greatly appreciated.
Please reply directly to me, I'll summarize to the net.
Rainer Kleinrensing (RAINER at DBNUAMA1.BITNET)
------------------------------
End of Info-IBMPC Digest
************************
-------