Info-IBMPC@C.ISI.EDU (Info-IBMPC Digest) (07/07/87)
Info-IBMPC Digest Monday, 6 July 1987 Volume 6 : Issue 50
This Week's Editor: Billy Brackenridge
Today's Topics:
Good news not entirely true
More on good news bad news
Turbo C Floating Point Patch
INTEL-310 ABR
IBM Graphics on an Epson clone.
freemacs
Undocumented Switches in 'cl.exe' for MS-C Ver 4.00
IBMCACHE Benchmarks
Adaptec ACB 2070A rll Disk Controller Suffers Heatstroke
Tutorial Software like Show Partner
Direct Manipulation of Serial Ports
KBEDIT
Today's Queries:
External Tape Drive Back-up
PC/XT Clones
Applewriter
IBM H14
High-Res AT Graphics
Need help with MicroSoft Languages
Microsoft Pascal Compiler
Widely Used Tools on Various Hosts
ps2/50 & external 5.25 drive (2 Msgs.)
Turbo Pascal and Hercules
Turbo C and CodeView
Appointment Calendars
Turbo Pascal 4.0
Book Wanted on File Formats
Interrupt 17
INFO-IBMPC BBS Phone Numbers: (213)827-2635 (213)827-2515
----------------------------------------------------------------------
Date: Mon 29 Jun 87 09:36:29-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: Good news not entirely true
To: brackenridge@C.ISI.EDU
I think the announcement in the digest should have been phrased that we agree
to take it over IF we get the funding, at least for the first year. With the
staff shortages here, we can't possibly take on that kind of responsibility
without being able to add a position, which can't be done without funding up
front. The wording of the announcement won't have a good effect at Columbia,
and outside Columbia it'll make people think the problem has taken care of
itself. Maybe a clarification in the next digest? Thanks! - Frank
[I will continue the digest till September. Dick Gillmann and, hopefully,
Koji Okazaki will help out while I am gone at the end of July. This gives us
a little more time to look for money for Columbia. -wab]
------------------------------
Date: Mon 29 Jun 87 10:04:06-EDT
From: Frank da Cruz <SY.FDC@CU20B.COLUMBIA.EDU>
Subject: More on good news bad news
To: brackenridge@C.ISI.EDU
My boss told me that you should also say that although funding is the
primary consideration, we also can't formally accept until the University
agrees to create the position. Also, people probably shouldn't start sending
checks quite yet. Instead, they should contact me -- I'll talk to them, and
then get back to them later after things have gelled a bit more. So it's more
like a pledge drive. Sort of a chicken-&-egg situation: can't create the job
till we have enough pledges, but can't take money till we know we can create
the job. - Frank
------------------------------
Date: Fri, 26 Jun 87 17:09:40 edt
From: John P. Nelson <panda!teddy!jpn@talcott.harvard.edu>
Subject: Turbo C Floating Point Patch
Organization: GenRad, Inc., Concord, Mass.
Here are all of the patches to turboC currently available on CompuServe:
(Four in all, three official patches, and one replacement function source).
- john nelson
PRODUCT : TURBO C NUMBER : 356
VERSION : 1.0
OS : PC-DOS
DATE : May 28, 1987 PAGE : 1/1
TITLE : -G PATCH
The following patch solves a problem in Turbo C where the
compiler can run out of memory compiling a large switch
statement if the -G option is used.
To apply this patch, you will need to use the DOS utility DEBUG.COM.
You may obtain a copy of DEBUG.COM from one of your original PC-DOS
or MS-DOS diskettes.
NOTE: 1. Do not patch your original Turbo C disk, use a working or
backup copy of TCC.EXE and TC.EXE for this patch.
2. DEBUG is not sensitive to upper and lower case. All ad-
dresses are listed in upper case for ease of readability.
3. XXXX,YYYY,ZZZZ are hexadecimal digits returned by DEBUG.
You must replace these digits accordingly when typing
in your commands.
4. While in DEBUG, the prompt will appear as a dash (-).
5. If you do not receive the appropriate response,press "q"
followed by <Enter>, to exit from DEBUG. Check your
version number and, if correct, try again.
6. TCC.EXE and TC.EXE will not fit together onto a 360K disk.
To patch both programs on a floppy disk, you may need to
copy TCC.EXE and DEBUG.COM onto one disk and perform the
patch. Save the patched version of TCC.EXE to another
disk. Repeat the same steps using TC.EXE.
At the DOS prompt, type the following information exactly as it
appears (Conclude each line by pressing <Enter>).
Patch for TCC.EXE
Type the following: You will see:
ren tcc.exe tcc.xex<Enter> A>
debug tcc.xex<Enter> -
r<Enter> ... CS=XXXX ...
-
h XXXX 1635<Enter> YYYY ZZZZ
-
e YYYY:7E0<Enter> YYYY:07E0 7C.
72<Enter> YYYY:07E0 7C.72
-
w<Enter> Writing 2948A bytes
-
q<Enter> A>
ren tcc.xex tcc.exe<Enter> A>
Patch for TC.EXE
Type the following: You will see:
ren tc.exe tc.xex<Enter> A>
debug tc.xex<Enter> -
r<Enter> ... CS=XXXX ...
-
h XXXX 1F84<Enter> YYYY ZZZZ
-
e YYYY:7E1<Enter> YYYY:07E1 7C.
72<Enter> YYYY:07E1 7C.72
-
w<Enter> Writing 38759 bytes
-
q<Enter> A>
ren tc.xex tc.exe<Enter> A>
PRODUCT : TURBO C
VERSION : 1.0
OS : PC-DOS
DATE : MAY 20, 1987 PAGE : 1/2
TITLE : FLOATING POINT EVALUATION - PATCH
The following patch solves a problem with dividing floating point
evaluation.
To apply this patch, you will need to use the DOS utility DEBUG.COM.
You may obtain a copy of DEBUG.COM from one of your original PC-DOS
or MS-DOS diskettes.
NOTE: See note from previous patch
PRODUCT : TURBO C
VERSION : 1.0
OS : PC-DOS
DATE : MAY 20, 1987 PAGE : 2/2
TITLE : DIVISION OF CONSTANTS - PATCH
Patch for TCC.EXE
Type the following: You will see:
ren tcc.exe tcc.xex<Enter> A>
debug tcc.xex<Enter> -
r<Enter> ... CS=XXXX ...
-
h XXXX 2420<Enter> YYYY ZZZZ
-
e YYYY:369<Enter> YYYY:0369 0A.
6<Enter> -
e YYYY:36F<Enter> YYYY:036F 06.
A<Enter> -
w<Enter> Writing 2948A bytes
q<Enter> A>
ren tcc.xex tcc.exe<Enter>
Patch for TC.EXE
Type the following: You will see:
ren tc.exe tc.xex<Enter> A>
debug tc.xex<Enter> -
r<Enter> ... CS=XXXX ...
-
h XXXX 2D01<Enter> YYYY ZZZZ
-
e YYYY:35E<Enter> YYYY:035E 0A.
6<Enter> -
e YYYY:364<Enter> YYYY:0364 06.
A<Enter> -
w<Enter> Writing 38759 bytes
q<Enter> A>
ren tc.xex tc.exe<Enter>
PRODUCT : TURBO C NUMBER : 355
VERSION : 1.0
OS : PC-DOS
DATE : May 28, 1987 PAGE : 1/1
TITLE : STRUCTURE PUSH FLOATING POINT PATCH
The following patch solves a problem with pushing structures
with floating point elements onto the stack in Turbo C.
To apply this patch, you will need to use the DOS utility DEBUG.COM.
You may obtain a copy of DEBUG.COM from one of your original PC-DOS
or MS-DOS diskettes.
NOTE: See note from previous patch
At the DOS prompt, type the following information exactly as it
appears (Conclude each line by pressing <Enter>).
Patch for TCC.EXE
Type the following: You will see:
ren tcc.exe tcc.xex<Enter> A>
debug tcc.xex<Enter> -
r<Enter> ... CS=XXXX ...
-
h XXXX 1C0C<Enter> YYYY ZZZZ
-
e YYYY:2FAD<Enter> YYYY:2FAD 25.
A9<Space> YYYY:2FAD 25.A9 01.
<Space> YYYY:2FAD 25.A9 01. 00.
<Space> YYYY:2FB0 81.
74<Space> YYYY:2FB0 81.74 E2.
0B<Space> YYYY:2FB0 81.74 E2.0B 00.
40<Space> YYYY:2FB0 81.74 E2.0B 00.40 00.
26<Space> YYYY:2FB0 81.74 E2.0B 00.40 00.26
0B.
83<Space> YYYY:2FB0 81.74 E2.0B 00.40 00.26
0B.83 D0.
47<Space> YYYY:2FB0 81.74 E2.0B 00.40 00.26
0B.83 D0.47 74.
6<Space> YYYY:2FB0 81.74 E2.0B 00.40 00.26
0B.83 D0.47 74.6 0A.
1<Space> YYYY:2FB8 26.
<Space> YYYY:2FB8 26. 83.
<Space> YYYY:2FB8 26. 83. 47.
57<Space> YYYY:2FB8 26. 83. 47.57 06.
8<Space> YYYY:2FB8 26. 83. 47.57 06.8
01.
0<Space> YYYY:2FB8 26. 83. 47.57 06.8
01.00 26.
29<Space> YYYY:2FB8 26. 83. 47.57 06.8
01.00 26.29 83.
6<Space> YYYY:2FB8 26. 83. 47.57 06.8
01.00 26.29 83.6 57.
54<Space> YYYY:2FC0 08.
74<Space> YYYY:2FC0 08.74 00.
90<Enter> YYYY:2FC0 08.74 00.90
-
w<Enter> Writing 2948A bytes
-
q<Enter> A>
ren tcc.xex tcc.exe<Enter> A>
Patch for TC.EXE
Type the following: You will see:
ren tc.exe tc.xex<Enter> A>
debug tc.xex<Enter> -
r<Enter> ... CS=XXXX ...
-
h XXXX 2557<Enter> YYYY ZZZZ
-
e YYYY:2FA4<Enter> YYYY:2FA4 25.
A9<Space> YYYY:2FA4 25.A9 01.
<Space> YYYY:2FA4 25.A9 01. 00.
<Space> YYYY:2FA4 25.A9 01. 00. 81.
74<Space> YYYY:2FA8 E2.
0B<Space> YYYY:2FA8 E2.0B 00.
40<Space> YYYY:2FA8 E2.0B 00.40 00.
26<Space> YYYY:2FA8 E2.0B 00.40 00.26 0B.
83<Space> YYYY:2FA8 E2.0B 00.40 00.26 0B.83
D0.
47<Space> YYYY:2FA8 E2.0B 00.40 00.26 0B.83
D0.47 74.
6<Space> YYYY:2FA8 E2.0B 00.40 00.26 0B.83
D0.47 74.6 0A.
1<Space> YYYY:2FA8 E2.0B 00.40 00.26 0B.83
D0.47 74.6 0A.1 26.
<Space> YYYY:2FB0 83.
<Space> YYYY:2FB0 83. 47.
57<Space> YYYY:2FB0 83. 47.57 06.8 26.
8<Space> YYYY:2FB0 83. 47.57 06.8 01.
0<Space> YYYY:2FB0 83. 47.57 06.8 01.00
26.
29<Space> YYYY:2FB0 83. 47.57 06.8 01.00
26.29 83.
6<Space> YYYY:2FB0 83. 47.57 06.8 01.00
26.29 83.6 57.6 08.
C<Space> YYYY:2FB0 83. 47.57 06.8 01.00
26.29 83.6 57.C 08.
A3<Space> YYYY:2FB8 00.
90<Enter> YYYY:2FB8 00.90
-
w<Enter> Writing 38759 bytes
-
q<Enter> A>
ren tc.xex tc.exe<Enter> A>
#: 83131 S11/Turbo C
07-Jun-87 04:44:44
Sb: #83081-TURBO C BUG
Fm: Brad Paulsen (PROGSIG) 76703,1005
To: WALT HOWARD 73240,142
Walt,
I'm not the sysop (here at least - <grin>), but I think I can step in here and
tell you that this problem has already been reported and (I believe)
acknowledged by Borland.
While there is no _official_ fix available yet (at least there was nothing in
DL11 as of about 1 hour ago), you're welcome to use the following until one is
available:
char *strstr (keystr, targetstr)
char *keystr, *targetstr;
/*
Features of Operation:
- If keystr or targetstr is NULL, a NULL pointer (failure) is returned
(i.e., NULL pointer input is handled gracefully).
- If keystr or targetstr contains only a NULL character, a NULL pointer
(failure) is returned (i.e., NULL's are not considered characters for
the purpose of this function -- they are considered string terminators).
- The search terminates successfully when '\0' of keystr is encountered
before (or at the same time) as '\0' of targetstr. The search terminates
unsuccessfully when '\0' of targetstr is reached before '\0' of keystr.
*/
{
register unsigned short i;
if (keystr == (char *) 0 || targetstr == (char *) 0)
return ((char *) 0);
if (*keystr == '\0' || *targetstr == '\0')
return ((char *) 0);
do {
for (i = 0; *(keystr+i) && (*(keystr+i) == *(targetstr+i)); i++);
if ( !(*(keystr+i)) )
return (targetstr);
} while (*(targetstr++));
return ((char *) 0);
}
As you can see, this replacement handles NULL pointer input gracefully, is
completely iterative and uses no calls to other library routines (for speed).
It's also 4 bytes _shorter_ than the original Borland version. And, as far as
I've been able to determine, it works!
Brad
Read action:
------------------------------
From: ism780c!mikep@sdcsvax.ucsd.edu (Michael A. Petonic)
Subject: INTEL-310 ABR
Date: 27 Jun 87 01:50:59 GMT
Organization: Interactive Systems Corp., Santa Monica CA
>Date: 23 Jun 87 07:59:39 EDT
>From: dicke @ belvoir-mail1.arpa
>Subject: INTEL-310 ABR
>
>
>Has anyone out there been able to get their Intel-310 to autobaud detect?
>Our 310's are the only systems on our network that don't have this cap-
>ability, and my Intel systems administrator says ABR isn't available. Is
>this really true?
There is a way to get autobaud detection, but only between 300-600-1200
baud. I think the setting is 3 in the /etc/ttys file. I'm not so
sure, so consult the getty entry in the Ref. Guide (or login, but
I forget which). I think this should have been posted to
comp.sys.intel instead of the ibmpc group.
MikeP {seismo|sdcrdcf}!ism780c!mikep "Some of my best friends are Bigots..."
------------------------------
Date: Sat, 27 Jun 87 10:40:25 PLT
From: "Glenn L. Austin" <AUSTIN%WSUVM1.BITNET@wiscvm.wisc.edu>
Subject: IBM Graphics on an Epson clone.
>I have a Star Micronics Gemmini 10X printer running from a PC clone.
>When I use graphics programs requiring Epson compatibility (the Gemini is), I
>get the graphics characters okay, except a blank space is printed between
>each line of output. I have tried setting the line spacing to 8 lpi to
>no avail. The graphs are correct but elongated with empty spaces. Is there
>a fix for this--short of buying a new printer?
Check the command for variable line feeds. Either this command is not
implemented (doubtful, since changing to 8 lpi didn't work), or it doesn't
set spacing to n/72".
------------------------------
Date: Wednesday, 24 June 1987 13:29-MDT
From: Russell Nelson <bh01%CLUTX.BITNET@WISCVM.WISC.EDU>
To: kpetersen@SIMTEL20.ARPA
Subject: freemacs
There is a new release of Freemacs, the programmable editor. It can
be found in pd:<msdos.text-editors> on simtel20:
Filename Type Bytes CRC
Directory PD:<MSDOS.TEXT-EDITOR>
EMACS14A.ARC.1 BINARY 176128 31B6H
-russ
bh01%CLUTX.BITNET@WISCVM.ARPA
------------------------------
From: srp@ethz.UUCP (Scott Presnell)
Subject: Undocumented Switches in 'cl.exe' for MS-C Ver 4.00
Date: 26 Jun 87 10:36:35 GMT
Organization: Chem. Dept., Swiss Federal Inst. of Tech. (ETH-Zurich)
For your amusement, here is a listing of options available in cl.exe for MSC
4.00, the documented options were added for completeness. The undocumented
options were 'discovered' using the Norton Utilities, and their functions
determined "on a rainy day". Hope someone will find them useful. Please
feel free to correct me or fill in the blanks.
Go wild son ...
--------
Listing of options in 'cl' of MS-C Ver. 4.00, documented and undocumented.
Switch Documented Function
-c yes
-d no Display passes as they happen.
-dos Xenix
-i no
-imp no
-n no
-s no
-k no Keep temp files (quiet).
-link yes
-l* no False friend, see below.
-m# no Make .map file.
-nl# no
-nologo no Don't print logo on startup.
-pack yes
-pathgen no
-o# no Name the output (exe) file.
-p no Gives warning about no -Gp.
-pa# no
-pl# no Supply alternate linker.
-p0# no Supply alternate pass 0 cmd.
-p1# no Supply alternate pass 1 cmd.
-p2# no Supply alternate pass 2 cmd.
-p3# no Supply alternate pass 3 cmd.
-pL# no
-u yes
-v# no
-w yes
-z no Print passes (do not compile).
-A* yes
-Ba# no
-Bd no Print passes as they happen.
-Bk no Keep temp files (verbose).
-Bl# no Supply alternate linker.
-Bz no Print passes (do not compile).
-B0# no Supply alternate pass 0 cmd.
-B1# no Supply alternate pass 1 cmd.
-B2# no Supply alternate pass 2 cmd.
-B3# no Supply alternate pass 3 cmd.
-BL# no
-C yes
-CSOFF no
-D# yes
-E yes
-EP yes
-FP* yes
-Fa(*) yes
-Fe* yes
-Fc(*) yes
-Fl(*) yes
-Fs(*) yes
-Fo* yes
-Fm(*) yes
-Gt(*) yes
-G* yes
-HELP yes
-H# yes
-I# yes
-K no Keep temp files (see -k).
-J yes
-L no Make .cod file only.
-M# Xenix See pg 298 MS-C Users Guide.
-ND# yes
-NM# yes
-NT# yes
-O(*) yes
-P yes
-PLM no _main & exit unresolved.
-PLMF no no default lib search.
-PLMN no -PLMF + something else?
-S no Make .asm file only.
-U# yes
-V# yes
-W# yes
-X yes
-Z* yes
*, # -- symbols used in the cl.exe string formats. Usually indicates
something further needs to be specified.
Favorite Undocumented Option: -nologo (makes my error.log files much
smaller).
N.B.: -l does not act like -l in 'ld' on UNIX systems. 'Cl' just seems
to chop off the -l and treat the rest like an object file to be linked.
Note undocumented 'cc/ld' compatible options, -o, -S, -B?, -O.
I would suspect that -Ba#, -pa# would allow an alternate assembler,
but 'cl' doesn't seem to be able to call 'masm'.
Any one got any good ideas about what -pathgen might do?
Regards,
-------
Scott Presnell Organic Chemistry
Swiss Federal Institute of Technology (ETH-Zentrum)
CH-8092 Zurich, Switzerland.
uucp:seismo!mcvax!cernvax!ethz!srp (srp@ethz.uucp); bitnet:Benner@CZHETH5A
"... I dunno, maybe it was Ewe-tah ..."
------------------------------
Date: Tue 30 Jun 87 14:19:44-PDT
From: <Found under a Rock>
Subject: IBMCACHE Benchmarks
I recently acquired a copy of the disk caching program that comes
with the new IBM PCs. I tested it with image processing in mind by
using it with the DOS COPY program and an automatic contrast
enhancement program on a 800 line by 800 byte image. The
stretch program sequentially reads every tenth line the input image
to acquire a histogram. It then reads a line of the input, does a
table look up for each pixel in the line, and writes an output line.
It cycles through this for each line. I initially assumed that a
disk caching program wouldn't help performance much for sequential
processing, but my tests indicate this is not true. Performance can
be doubled. The PC used was a PC-AT clone running at 8Mhz 0 wait
states. The disk was a Maxtor XT-1140, a 120 megabyte disk
partitioned into 4 roughly equal partitions of 30 Megabytes each
using SPEEDSTOR. The input file was in the first partition and the
output was in the third, requiring the heads to travel roughly half
way across the platters on each head seek. MS-DOS 3.2 was the
operating system. I varied the size of the disk cache, the block size
of the cache, and the number of DOS buffers. The cache program
required about 10k of memory and about 1k more memory for each 100k
of cache.
In the table below I have listed my results. The column marked COPY
is the result of using the DOS COPY command to copy the image. The
STRETCH column is the result of the automatic contrast program. The
FREE MEMORY column lists the number of bytes available for normal DOS
programs after all the device drivers and memory resident programs I
use are loaded. I used the public domain MAP program to obtain this.
The /P column is the value of n I used as explained above. Times are
in m:ss.f format for COPY and m:ss for STRETCH where m is minutes, s
is seconds and f is tenths of a second. The times for COPY are for
the second time the COPY test was run. The second time was always
about a second shorter than the first for unknown reasons.
Results:
buffers= cache size(k) /P COPY STRETCH FREE MEMORY
20 0 0:09.1 3:27 567504
5 0 0:08.2 3:27 575424
default 1000 default 0:08.1 1:56 550400
default (1) 1000 1 0:08.4 4:19 576480
default 1000 2 0:08.2 2:43 535424
default 1000 4 0:08.2 1:57 550400
default 1000 8 0:08.1 1:31 556352
20 1000 8 0:07.9 1:25 547376
10 1000 8 0:07.9 1:25 552656
5 1000 8 0:07.9 1:25 555296
3 1000 8 0:08.0 1:29 556352
2 1000 8 0:08.4 1:36 556880
1 1000 8 0:08.6 1:36 557408
3 2000 8 0:08.1 1:21 548352
3 1500 8 0:08.1 1:22 552352
0 (2) 1000 8 0:08.1 1:28 556352
3 700 8 0:08.1 1:35 558752
3 500 8 0:08.1 1:39 560352
3 200 8 0:08.1 1:41 562752
3 100 8 0:08.1 1:41 563552
default (3) 0 0 :56
default (4) 0 0 :48
Notes:
(1) I got an error message when I booted saying 1 is not an allowed
value for /P. Everything still ran but like there was no cache
installed.
(2) when I specified buffers=0 in the CONFIG.SYS I got an error
message and the system appeared to allocate the default (3) buffers.
(3) STRETCH from harddisk to ramdisk
(4) STRETCH from ramdisk to ramdisk
Conclusions:
Greatly improved throughput can be obtained with as few as 3 DOS
buffers and a few hundred kilobytes of cache. DOS buffers don't
matter much if a cache is available. Changing from BUFFERS=20 to
BUFFERS=3 and adding a 100k byte cache costs about 4k bytes of memory
in the precious 640k region DOS and your programs live in but can
improve disk speed by a factor of 2. I can actually hear the
difference in the noise my disk makes when the cache is installed. It
runs more quietly with the cache.
Using a ramdisk is much better than using the disk cacheing program, but
does require some intelligence and extra typing on the user's part.
------------------------------
Date: Thu, 2 Jul 87 00:28:50 PDT
From: Ya'akov_Miles%UBC.MAILNET@MIT-Multics.ARPA
Subject: Adaptec ACB 2070A rll Disk Controller Suffers Heatstroke
According to the Adaptec ACB-2070A manual (401404-00A/AB/BOFORS)
page 2-1, this RLL disk controller BOARD will only operate within
spec at temperatures below 133 F (55 C). I have encountered problems
with my IBM-PC/xt clone, when the ambient temperature exceeds that
of a moderately well air-conditioned office, which is not surprising
considering that the temperature inside the computer is typically
about 30-40 F warmer than the outside environment. I hope that
Adaptec(?)/580 Cottonwood Drive/Milpitas/Ca 95036/USA/(408)946-8600
fix up their products so that we can use them to defend our numerous
Middle Eastern (and other) friends...
------------------------------
From: yale!hsi!tankus@seismo.CSS.GOV (Ed Tankus)
Subject: Tutorial Software like Show Partner
Date: 30 Jun 87 11:35:30 GMT
Organization: Health Systems Intl., New Haven, CT
Daniel,
You might want to try to contact Nostradamus, Inc. in Salt Lake City, UT.
They make a software package called Instant Replay II that is a combination
of Dan Bricklin's Demo and Show Partner.
Instant Replay also allows interactive sessions with the subject or student.
Cheers!
Ed.
Net : {noao!ihnp4!yale!}!hsi!tankus
Snail: Health Systems Int'l, 100 Broadway, New Haven, CT 06511
Bell : (203) 562-2101
------------------------------
Date: Fri, 03 Jul 87 13:57:37 PDT
From: Roland McGrath <roland@lbl-rtsg.arpa>
Message-ID: <870703135737.3889@bl-rtsg>
Subject: Direct Manipulation of Serial Ports
Can someone send me a good description of how to directly
manipulate the PC's serial ports?
I gather that this sort of information is supposed
to be in the DOS Technical Reference manual, but
the IBM book I have calling itself by that name
doesn't even list the BIOS calls, much less the
hardware ports.
Is there some other book I should have???
Thanks,
Roland McGrath (roland@lbl-rtsg.arpa)
P.S.
I'm not a technical dunce, but I need something that
describes the ports 3F8-3FF (2F8-2FF,3E8-3EF,2E8-2EF), telling
me which are input and which are output and the bits that need
to be set in each byte or word to do various things.
------------------------------
Date: 3 Jul 1987 15:34:10 PDT
From: <KRANENBU%HLERUL5.BITNET@wiscvm.wisc.edu>
Subject: KBEDIT
KBEDIT provides a larger keyboard buffer and command line editing.
Such programs have been around for some time in various shapes, but I wanted
to have a program that minimally disturbs the system (in terms of stolen
interrupt vectors, undocumented system data, etc.), and where unavoidable, can
be easily reconfigured to adapt to incompatible software.
The program has been in use for over two years now and has gradually evolved
over this period to be believed fairly tested and debugged.
KBEDIT is a DOS device driver performing two independent functions:
- larger keyboard type-ahead buffer
- replacing DOS function 0AH (buffered input) with full
editing facilities
The reason for programming it as a (character) driver is twofold:
1) it is possible to relocate the keyboard buffer within
the DOS-data-segment at 40H and
2) it is easy to control operation of the program using normal DOS-channels.
i.e., one can write characters to the device using its name (which is KBEDT)
through DOS write file functions or even from the command line by typing
COPY CON KBEDT followed by a two-character control code.
The file assembly consists of the following parts:
- README.KB, explaining the functions of KBEDIT
- KBEDIT.ASM, assembler source of the driver
- ANSI21.SCR, ANSI32.SCR, scripts for DOS DEBUG program
The latter files may be necessary to fix a bug appearing in ANSI.SYS
which came with various versions of PC-DOS. These versions of
ANSI.SYS performs input- buffer flush by using absolute addresses
(4EH) where it should get its data from the DOS-DATA-SEGMENT (at
40H). Other console drivers (such as NANSI.SYS, which I have seen)
might not contain this bug. Use ANSI21.SCR for PC-DOS version 2.1
ANSI.SYS driver. Use ANSI32.SCR for PC-DOS versions 3.0, 3.1, 3.2
ANSI.SYS driver.
[KBEDIT.ASM has been added to the info-ibmpc lending library. -wab]
------------------------------
Subject: External Tape Drive Back-up
Date: Sat, 27 Jun 87 14:51:56 -0400
From: edelheit%community-chest.mitre.org@gateway.mitre.org
I am interested in purchasing an external tape drive for backing up several
XTs and XT clones. I also expect to be adding an AT clone in the near future.
I don't think that I need more than 20mb of tape storage and would like to
be able to perform selective dumps and restores.
Any comments, experiences, etc. would be greatly appreciated.
Jeff Edelheit (edelheit@mitre-gateway.arpa)
The MITRE Corporation, 7525 Colshire Drive
McLean, VA 22102 (703) 883-7586
------------------------------
From: sr16#@andrew.cmu.edu (Seth Benjamin Rothenberg)
Date: Sat, 27 Jun 87 16:02:17 edt
Subject: PC/XT Clones
I am looking into buying an XT clone. Two are under serious
consideration: Leading Edge, and Visual. The Visual is available
from DAK, with a cheap Daisy-wheel included. I would appreciate
any advice/comments people have on compatibility of these models,
or of any others that claim to be compatible but aren't. (I know
that some don't claim to be completely compatible) Thanks in
advance.
Seth Rothenberg
sr16@andrew
sr16@andrew.cmu.edu
seismo!andrew.cmu.edu!sr16
------------------------------
Subject: Applewriter
From: oxy!bagpiper@csvax.caltech.edu (Michael Paul Hunter)
Date: 28 Jun 87 14:47:57 PST
I have been having a lot of problems getting an AT clone
to talk to an applewriter. We can hook an applewriter up to
a true blue PC and everything flys, but with an AT nothing
happens. I can't fathom this problem...the serial card on
the AT should act like the one on the PC. BTW the clone we
tried it on was a compaq 286.
Michael Hunter UUCP : ...{seismo, rutgers, ames}!cit-vax!oxy!bagpiper
Box 241 ARPA : oxy!bagpiper@csvax.caltech.edu
Occidental College BITNET: oxy!bagpiper@hamlet.bitnet
Los Angeles, CA 90041 CSNET : oxy!bagpiper%csvax.caltech.edu@relay.cs.net
------------------------------
From: sdsu!pnet01.CTS.COM!tiger@sdcsvax.ucsd.edu (Andre Johnson)
Subject: IBM H14
Date: 29 Jun 87 02:36:32 GMT
Organization: People-Net [pnet01], El Cajon, CA
Help!!!!!! I need to use the H14 call in the IBM bios but for unknown reason
the port\device Keeps timing out. I have been told all kinds of things
something wrong with the cables that I'm using, that god is not on my side all
kind things. What i'm trying to do is have one computer send charters using
the H14 call and receive charters on the other end with h14.
If you have any information on how to make this work it would be appreciated.
Tiger
[Use interrupt driven I/O as in any of our many communications packages. -wab]
------------------------------
Date: Mon, 29 Jun 87 23:02 EDT
From: <V111QQK8%UBVMS.BITNET@wiscvm.wisc.edu>
Subject: High-Res AT Graphics
We are looking for a high resolution (at least 700*700) graphics
card and monitor for use on an IBM PC/XT/AT compatible. They can be
either monochrome or color, BUT must satisfy certain critical
constraints. First, the phosphor on the monitor must NOT be of long
persistence type. Second, the brightness of the display should NOT
vary with image complexity (i.e. there should be even luminance across
the screen regardless of the number of characters present). We will
also require technical specifications and programming notes as they
will be controlled via machine language. The intended application will
involve rapid presentation of images, the average duration being 100
milliseconds.
One possible candidate might be a product called LASERVIEW from
SIGMA DESIGNS, but we don't have much information on it. If you know
more on this product or on any such products, please send a note to me
at the address given below.
John Hilton
UUCP : {cmc12,hao,harpo}!seismo!rochester!rocksvax!sunybcs!hilton
...{allegra,decvax,watmath}!sunybcs!hilton
CSNET : hilton@buffalo
ARPA : hilton%buffalo@csnet-relay
BITNET : hilton@sunybcs (or) v111qqk8@ubvmsc
------------------------------
Subject: Need help with MicroSoft Languages
Date: Mon, 29 Jun 87 21:58:14 -0700
From: Alastair Milne <milne%icse.UCI.EDU@ICSE.UCI.EDU>
To any experts in MicroSoft Pascal, C, and LINK:
I am a project manager for a U.C. project that creates educational
programs on micro's. For the last 5 years or more, we have been using the
UCSD p-System. But for our most recent project, we have been obliged to
use MS-DOS 3.1 (Japanese) on the Fujitsu FM-16Beta (Intel 80286). With
this, we are using MicroSoft Pascal (for all top- and mid-level routines)
and MicroSoft C (for device-level support). MicroSoft Pascal 3.31
was chosen primarily because it supplies a UNIT compilation module
syntactically similar to that of UCSD Pascal, supplying the same sort
of global, but private, referencing environment. For this reason,
dialects like Turbo Pascal, which has no such ability, didn't seem
feasible.
We are having a severe problem that didn't apply under the p-System,
so we have never had to solve it before:
- The code generated by MSPascal and MSC is huge.
- Our largest single UNIT, approximately 4000 lines of Pascal, is used
by every one of our programs. It compiles to about 16K of p-code under
UCSD. With MSPascal, the .OBJ file is almost 64K. I was well aware
that the native code would be larger than the p-code, but 4 times
is much more than I expected. Does 64K of code for 4000 lines
of Pascal sound reasonable to experienced MSPascal users?
- Each program uses 6 or 7 units. The one mentioned above is easily the
largest. Of the others, 2 are fewer than 500 lines, and none is over
1500. They are mostly Pascal, but a couple of them have perhaps 200
lines of C each. Each program itself is from 1500 to 2500 lines
of Pascal. The linked EXE files are between 160K and 200K. This
seems to me an incredible size, larger than PAS1 and PAS2 of the
MSPascal compiler put together.
I have tried EXE2BIN, to see if the code files could be converted
to smaller .COM files. EXE2BIN rejected the files as too big.
[.COM files must fit in one segment i.e. < 64K -wab]
Does anybody know if the MicroSoft linker (LINK, ver 3.51) is simply
copying entire pieces of library in, rather than resolving references to
individual units and routines?
Are we causing massive redundancy of support routines by mixing MSPascal
and MSC? If so, I'll be happy enough to turn most of the C source into
Pascal, and the remainder into assembly. However, we declare as
EXTERNs a few C routines to generate random numbers, and to chain to
other programs.
Do EXE files contain global data frames, or stack or heap space
within them? (We need at least an 8K stack to run.)
How efficiently does MSPascal store case tables, floating-point
constants, strings, and other structured constants?
- to try to reduce some of the redundancy of code on the disc (since every
program must contain its own complete copy of the code it uses from the
library), we have considered the possibility of making an entire chain
of programs into a single program, with the formerly separate programs
as UNITs within it, linked as overlays. But this presents another
problem. We must be able to abort cleanly any of the programs, at
any point within them. However, while we can easily enough abort
a whole program with ENDXQQ, aborting a specific scoping level
doesn't appear to be possible.
- Alternately, if we could keep the programs separate, but have only one
of them containing the library routines, we could both reduce
redundancy and exit easily from the individual programs. The problem
then is: how to produce EXE or COM files from OBJ files without
linking in all the libraries, and how to get them loaded and running,
using segments that have already been loaded when another program
was executed? Does anybody know if such a thing is possible?
If further detail is needed on any of these points, I'll do my best to
oblige.
I am also open to suggestions of other languages whose syntax includes
modules: Modula-2 and Ada are two that spring immediately to mind,
though I doubt very much whether there's a respectable, reliable Ada
for the FM-16.
Thanks in advance for any assistance.
Alastair Milne,
Project Manager,
Educational Technology Center,
U. of Calif., Irvine
------------------------------
Date: 1 Jul 1987 15:18:46 PDT
Subject: Microsoft Pascal Compiler
From: Richard Gillmann <GILLMANN@C.ISI.EDU>
To: milne@icse.UCI.EDE@ICSE.UCI.EDU
I have been using the Microsoft Pascal compiler for several years now.
I'm currently using version 3.30. I also have 3.31 and 3.32 but I've found
that they don't work reliably for me when compiling large programs. When
the .OBJ files start to reach 20K or more, I find myself running into
the size limitations of the compiler. Sometimes it gives an out
of memory error, sometimes it just compiles bad code. I've found that
the number of symbols in use is more of a problem than code size. There
are some hints in the manual on how to deal with large programs and these
should be taken seriously: using shorter identifiers, etc.
I also mix in a little Microsoft C code and Microsoft assembler code,
so far without any problems. One thing you must be careful to do is
to test your program on an AT without an 80287. For this case, it
needs the environment variable NO87 set to any non-empty string, or else
the program will not do arithmetic correctly.
One way to reduce code size somewhat is to use the /E option on the
linker, or else use EXEPACK which is equivalent. But the total sizes
you mention sounds typical. As far I know, it only takes what it needs
from the library.
I have only used Turbo Pascal a little because last time I checked it
did not allow you to have a program >64K not did it allow you to
use all the memory, as MS Pascal does.
A 160K program should be no problem in any case, since almost all users
have 640K these days.
Richard Gillmann
Inner Loop Software
------------------------------
Subject: Widely Used Tools on Various Hosts
Date: Wed, 01 Jul 87 11:38:49 -0400
From: howell%community-chest.mitre.org@gateway.mitre.org
I am interested in information on widely used tools that are
available on a variety of hosts. For example, EMACS-based editors
are available for a wide range of UNIX hosts, for micros running
MS/DOS, and I believe for VAX VMS. Scribe is also available for
several different operating systems. What other machines/OSes does
Scribe or EMACS run on? What are other examples of tools that run on
various operating systems? I imagine there are a number of examples
from the microcomputer world (e.g. Lotus on a variety of OSes).
I'm interested in a wide definition of "tools"; for example, I
would consider the availability of TCP/IP on UNIX and VMS, or the
availability of NFS on UNIX and PCs, to be good examples.
Please send to me; I'm not on all of the lists I've mailed to.
I'll summarize all responses received by 10 July and redistribute
to all mailing lists.
Thanks,
Chuck Howell
ARPA: howell@mwultrix.arpa or
howell%community-chest.mitre.org@gateway.mitre.org
------------------------------
Date: Mon, 29 Jun 87 21:57:08 CDT
From: Esmail Bonakdarian <bonak%cs.uiowa.edu@RELAY.CS.NET>
Subject: ps2/50 & External 5.25 drive
A good friend of mine just purchased a IBM ps2/50 with a hard drive
and micro floppy drive. In order to be able to read and write from
regular floppies (5.25inch) She is considering buying an external
5.25 drive. anybody out there have any suggestions about
this idea and recommendation about hardware to purchase?
thanks in advance.
E. Bonakdarian for R. Brimmer
------------------------------
Date: 30 Jun 1987 12:41:57 PDT
Subject: ps2/50 & external 5.25 drive
From: Billy <BRACKENRIDGE@C.ISI.EDU>
To: Esmail Bonakdarian <bonak%cs.uiowa.edu@RELAY.CS.NET>
Our first PS2 just arrived. We bought IBM's 5.25 disk option so we could
use this machine to transfer files to the new 3.25 1.44 MB mini-disks.
IBM did a great job of engineering with their plug together PS2.
Installation of anything is very easy. The only problem with the
5.25" disk is that it takes up a slot. There are only three expansion
slots in the model 50 PS2. It seems a shame to waste one for a floppy
drive.
The automatic reconfiguration program is very easy. After plugging in
the floppy drive you run the reconfiguration program. It senses that
a new device has been added to the system and knows exactly what the
device was. This is much simpler than the old DEVICE= parameter in
config.sys that older versions of DOS seemed to need in profusion.
The PS/2 doesn't seem much different from a 16 Mhz AT clone as far as
perceived performance is concerned. The keyboard sucks. I am 6' 5"
and have large hands. The keys are tiny yet a reach for the ALT or
esc key would strain a concert pianist.
------------------------------
Date: Wed, 1 Jul 1987 13:25 CET
From: ACESTAB%HUTRUU0.BITNET@wiscvm.wisc.edu
Subject: Turbo Pascal and Hercules
I am using a PC with a Hercules (clone) graphics board and
I am very interested in a series of (as low-level as possible)
routines that i can use instead of the graphics that come with
Turbo Pascal. The Turbo graphics don't work with my card. Is there
anyone who can help me with this (perhaps outdated) question?
Bert Stals (ACESTAB@HUTRUU0.BITNET)
------------------------------
Date: Sat, 27 Jun 87 17:00:14 +0300
From: Moshe Raccah <VSMOSH%WEIZMANN.BITNET@wiscvm.wisc.edu>
Subject: Turbo C and CodeView
Is it possible to use MicroSoft's symbolic debugger "CodeView"
on compiled Turbo-C code?
------------------------------
Date: Tue, 30 Jun 87 16:18 EDT
From: GERBER%temple.edu@RELAY.CS.NET
Subject: Appointment Calendars
Please reply if you get this. I too have been looking for a good
appointment calendar. Let me tell you what I don't (and do) like
about the available calendars:
Word Perfect Library:
Good: Resident alarm to remind you of appointments, to-do list, unlimited
text size for description, marks conflicting (overlapping) appts.,
easy to enter and print data
Bad: Hard to move data, no repeating meetings (every Friday at 10 for ex.)
doesn't print in "Calendar" format, not resident for entering data
can't handle more than 1 person (can't schedule group meetings)
Sidekick:
Good: Resident, easy to enter data
Bad: No alarms, hard to move data, no group functions, poor printing w/o
Travelling S/K, easy to make mistake entering data erasing a just
entered meeting (arrow key instead of RETURN)
Metro:
Good: Resident, easy to enter data, weekly meetings, resident alarm
Bad: Metro crashes several common programs, no group functions,
alarm is sound only, easy to ignore, takes up too much memory
Have you found anything worthwhile? I'm using Word Perfect libr.
until something better comes along.
------------------------------
Date: Thu, 2 Jul 87 23:54:52 EDT
From: <rbw@williams.edu>
Subject: Turbo Pascal 4.0
Has anyone heard about TP 4.0 yet? In the Turbo Prolog manual they
said that they were going to release TP 4.0 by second quarter '87, and
it would be capable of producing relocatable code.
-Richard
rbw@cs.williams.edu
89RBW@williams.bitnet
------------------------------
Date: Wed, 1 Jul 87 14:01:54 EDT
From: Clif Sothoron <cbsoth@BRL>
Subject: Book Wanted on File Formats
Someone mentioned a while ago that a book on file formats was
available. This book was to have included the internal structure of
Lotus worksheet(.wk1 or .wks), dBASE III+(.dbf) ,.dif files and others.
I am writing C programs that would read these type of files. Does anyone
know where I can obtain this book?
Thanks in advance,
Clifton B. Sothoron Jr.
Ballistic Research Laboratory
Aberdeen Proving Grounds, Md.
cbsoth@brl.mil or cbsoth@brl.arpa
------------------------------
Date: Fri, 3 Jul 87 12:31 EST
From: Joshua D. Males <josh%ILJCT.BITNET@wiscvm.wisc.edu>
Subject: Interrupt 17
When using interrupt 17H with 0 as a parameter, if the printer is out of paper
or off-line, etc... the computer pauses for about 30 seconds before returning
from the interrupt. Is there any way to shorten this delay? I am calling this
interrupt from Turbo Pascal. I tried checking the status (parameter=2) before
I send the character, but it doesn't always work, 'cause the status may change
between the check and the actual sending.
Are there any interrupt 17H experts out there that can help me?
Thanks,
Joshua D. Males
Jerusalem College of Technology
21 Rechov HaVaad HaLeumi
Givat Mordechai, Jerusalem
ISRAEL 91160
josh@iljct (bitnet)
------------------------------
End of Info-IBMPC Digest
************************
-------