Info-IBMPC@B.ISI.EDU (Info-IBMPC Digest) (09/29/86)
Info-IBMPC Digest Monday, September 30, 1986 Volume 5 : Issue 88
Today's Editor: Richard Gillmann
Today's Topics:
Floppy head step rate zap
DOS command line editing (3 msgs)
CGA/EGA/PGA/MDA/HERC cards (2 msgs)
Manipulating the DOS Environment (2 msgs)
GEM and External 3.5" drive
REFORMAT and DOS 3.2
Upgrade to Microsoft C v4.0
MSDOS Encyclopedia
FCOMP.C Use
Satellite tracking program
Today's Queries:
TROFF for HP Laserjet+ Query
New keyboard with 123 Query
Zenith 158 with 768k Query
Resident Programs Standard Wanted
Path change in DOS 3.2 Query
Com3 Com4 Query
HP Vectra Query
Tecmar Hard Disk Query
----------------------------------------------------------------------
Date: Sun, 28 Sep 86 02:18:48 CDT
From: CCRJW%UMCVMB.BITNET@WISCVM.WISC.EDU (Richard Winkel UMC
Computing Services)
To: INFO-IBMPC@USC-ISIB.ARPA
Subject: Floppy head step rate zap
>Does anybody have a head-settle patch for IBMBIO.COM for DOS 3.10? I've
>found one for DOS 2.10, but it seems that 3.10 is just as slow as all of
>them (except DOS 1.1).
I don't know of a patch for IBMBIO 3.1, but I can tell you how to zap
the bios diskette parameter table to achieve the same effect. This
zap is independent of the dos version.
The vector for INT 1E points to the diskette parameter table, and the
head step rate (which is actually what you're after) is in the first
nibble of the byte at offset 0 in the table. The default step rate is
'C' (12), and 'E' (14) seems to be a good replacement value. If you
are well versed in DEBUG, you can enter the following program using
the assemble command:
-A 100 ; start assembling at offset 100H
XOR AX,AX ; get to the bottom of memory
MOV DS,AX
LDS DI,[78] ; put the INT 1E vector into DS:DI
MOV BYTE PTR [DI],EF ; move in the new value (second nibble is always F)
MOV DL,0 ; reset diskette system to load new parms
INT 13 ; do the reset
INT 20 ; exit
<null line>
-N FASTDISK.COM
-R CX
:18
-W
-Q
That's it!
------------------------------
To: ya'akov_miles%ubc.mailnet@mit-multics.arpa
Cc: info-ibmpc@usc-isib.arpa
Subject: re: DOS 3.2 and ugly Ctrl-U (and Esc) behaviour
Date: Fri, 26 Sep 86 12:06:52 -0500
From: Mark Colan <mtc@ATHENA.MIT.EDU>
I agree with your complaints, and currently use DOS 3.10 because of the
missing ^U. Incidentally, I have heard that not all DOS 3.10's
have that ^U feature enabled.
I would like to clarify one point, though:
> The PC-DOS recall feature F3 is pathetic. There is no way to edit
> the middle of a long command line other than to delete all the
> characters after the one you want to edit
There actually is, sort of. The DOS quick ref card lists the other
editing keys that are available:
DEL Skip one char in retained line
INS Toggle - insert characters mode
F1 or -> Copy and display one char from retained line
F2 Copy all chars up to specified char
F3 Copy all remaining chars from retained line
F4 Skip all chars to specified char of retained line
This is easier to understand by example:
To transform the command:
copy dos310.c \usr\src\foobar
into
copy badedit.c \usr\src\foobar
1. either press -> five times, or type F2 then "d". DOS sez "copy ".
2. use either of these two methods:
a. type "badedi", press INS, "t", and F3
b. press F4 then ".". Press INS, type "badedit", and F3
Similarly, to change
copy ugliness.c \hope\dos\gets\better
to
copy broken.c \hope\dos\gets\better
1. either press -> five times, or type F2 then "u". DOS sez "copy ".
2. use either of these two methods:
a. type "broken", press DEL twice, and F3
b. press F4 then ".". Press INS, type "broken", and F3
Clearly, this is kludgey as heck. I'm not going to try to defend
something as ugly as this, but I DO use it, and I find it superior
to un*x in this respect: the csh has only very limited recall facilities,
in which you have to type ^old^new to make one substitution; I have
yet to figure out how to make it do two substitutions. I certainly
prefer the "direct manipulation" approach that DOS has, but I've
seen better (and MUCH worse).
Mark Colan
MIT Project Athena
------------------------------
Date: Fri, 26 Sep 86 12:49:48 PDT
From: Jim Anderson <bilbo.jta@LOCUS.UCLA.EDU>
To: info-ibmpc@b.isi.edu
Subject: DOS command line editing
In vol. 5 issue 27 of info-ibmpc Ya'akov Miles complained about DOS 3.2
command line editing. I would like to recommend PCED from Cove Software
Group. It costs $35 and, in my opinion, is well worth the price. Accept
no substitutes, such as DOSEDIT. I am not associated with Cove Software
Group, but am a VERY satisfied user of PCED.
Cove Software Group
P.O. Box 1072
Columbia, MD 21044
(301) 992-9371
------------------------------
Date: Mon 29 Sep 86 12:29:18-CDT
From: Pete Galvin <CC.GALVIN@R20.UTEXAS.EDU>
Subject: Re: DOS 3.2 and ugly Ctrl-U (and Esc) behaviour
To: Ya'akov_Miles%UBC.MAILNET@MIT-MULTICS.ARPA
cc: info-ibmpc@B.ISI.EDU
Since DOS 3.2 continues in the tradition of the other DOSes by not
having a nice command interface, I use the PD (shareware?) program
CED. It does all you want and more (except for ^U).
--Pete
------------------------------
Date: Fri 26 Sep 86 08:23:13-PDT
From: David John Buerger <D.Buerger%SCU%PANDA@SUMEX-AIM.ARPA>
Subject: NEC CGA/EGA/PGA card
To: info-ibmpc@USC-ISIB.ARPA
In reply to Clif Sothoron's request for info on a CGA/EGA/PGA compatible card
to work with his NEC Multisync monitor, NEC just announced such a card to work
with their own product. Of course the "PGA" emulation won't be quite as nice
as the true product, but the cost is reasonable (about $750 list) enough. Call
NEC for more info.
David J. Buerger
Director, PC Center, Santa Clara University
Dave%SCU%Panda@SUMEX-AIM.ARPA
------------------------------
Date: Mon, 29 Sep 86 8:55:38 EDT
From: Clif Sothoron <cbsoth@BRL>
To: info-ibmpc@usc-isib.ARPA
Subject: Quadram EGA+ Board
We have been using Quadram EGA+ boards and they work great. They
emulate EGA/CGA/MDA/HERC applications. I have not tested the Hercules
and mono stuff because I have an enhanced color monitor. The emulations
are switched via software. I like controlling them via batch files.
There is even a screen turn-off utility available. This board includes
256KB of on-board RAM and a decent manual. It works with a NEC Multisync
monitor as well. That is another fine piece of hardware (800/560
resolution).
Enjoy,
Clifton B. Sothoron Jr.
Ballistic Research Laboratory
Aberdeen Proving Grounds, Md.
------------------------------
Date: Fri, 26 Sep 86 18:03:34 cdt
From: Peter Wu <pwu@unix.macc.wisc.edu>
To: info-ibmpc-request@mosis
Subject: Re: SETENV.C
Author of setenv.c asked how to find the length of DOS's environment.
This is done by looking at the memory block header of the DOS
environment block.
Also, a better way to look for the DOS environment block is to
trace the segment portion of the terminate address back until
you find a segment whose terminate address points to itself.
This is DOS. The next following memory block is DOS's environment.
The program input.c in info-ibmpc library uses this idea and
does the same thing (accept string and store into dos
environment). I wrote this awhile ago and submitted it eagerly
(to show off the neat trick) but never find any use for it since then.
peter
uucp: {akgua|allegra|harvard|seismo|topaz|ucbvax}!uwvax!uwmacc!pwu
arpa: pwu@unix.macc.wisc.edu
bitnet: WU at WISVMACC
------------------------------
Date: 28 Sep 86 11:07 EST
From: DIXON WALTER V <DIXON@ge-crd.arpa>
Subject: Manipulating the DOS Environment
To: Info-IBMPC@B.ISI.EDU
The question of changing environment variables from within a
program has come up several times. There was a posting of SETENV.C
in the last digest which did this, but it required PATH varaible to
be set. I have also created a program to do this which relies on
a "semi-documented" dos hook. This posting includes two routines
getenv and setenv for manipulating the master environment as well
as a utility for using "logical names" to manipulate the path value.
The fundamental problem in manipulating the environment is that
dos passes a copy of the environment to a program when it starts up.
Most respectable C compilers have a library routine which will mani-
pulate this environment, but any additions/deletions are undone
when the program exits. If these programs in turn spawn (fork) other
programs, the child programs are passed their parent's environment.
There are two problems with mainpulating the DOS "master" environ-
ment -- finding it and expanding it. Finding the master environment
is fairly easy, but the only way I can see to expand it is to hack up
COMMAND.COM.
The environment is a table whose starting segment is stored in the
PSP at offset 2CH; unfortunately, this is a copy of the DOS environment.
Location 14H in the PSP is the starting segment of the parent process
PSP. In most cases the parent process is command.com. If multiple forks
have been performed, this location will form a linked list which can
be traced back to the original copy of command.com. In many ways command.com
is another process with its own PSP; however offset 2CH in its PSP is 0.
When command.com starts up, it allocates a block of memory to use as the
environment and stores the size and starting paragraph internally. If one
were willing to hack on command.com or depend on knowing the location of
these variables (environment size and starting segment), it becomes a
simple matter to alter the environment contents and size.
The DOS tecnincal reference manual states that the address of the
environment is passed when a program is loaded (INT 21H AH=4BH). The
load routine copies this environment in the course of making the program
memory resident. Thus it is possible to determine the starting segment
of the master environment by trapping load requests.
The code which follows includes a terminate and stay resident program
which monitors program loading and a routine for manipulating the master
environment. Also included in this posting is a utility which uses these
routines to manipulate the DOS path variable.
[GET.C has been added to the Info-IBMPC library. -rag]
------------------------------
Date: Mon, 22 Sep 86 09:00:13 edt
From: Ted Cooley <tedc%dartmouth.edu@CSNET-RELAY.ARPA>
Subject: GEM and External 3.5" drive
To: info-ibmpc%usc-isib.arpa@CSNET-RELAY.ARPA
A have at least fixed the two problems I mentioned earlier:
1) GEM hangs IBM-XT runnings DOS 3.20
2) External 3.5" IBM drive does not format to 720kbytes.
In the GEM problem, I was finally able to get GEM to run if I
_DO NOT_ run device = vdisk in the config.sys file. Apparantly, vdisk
is located at the same memory locations as one of the device drivers for
GEM... I have not tried to make the virtual disk, say, 100kbytes to see
if size is the issue. If reducing the size of the vdisk does permit GEM to
run, I'll report it here.
As for the external 3.5" drive, I have had two now, both of which
have been flakey from time to time... "Can't write Boot sector", etc. The
other problem was that I had not setup the device drivers properly. I had
changed the switch settings on the mother board rather than only installing
a new device driver. Be forwarned: defaults are not always what you expect.
I hope that this information will help someone out there. It is clear
that not many others have been using this combination of s-ware and h-ware.
Regards,
Ted Cooley
Thayer School of Engineering
Dartmouth College
Hanover, NH 03755
tedc@dartmouth.edu
...seismo!harvard!dartvax!tedc
------------------------------
Date: Fri, 26 Sep 86 10:40:15 MET
To: INFO-IBMPC@USC-ISIB.ARPA
From: U001222%HNYKUN11.BITNET@WISCVM.WISC.EDU
Subject: REFORMAT and DOS 3.2
REFORMAT has now been tested on several machines running DOS 3.2.
It works perfectly. So anybody with DOS 3.2 should change line 981
in the file REFORMAT.IN5: '..... ah > 10 ..' to '.....ah > 20 ...'.
Doeg,
Jos Wennmacker
Universitair Rekencentrum
Geert Grooteplein Zuid 41
NL-6525 GA Nijmegen
The Netherlands.
[The library copy has been updated. -rag]
------------------------------
Date: Fri, 26 Sep 86 06:37:28 cdt
From: mlw@ncsc.ARPA (Williams)
To: info-ibmpc@usc-isib.ARPA
Subject: Upgrade to Microsoft C v4.0
I was surprised to get an upgrade offer and order form for MS-C, v4, since
I bought MS C, v2 (i.e., Lattice) some time ago and never upgraded it.
However, a standard MS upgrade notice w/order form reached me (at a NEW
work address!), so I believe that's still they're approach to offering
upgrades at reduced prices. I certainly hope everyone who's eligible
gets their upgrade offer through the mail -- I usually suffer migraines
and rashes any time I try to talk w/MS folks on the phone :-)
Mark L. Williams
(mlw @ ncsc.arpa)
------------------------------
Date: Friday, 26 Sep 1986 08:24:41-PDT
From: watson%akov04.DEC@decwrl.DEC.COM
To: info-ibmpc@b.isi.edu
Subject: MSDOS Encyclopedia
I saw a copy of the long awaited "MSDOS Encyclopedia" at a computer book store
in the Boston area the other day. I was told that it sold for $140.00 but was
not for sale because Microsoft had recalled the entire edition. I convinced
the salesman to let me have a look at it anyway and would like to comment on
what is actually in the book. I was mostly disappointed in the book as it does
not contain much new, previously unpublished information. The first third is
devoted to DOS commands and utilities and is mearly an expanded description of
the DOS users manual. The rest is descriptions of DOS calls, all of which are
documented in the MSDOS Programmers Guide allready. The one nice thing about
the book was the flow charts included to diagram the DOS functions code. In
my mind, this is not sufficient justification for the high price tag.
I don't know why the book was recalled and the salesman said he had not been
able to find out from Microsoft himself. Also, he did not know when the book
will be released again (if ever).
------------------------------
To: info-ibmpc@usc-isib.ARPA
Subject: FCOMP.C Use
Date: Sun, 28 Sep 86 21:57:13 -0500
From: James R. Van Zandt <jrv@mitre-bedford.ARPA>
ciaraldi@rochester.arpa recently reported:
> I recently grabbed FCOMP.C from the info-ibmpc archives
> at usc-isib, and ran into a few very minor problems...
> ...I also got "stack overflow" when using Lattice C, and
> was never able to find a stack size big enough to let
> it run.
I borrowed a Lattice compiler and ran into the same problem. It's
because FCOMP allocates these big arrays from the stack:
/* for each diagonal, two items are saved: */
int last_d[2*MAXLINES+1]; /* the row containing the last d */
struct edit *script[2*MAXLINES+1]; /* corresponding edit script */
I first fixed the problem by moving the declarations outside main to
make them global variables. However, this made the .exe file much
larger (parhaps due to my old version of link: 2.44). I eventually
allocated the arrays from the heap using malloc().
> ...This means you can only compare files up to about 16K
> bytes in length each, since both files and some scratch space
> are held in memory.
I have to apologize...I had modified FCOMP to save only a hash code for
each line, but never uploaded the new version. This increased its
capacity somewhat, but I stillran out of memory pretty often. I've
been looking forward to getting it compiled with a larger memory model.
Using the small code/large data memory model of the Lattice compiler,
much more memory is available for the "edit scripts" FCOMP uses to keep
track of the file differences. That's the good news. The bad news is
that the capacity only grows as the square root of the available
memory. If there are N differences between two files, approximately
(N+1)*(N+2)/2 edit scripts are required. For 2 times as many file
differences, you need about _4_ times as much memory. The two versions
of FCOMP work like this on my machine:
version DeSmet Lattice
(small/small) (small/large)
# edit scripts 3459 9033
# file differences 82 133
.exe file size 15360 21612
For comparison, chkdsk reports "786432 bytes total memory 200352 bytes
free" on my Z-100.
Incidently, I wasted quite a bit of time before I realized that the
DeSmet and Lattice versions of lseek() have different calling
sequences. I'm now using fseek(), which is the same under both.
I'm appending the new version of FCOMP to this message.
- Jim Van Zandt
[FCOMP.C has been updated. -rag]
------------------------------
Date: Mon, 29 Sep 86 9:32:05 EDT
From: Brian Vaughan <vaughan@labs-b.bbn.com>
To: INFO-IBMPC@b.isi.edu
Subject: Satellite tracking program
There is an article called "TI-59 program tracks satellites in elliptical
orbits" in the October 6, 1981 issue of Electronics, page 146. The author's
name is Janos Molnar from Siofok, Hungary.
------------------------------
Date: Thu, 25 Sep 86 15:31:49 EDT
From: Clif Sothoron <cbsoth@BRL>
To: info-ibmpc@usc-isib.ARPA
cc: keller@BRL, pbaer@BRL, fickie@BRL
Subject: TROFF for HP Laserjet+ Query
Does anyone know of a port of TROFF to the IBM PC-AT with support
for the Hewlett-Packard Laserjet+ running PC-DOS? I know that Addison
Wesley supports TEX for the AT but we already have lots of UNIX TROFF
formatted files. Interesting thought, does anyone know of a program
that converts TROFF formatted files to TEX formatted files? This would
be an acceptable alternative as well.
Thanks in advance,
Clifton B. Sothoron Jr.
Ballistic Research Laboratory
Aberdeen Proving Grounds, Md.
------------------------------
Date: Fri 26 Sep 86 14:46:58-PDT
From: Ted Shapin <BEC.SHAPIN@USC-ECL.ARPA>
Subject: New keyboard with 123 Query
To: info-ibmpc@B.ISI.EDU
Are there any patches to use the cursor keys on the new IBM keyboard
(IBM # 1390120) with Lotus 123. We would like to enter digits on the
digit keypad and use the cursor keys to move the cursor. The scan codes
must be different as Lotus doesn't seem to recognize the cursor keys.
------------------------------
Date: 26 SEP 1986 14:27 EDT
To: <INFO-IBMPC@USC-ISIB.ARPA>
From: Kenneth R. Van Wyk <LUKEN%LEHICDC1.BITNET@WISCVM.WISC.EDU>
Subject: Zenith 158 with 768k Query
All Z-158 computers can hold 768k of RAM, but the operating system
only recognizes 640k of it. Does anyone out there know of a way that
this additional 128k of RAM can be used as a RAMdisk? Sure hate to
see it go to waste...
Ken Van Wyk
<LUKEN@LEHICDC1.BITNET>
------------------------------
Date: Sat, 27 Sep 1986 23:10 PDT
From: "Jeffrey Sicherman" <JAJZ801%CALSTATE.BITNET@WISCVM.WISC.EDU>
Subject: Resident Programs Standard Wanted
To: <INFO-IBMPC@B.ISI.EDU>
Has any document, written standard, or software come out of the recent
Microsoft, Borland, et.al. conference on keyboard stealers and
resident programs ? If so, how may it be obtained ?
------------------------------
Date: Sun, 28 Sep 86 13:13 PDT
To: Submit to Info-IBMPC <info-ibmpc@usc-isib.arpa>
From: Todd Booth 213-825-1933 <CSDCTGB@UCLA-CCN.ARPA>
Subject: Path change in DOS 3.2 Query
With DOS 3.1 the following will add c:?newdir to the current path:
set path=%path%c:?newdir
However with DOS 3.2 it does not. Does anyone have any suggestions
or available programs?
todd
------------------------------
Date: Mon, 29 Sep 86 9:47:48 EDT
From: Brian Vaughan <vaughan@labs-b.bbn.com>
To: info-ibmpc@b.isi.edu
Subject: Com3 Com4 Query
I have purchased an EVEREX modem for the AT. The manual says it can be
set to the address location for com1, com2, com3, or com4. Out of interest,
if the following I/O addresses are true:
com1 3F8 - 3FF
com2 2F8 - 2FF
where is: com3 ??? - ???
com4 ??? - ???
Thanks in advance.
------------------------------
Date: 29 Sep 1986 10:56-EDT
Subject: HP Vectra Query
From: HARDY@A.ISI.EDU
To: Info-IBMpc@B.ISI.EDU
I would like to hear from anyone who has used the Vectra by HP. Good/Bad
comments on
How it works
3Com file sharing
3Com plus file sharing
DBase III Plus and 3Com file sharing
Any experence with problems when tring to use memory in the 636k to 640k
area?
Rich.
------------------------------
Date: Mon, 29 Sep 86 15:21:41 EDT
From: Stephen Wolff <steve@BRL.ARPA>
To: info-ibmpc@usc-isib.arpa
Subject: Tecmar Hard Disk Query
Help! We have a Tecmar hard disk full of non-backed-up data that
refuses to be found after a system restart. The operating system
(DOS) produces the message "Unable to Access Hard Disk". Has anyone
coped with this before? Does anyone know of a utility that would
allow us to retrieve the info on the disk or to rebuild its directory?
------------------------------
End of Info-IBMPC Digest
************************
-------