Info-IBMPC@B.ISI.EDU (Info-IBMPC Digest) (09/21/86)
Info-IBMPC Digest Sunday, September 21, 1986 Volume 5 : Issue 86
This Week's Editor: Eliot Moore <Elmo@B.ISI.Edu>
Today's Topics:
Orchid PCturbo-286e
Vertical and vertical
Re: Problem with IBM Graphics Printer
Scientific subroutine Package
SIM3278
DisplayWrite 3
U.S. Designs
MV bug
Orchid Tiny Turbo
NOTROJ--it IS a trojan
Slow Garbage-Collector in BASICA
Call for Papers - 1987 Academic Microcomputer Conference
SCSI Host Adaptors
Today's Queries:
Personal Fonts for Cordata Printer
Qmodem
Microsoft C V4.0
Industrial Dynamics Simulation Modeling Tool
Cache on a Network
EGA Drawing Program => Postscript Query
HP 150 with "Carbon Copy" or "REMOTE"
Fastback
Personal Computer Support Group (PCSG)
DOS Disk Sector Size Constraints
----------------------------------------------------------------------
Date: Tue, 16 Sep 86 07:15:57 cdt
From: mlw@ncsc.ARPA (Williams)
Subject: Orchid PCturbo-286e
Got a new complication for my PC/XT and thought I'd send along a
review...
The original box: PC/XT w/256K motherboard RAM, IBM 256K RAM memory
expansion, IBM asynch adapter, standard IBM disk controllers, IBM
EGA w/piggyback board, Tall Tree JRAM-3 w/2 Mbytes RAM, clock/calendar,
serial, & parallel port.
The newcomer: Orchid's PCturbo-286e card w/daughterboard, yielding 2
Mbytes of 16-bit, no wait memory and an 80286 processor running at
8 MHz. Supposed to have an 8 MHz 80287, but the distributor sent a
5 MHz model instead, so that's being exchanged.
The challenge: you guessed it -- to make everything work and live to-
gether happily. Or at least civily.
Ridiculous situation 1: IBM EGA piggyback board. If anyone doesn't know,
the IBM EGA is a full-length card that comes with 64K on the basic card.
If you wish to expand to 128K or more, you have to get a piggyback card.
The card mounts easily and is held securely, but by what!? By these
L O N G plastic pins that make it impossible to put another card
"behind" the EGA. So...move the EGA to slot 1 and relocate the JRAM
card that used to be there.
Ridiculous situation 2: Slot #2. Place the PCturbo card in slot #2.
See how it won't come close to seating. Discover that you're mashing
the *!## out of the speaker connection on the motherboard, which is
vertically oriented and interferes with any wide card design targeted
for that slot. So...introduce a low-profile connector by bending the
connector leads to a vertical plane.
Now you're ready for business. Discover that the PCturbo wants some
specific routes to the host's memory and i/o areas (adequately docu-
mented in the manual). Search through the JRAM manual to discover
possible conflicts, etc. Brilliantly decide to set the PCturbo to
utilize IRQ5, which you later discover is the XT hard drive interrupt.
Oops. Thrash and thrash with the JRAM boot and JDRIVE software to
try to get everything going. Come REAL CLOSE a couple of times.
Finally, call Orchid. Nobody's there yet (a real problem for folks
in Eastern & Central time and all the computer companies in the world
in California). They take a message. They'll call back. Sure. OK.
EXPLETIVE!! They call back in less than 20 minutes! Carol suffers
through a variation of the song and dance above and makes suggestions.
I decide that I like most of them, but will implement them in a
piecemeal manner, hoping that I don't have to disassemble the PC
again. Hope against fact, there.
Now, for all of you who may want to add a PCturbo-286e to your
system with a JRAM card, here's what I finally ended up with. It's
working now and I hope it'll be stable.
Hardware: set the PCturbo for I/O address 208H (described in manual
and NOT the default, which is 300H)
select Host Interrupt Line IRQ2 (which is not covered in
the manual. If you really want to know, write me or
ask Orchid).
DO NOT blindly follow the manual and its references to the
daughtercard jumpers -- that information is superceded
by the installation info that comes with the daughter-
card itself, which is correct. Basically, you don't
have to change any jumpers to accommodate the daughter-
card if you plan to use it in EMS mode and not in full
protected-memory mode, which is likely with today's
products.
Software: boot from a plain-vanilla DOS diskette, thereby suppressing
the installation of the JRAM device drivers.
run the Orchid installation program (which, incidentally,
looks at the PATH statement in the AUTOEXEC.BAT file and
adds a new path element if it's not there already)
retain the default address of dual-port memory at E000:0.
complete the installation by identifying the changes you made
to the jumpers.
Configuration: edit the file turbo.sys, which acts like config.sys for
the turbo processor. Add your memory-resident utilities,
etc. The turbo is a true coprocessor and must have its
own copies of things like SIDEKICK, etc.
for safety's sake (may not really be required), add an argument
X=14 to the JBOOT.BIN device driver invocation, thus
precluding conflicts between JRAM & PCturbo.
review your autoexec.bat, hostexec.bat, and turbexec.bat files
to be sure they have what you want.
add the DEVICE = RAMDISK.SYS... argument to the turbo.sys file
if you want a RAM disk on the turbo card (the manual ex-
plains adequately).
ATTACK!
The only thing Orchid told me that I haven't done yet was to put the
JDRIVE device driver in the turbo.sys file. I had tried something like
that earlier and didn't like what I saw, so I'm trying to leave it the
way I've described above. Things seem to be going OK so far. Now I
have access to the full 2-meg JRAM RAM drive (which receives all my
utility software on boot-up) and my 1-meg RAM drive (which gets special
stuff) from turbo mode, plus standard disk access, of course. The per-
formance is impressive. Directories flash by far faster than the eye can
see. Former stody programs react with zip. The poor hard drive is run
absolutely ragged if the program requires much disk access. WORD works
with reasonable responsiveness. The world is a rosy place. One can,
however, get the feeling that your computer is beating on you for a
response, rather than vice versa -- a strange and, at first, uncomfortable
situation.
To summarize: I find Orchid's PCturbo-286e to be a very satisfactory pro-
duct whose difficulty of installation is commensurate with the complexity
of the objective: to convert a single-processor system into a multi-
processor system. The manual is reasonably well-written and suffices
for a "no variations" installation quite well -- however, there are some
pitfalls that are not adequately documented. The software installation
is quite smooth, but final tuning must be performed by the user -- expecting
anything else is a but much, in my opinion.
Areas of concern: watch out for the concurrent coprocessing version of the
software. The manual warns you clearly about that, and I'd suggest you
heed the warnings. There is little doubt that the current version of the
software is capable of causing significant problems for the ordinary
user. Second -- the board has some pretty impressive heat sinks on a
couple of the ICs. I think I'm going to get a secondary fan to keep
from frying everything in my box. The PCturbo is warranted for 1 yr
(expandable to 2 yrs if you fill in & return your warranty card), but
I don't know if the rest of my components can stand the environment
in there.
If anything else exciting happens, I'll post it unless there's an over-
whelmingly critical mass review of this posting. If that happens, I'll
be closing the show on the road.
Mark L. Williams
(mlw @ ncsc.arpa)
------------------------------
Date: Tue, 16 Sep 86 07:25:07 cdt
From: mlw@ncsc.ARPA (Williams)
Subject: Vertical and vertical
My other message describing my adventures with the PCturbo-286e has an
error -- I said, in effect, that I bent the speaker connector leads from
a vertical orientation to a vertical orientation. Not much good, that.
Actually, I bent them from a vertical orientation to a horizontal one.
Much better.
Mark L. Williams
(mlw @ ncsc.arpa)
------------------------------
Date: Tue, 16-Sep-86 08:18:24 PDT
From: localhost!pelican!pete@csvax.caltech.edu (Pete Carah)
Subject: Re: Problem with IBM Graphics Printer
>The IBM Graphics Printer is giving me some strange problems while
>producing graphics on it. The problem occurs in the 960 Bit Image
>mode (ESC L, maybe on other modes too, this is the one I tried). If
>you send SUBs to the priner (hex 1A, dec 26) while in graphics it goes
>mad (Starts printing junk). This seems to be happening with other
>charaters as well but I didn't manage yet to find which. Any help
>with this problem would be appreciated.
This is not a problem with this printer, it is a DOCUMENTED (obscurely)
FEATURE of DOS. (It wasn't documented in 2.x, but a description was
added to the ioctl section of the DOS 3.x technical reference). I have
always considered it a bug, but have had NO RESPONSE AT ALL from anyone
at either Microsoft or IBM. What is happenning is that 1A characters
are omitted from the output stream, thus making the count of characters
sent to the printer wrong. It is especially bad if the count contains a
1A. The worst problem is that within the only language (basic) supplied
with DOS, there is NO WAY to print general graphics.
To avoid it using the DOS file mechanism, you have to open the device,
THEN set it into raw mode with an ioctl call. This will only work if
your language supports ioctl or a universal dos call mechanism of some
sort. Most graphics programs that I know of bypass the MSDOS file
mechanism completely and either call the ROM bios int 17 directly or
write directly to the hardware. With either of those methods, there
should be no problem.
-- Pete
{ihnp4|vortex|scgvaxd}!pelican!pete
------------------------------
Subject: Scientific subroutine Package
Date: Tue, 16 Sep 86 13:06:08 -0500
From: jcmorris@mitre.ARPA
The SSP was a Type 2 program IBM distributed in the 1960's to users of IBM's
OS/360, and was distributed in source. Since that was prior to the New
World days at IBM, I'm reasonably sure that the code was NOT copyrighted
and thus can be copied as required if you can find someone with a version
still in the archives.
As I recall the package was known to have several problem areas and was
considered to be a poor choice for critical or unusual applications, or
ones which required real accuracy.
Joe Morris
------------------------------
Subject: SIM3278
Date: Tue, 16 Sep 86 13:20:36 -0500
From: jcmorris@mitre.ARPA (Joe Morris)
SIM3278 is (and always has been) a commercial product of SIMWARE, Inc.
and is (hopefully) not on any bulletin boards. Their address is:
SIMWARE, Inc.
14 Concourse Gate, Suite 100
Nepean, Ontario, Canada K2E 7S6
Phone is (613) 727-1779
Their products are frequently advertised in mainframe-oriented publications
which would be likely to be read by VM installations.
Joe Morris (jcmorris@mitre)
------------------------------
Date: Wed, 17 Sep 86 09:40 N
From: <VOGT%HGRRUG5.BITNET@WISCVM.WISC.EDU>
Subject: DisplayWrite 3
I understand that a person named Carl is looking for a way to
pass Displaywriter documents to a PC (cf. message from Jeff Edelheit,
sep. 12, 1986)
Sending revisable document to and from a PC can be accomplished using
the following hardware and software:
Displaywriter hardware: 3705 Communications adaptor
software: 5608-SR2 Binary Synchronous Communication
PC hardware: 383120000022 (?) BSC adaptor
software: 383176000011 (?) DisplayComm
in between hardware: Modem eliminator to provide a clock signal
costs add to about Hfl 5000.-- (in the Netherlands)
Documents will be revisable on the Displaywriter (with Textpack 4 or 6)
and on the PC (with DisplayWrite 2 or 3, with WordPerfect and probably
with Framework II)
Regards,
Herman F. Vogt
Rekencentrum RU Groningen
Postbus 800
NL-9700 AV GRONINGEN
VOGT@HGRRUG5
------------------------------
Date: Thu 18 Sep 86 18:50:13-PDT
From: William Pearson <PEARSON@SUMEX-AIM.ARPA>
Subject: U.S. Designs
U.S. Designs is a independent assembler of DEC minicomputer
systems (MicroVaxII, 11/73) with Digital CPU and their disks and
controllers and cabinets. Check in a DEC magazine (Digital Review,
Hardcopy) for an address.
------------------------------
Date: Thu, 18 Sep 86 11:28:01 cdt
From: Peter Wu <pwu@unix.macc.wisc.edu>
Subject: MV bug
Hi, this is embarassing, but I have to tell you about a bug in MV
someone found out and told me after getting MV from info-ibmpc.
This bug occurs when you try to move a sub-directory (call it A)
into or out of another sub-directory (call it B) that is longer
than one cluster and when the sub-directory A is not in the
first cluster of sub-directory B. The bug can be generated by
the following sequence on a 360K floppy disk:
mkdir a
mkdir b
cd b
-- now create more than 32 files in directory b --
cd \
mv a b/a --- mv freaks out:
internal error in 'findir' ...
On an hard disk you would have to create at least 128 files in
sub-directory b to generate this bug.
I will try to fix this bug but in the mean time you can still use
MV because you are not very likely to run into this bug, and even
if you do it will not cause any harm to your disk, because no
disk write operation has taken place. Just that you won't be
able to move the sub-directory.
Sorry about this. And thanks Harry McGavran for pointing this out
to me.
peter
------------------------------
Date: Sat, 20 Sep 86 04:11:03 EDT
From: "James H. Coombs" <JAZBO%BROWNVM.BITNET@WISCVM.WISC.EDU>
Subject: Orchid Tiny Turbo
XT too slow but AT too expensive and 80386 is on the horizon? I just
got the Orchid Tiny Turbo. No problems after a week of heavy use.
Everything runs on it. Switch is handy when the machine hangs. Speed
increase is obvious. My prime motivation was to cut long compile times.
The program that drove me to it takes 4:05 with the 8088 and 1:44 with
the 80286. It works! --Jim
------------------------------
Date: Sat, 20 Sep 86 04:17:50 EDT
From: "James H. Coombs" <JAZBO%BROWNVM.BITNET@WISCVM.WISC.EDU>
Subject: NOTROJ--it IS a trojan
Distribute far and wide!
(C)Nobodaddy, 1986
A Story of a Trojan Horse
With Some Suggestions for Dismounting Gracefully
by
James H. Coombs
NOTROJ.COM is a TROJAN HORSE (comes in NOTROJ.ARC--for now).
I first became aware of NOTROJ when a member of The BOSS BBS community
reported his belief that the program destroyed the directory of his hard
disk. After two days of restoring his files, he concluded:
This Trojan was written by a real Pro---he knows his ASM and
uses it as a weapon---not a tool. From lokkin' at the job he
did on me, I tendto doubt that I would have found the bomb has I
been smart enough to look. ---PLEASE!!!!! Spread the word 'bout
this one. It's a Killer!
In the next couple of days, I saw a similar note on the Boston Computer
Society bulletin board. This victim rather pathetically credits NOTROJ
with a "valiant" attempt at saving his data.
The program in question is a time-bomb (about 10 minutes) and
works by the "SOFTGUARD UNFORMAT" method of attack. I'm not
sure what it did, or how it did it, or even how I could have
recovered the disk but the NOTROJ program I had in the
background alerted me to the fact, and tried a valiant attempt
to shut down the hard disk. To no avail, though.
Since my hard disk was becoming fragmented anyway, I decided to test
NOTROJ. Everything looked pretty reasonable from the start; in fact, the
program looks like a very useful tool (although I'm not in love with the
interface). One loads NOTROJ resident and then accesses the options menu
through Alt-N. The menu contains about fifteen items, some of them
annotated "DANGER", e.g., "Format track (DANGER!)". For each parameter,
the user can select one of four responses: Proceed, Timeout, Reboot, or
Bad Command. The menu also provides a fifth option--"Pause&Display"--
which provides the user with full information on the activity that the
currently active program is trying to perform and prompts for one of the
four primary actions, e.g, Proceed.
I selected "Pause&Display" for all of the DANGERous parameters.
Everything worked fine, although I found that iteratively selecting
"Timeout" in response to the "Write sectors" interrupt hung up the
machine. I fooled around with a number of commands and finally
reproduced the disk crash. At the time, I was running the DOS ERASE
command (I had been suspicious of that one for quite some time anyway).
I don't have the full message that the program displayed, but I did write
down this much "Softguard-style low-level disk format." (Keep those
words in mind.)
In spite of the fact that I had prepared for a disk crash, it took me at
least an hour to get running again. When I booted the machine, I was
thrown into BASIC and could not get back to the system. I put a DOS
diskette in, and got an invalid drive error message when I tried to
access the hard disk. Here is the recovery procedure for this and most
disk crashes:
1) Insert DOS system disk in drive A.
2) Reboot the machine.
3) Run FDISK and install a DOS partition on the hard disk.
4) Format the hard disk with the '/S' option.
5) Restore files from the most recent full-disk Bernoulli or tape
backup.
6) Restore files modified since the most recent full-disk Bernoulli
or tape backup.
Once I got a minimal system running, I decided to reproduce the crash to
ensure that this was not some quirk of bad programming. What, ho! I got
bored playing around with COPY and ERASE and a few other programs. I
waited for a while, read a magazine--no signs of a simple timing
technique. I began to think that NOTROJ might be more incompetent than
vicious. Something about the documentation made it seem unlikely that
the author was a criminal. It occurred to me, however, that the author
might have had some time to waste on this program. Does he, perhaps,
check to see how full the hard disk is? It would be reasonable to evade
detection immediately after a bomb by making it impossible to reproduce
the crash. In addition, it would be much more painful for people if they
have restored all of their files or gradually rebuilt their hard disks
before they discover that this is a trojan horse. So, I restored all of
my files.
This time, Norton's NU command turned out to be the great blackguard that
was trying to format my disk (according to NOTROJ--although it was only
reading the FAT). So, I restored my hard disk. All of the while,
however, I had the nagging feeling that the documentation did not reflect
the personality of someone vicious. When I got running again, I took a
look into NOTROJ.COM. Nowhere could I find the words from the message
"Softguard-style low-level disk format." That convinced me. I have
concealed passwords on mainframes by assembling strings dynamically
instead of storing them statically. Our trojanette must have used the
same technique so that no one would spot the suspicious messages. I had
counted on being able to get them directly from the program so that I
would not have to take the time to write the whole message down while my
system was being operated on. I do recall NOTROJ patting itself on the
back, however, for preventing "further damage."
As I think back on it, the documentation contains something of a rant
against copy-protection schemes, including Softguard. In addition, I had
always been troubled by the fact that the name NOTROJ is an acrostic for
TROJAN and also an assertion that the program is not itself a trojan.
The documentation is also very badly written. One has to experiment to
make sense of it, although that is nothing new in software documentation.
Also, the style is something of a pidgin English, which seems consistent
with the fact that the author has an Oriental name (Ng, or is that for
"no good"?). Well, since the author's name and address are listed in the
documentation, I decided to give him a call. Mirabile dictu! It's a
real name, and I got a real number--I just didn't get an answer, even at
2 a.m. It doesn't make much difference anyway, there's nothing that he
can say to convince me that he had legitimate reasons for concealing
error messages and that his program is not a trojan horse. There is also
the possibility that the person listed as author has nothing to do with
the program. Could the pidgin style of the documentation be the work of
a clever linguist--an acrostic fan--a sick person who considers himself
to be the bozo that Sherlock Holmes was always after? Who knows? I have
to write a book. No time to play with these fools.
So, be careful. Note that sysops don't have the time to test every
program extensively. If a program like NOTROJ requires that a disk be
more than 70% full, for example, a lot of people may never have any
problems with it. What else can we do? Does someone want to try to
prosecute the author of NOTROJ? And how do we keep ourselves from
becoming paranoid about new noncommerical software?
Eventually, I think it will all shake out just fine. Those of us who are
prepared for problems provide others with the testing and filtering.
Junk like NOTROJ just does not make it into my community. Actually, I
find mediocre software much more of a problem. I have spent a lot of
time and money sorting through megabytes of chaff to find but a few
grains of wheat. I would like to see us find some way to constrict the
growth of chaff and worms both. If we can't do this, many of us may
have to switch to commercial software.
--Jim
Replies may be made to:
BITNET: JAZBO@BROWNVM
BBS: The BOSS, BCS, Hal's, et passim
BIX: jcoombs
------------------------------
Date: Wed, 17 Sep 86 16:06 CET
From: Wolfgang Strobl <STROBL%DBNGMD21.BITNET@ucbvax.Berkeley.EDU>
Subject: Slow Garbage-Collector in BASICA
In Issue 84 KAPLAN@RED.RUTGERS.EDU reports a problem with BASIC's
garbage collector and asks for help:
> I would like to be able to program around this somehow. I have tried
> to avoid using temporary storage for string variables; I name each
> intermediate string result. (Am I making a mistake to do this?) I
Yes.
> thought this would keep the interpreter from proliferating lots of
> intermediate strings and thereby use up storage.
No. It's the other way round: with IBM'S/Microsoft's BASICA
temporaries don't produce garbage, string assignments do.
In order to demonstrate this, run the following short program:
+------------------------------------------------------+
I 10 PRINT"Part 1: temporaries don't produce garbage:" I
I 20 A$="Hallo":N=0:M=0:FS=0:B$="":FS=FRE(0) I
I 30 IF MID$(A$,2,3)="all" THEN N=N+1 I
I 40 PRINT ,N,FS-FRE(0) I
I 50 IF N<3 THEN 30 I
I 60 PRINT"Part 2: string assignments do:" I
I 70 B$=MID$(A$,2,3):IF B$="all" THEN M=M+1 I
I 80 PRINT ,M,FS-FRE(0) I
I 90 IF M<3 THEN 70 I
I 100 PRINT"Part 3: enforced garbage collection:" I
I 110 M=FRE(""):PRINT ,"back to",FS-FRE(0) I
+------------------------------------------------------+
This gives the following output:
+---------------------------------------------+
I Part 1: temporaries don't produce garbage: I
I 1 0 I
I 2 0 I
I 3 0 I
I Part 2: string assignments do: I
I 1 3 I
I 2 6 I
I 3 9 I
I Part 3: enforced garbage collection: I
I back to 3 I
+---------------------------------------------+
In a response to the question Mike Scheutzow wrote:
> There is one other thing you should know: Each time fre(0) [or
> whatever command is used to get the amount of unused memory] is
> called, the interpreter *must* do GC in order to be able to reliably
> report the amount of free space. When you noticed that memory "reset
> to 50K", it was because your program no longer was using it, not
> because GC was performed.
>
> Whatever is happening during that 10 to 15 minutes, it ain't GC.
This is wrong, as You may deduce from the output of the above sample
program. According to my BASICA manual, a call to FRE with a string type
parameter (FRE("") or FRE(A$)) enforces an early garbage collection.
FRE(0) (or FRE(A)) reports the amount of storage, which is not used and
not garbage, without doing any garbage collection. They suggest to call
FRE("") periodically in Your Program, in order to get more, but shorter
garbage collection delays.
Mike Scheutzows comment may result from experience with an earlier
Microsoft BASIC. Microsoft has changed BASIC's storage handling a couple
of times since its first version of BASIC (remember those 8K-
ROM-Basic's?)
Summary: place DUMMY=FS("") at a frequently visited position in Your
program. You may try IF INITIAL.FS-FRE(0)<5000 THEN INITIAL.FS=FRE("")
too.
Wolfgang Strobl, STROBL@DBNGMD21.BITNET
------------------------------
Date: Thu, 18 Sep 1986 15:21 EDT
From: <IJDG400%INDYCMS.BITNET@WISCVM.WISC.EDU>
Subject: Call for Papers - 1987 Academic Microcomputer Conference
1987 ACADEMIC MICROCOMPUTER CONFERENCE
CALL FOR PAPERS
DEADLINE FOR SUBMISSION: NOVEMBER 14, 1986
We would like to take this opportunity to invite you to participate in the
third annual Academic Microcomputer Conference to be held April 20-22,
1987, at the Radisson Plaza Hotel in Indianapolis, Indiana. This
conference is hosted by Computing Services, Indiana University - Purdue
University at Indianapolis. Approximately 50 30-minute papers will be
presented in two simultaneous sessions. The vendor display area adjacent
to the meeting rooms has been expanded for the 1987 conference. Other
features of the conference include a reception, banquet, keynote speaker,
exchange of public software, and informal birds-of-a-feather meetings.
Below are some suggested topics for papers.
Philosophical, moral, and legal aspects of microcomputer use in academic
environments
AI and expert systems
Networking
UNIX in an academic setting
Comparative product evaluation
Statistical computing on micros
Applications in the humanities and liberal arts
Public domain software
Hardware peripherals and compatibility
Computer center support of microcomputers
Computer-based training
Training and documentation
Authors whose papers are accepted will be notified of presentation details
at a later date. So that the Proceedings can be distributed at the
conference, papers must be submitted by late February.
Please send electronically the title of your talk, a short abstract, and
your name and address to John Hewitt, JSH10194@NORTHWESTERN.MAILNET.
Abstracts should be submitted by November 14, 1986.
General questions about the conference may be directed to the coordinator,
James Williams, IDTZ400@INDYCMS.BITNET or
IDTZ400%INDYCMS.BITNET@WISCVM.WISC.EDU.
We are looking forward to seeing you at the conference and thank you for
your participation.
1987 Academic Microcomputer Conference Committee
see you at the conference and thank you
------------------------------
Date: Tue, 16 Sep 86 10:10:47 pdt
From: kfd@ads.ARPA (Ken Dove)
Subject: SCSI Host Adaptors
I have a cheap SCSI disk sitting around and have been looking for a host
interface for an XT for some time. Does anyone know of a cheap source
for such a beast? Or has the low cost of ST506 controllers driven them
out of the market??
Ken Dove
kfd@ads.arpa
------------------------------
Date: 16 Sep 86 14:07:56 PDT (Tuesday)
Subject: Personal Fonts for Cordata Printer
From: Hopper.XRCC-NS@Xerox.COM (Mike Hopper)
This message may better have been posted to LaserLovers but it is
really a PC programming question. Has anyone in PC-land figured out
how to make your own fonts (or logos) with the PC driven Cordata laser
printer? I would like to use the printer to produce customized
letters.
Thanks Mike.........
Hopper.XRCC-NS@XEROX.COM
------------------------------
From: melmoy@nprdc.arpa (Mel Moy)
Date: 17 September 1986 1111-PDT (Wednesday)
Subject: Qmodem
Can anyone tell me what terminal is emulated by Qmodem?
I'm trying to use it to interact with the Vi screen
editor in UNIX. I've tried several termcaps, but have
not found the right one. Am I trying to do the
impossible with Qmodem?
melmoy@nprdc
------------------------------
Date: 17 Sep 1986 1543-EDT
From: Bruce Krulwich <KRULWICH@C.CS.CMU.EDU>
Subject: Microsoft C V4.0
I am interested in any comments on the microsoft C compiler version 4.0,
dealing with the generated code, the debugger, 8087 support, environment,
etc. quick mail responses would be nice as my project will be making
a purchase within a day or two.
thanks in advance.
bruce krulwich
arpa: krulwich@c.cs.cmu.edu
bitnet: bk0a%tc.cc.cmu.edu@cmccvma
uucp: ... seismo!... or ...ucbvax!...
!c.cs.cmu.edu!krulwich
------------------------------
Date: Thu, 18 Sep 86 00:52:41 -0500
From: clb@mitre-bedford.ARPA (Cleve Bell)
Subject: Industrial Dynamics Simulation Modeling Tool
Many years ago, about 1971, the Sloans School of Management
at MIT, Cambridge, Ma. developed a method of system dynamics analysis
using a modeling tool called INDUSTRIAL DYNAMICS, developed by
Jay W. Forrester. The modeling tool was based upon exponential
growth and dynamic feedback theory.
I am interested in learning if such a modeling tool has
been developed for use on the IBMPC (or clones). Anyone
aware of this modeling tool or similar capabilities, that
could be used on a PC, please provide me with points of contact.
Sayonara from Japan. Cleve Bell
------------------------------
Date: Thu, 18 Sep 86 12:18:40 EDT
From: Manasseh Katz <MKATZ@UMD2.UMD.EDU>
Subject: Cache on a Network
Does anyone know of any disk-cacheing software for an AT with extra (I
am not sure whether it is EMS or EEMS or something else) memory that
will work on a network. Apparently the boards were purchased and then
they found out that the software won't all fit on a large ramdisk, but
I think a cache would help things a lot - the server gets really
slowed down by the disk. The servers are ATs, and each one is
connected to 20 PCs or ATs on an Ethernet. The software is 3Com, and
I think it is version 4.2 (that's what the user diskettes say) but it
might be 2.8 (that's what some of the drivers that get loaded in the
PCs say). If anyone has any experience with disk-cacheing software,
or the 3Com network or both, please send me a message.
Please reply directly since I am not on the mailing list.
Manasseh Katz
MKATZ@UMD2.UMD.EDU or KATZM@UMDD.BITNET
------------------------------
Date: Mon, 15 Sep 86 22:55 EDT
From: Carl Hewitt <Hewitt@XX.LCS.MIT.EDU>
Subject: EGA Drawing Program => Postscript Query
I have the same query as Richard Patis (see below) except that I have an EGA
graphics board.
Thanks,
Carl
Date: Tue 26 Aug 86 10:35:08-PDT
From: Richard Pattis <PATTIS@WASHINGTON.ARPA>
Subject: Drawing Program => Postscript Query
To: info-ibmpc@B.ISI.EDU
I would like to merge drawings into TeX documents, as my DVI -> PS
conversion program says I can do. My question is, are there any drawing
utilities out there that produce postscript? I am running an AT under
DOS 3.1, with a Hercules (clone) card. I don't yet have a mouse, but
would purchase one for such an application.
Rich Pattis
------------------------------
Date: Tue 16 Sep 86 20:03:39-PDT
From: D.LEWIS%SCU%PANDA@SUMEX-AIM.ARPA
Subject: HP 150 with "Carbon Copy" or "REMOTE"
Does anyone know if either "Carbon Copy" (by Meridian Technology) or
"REMOTE" (by Microstuf, Inc.) will run on a Hewlett-Packard HP-150
computer?
These programs allow two IBM PC's to be linked together via a modem
in such a way that the "local" PC can control the execution of a
program running on the "remote" PC, with all the screen output of the
remote PC also appearing on the local PC.
I imagine that the minimal requirement is probably a going to be that
the display, keyboard, and serial port entry points of the HP-150's
BIOS interface be IBM compatible. However, I have no idea if the HP
150 is BIOS compatible (or much less hardware compatible) with the
IBM PC.
Specifically, I want to use this remote capability with HP's
"Executive Card Manager" database program. Does anyone know anything
about the feasibility of this?
Thanks in advance!
Dan Lewis
Assoc Prof of EECS
Santa Clara Univ.
Santa Clara, CA 95053
(408) 554-4449
(Or respond to return path listed with message.)
------------------------------
Date: Wed, 17 Sep 86 11:50:01 ADT
From: PAUL%Acadia.BITNET@WISCVM.WISC.EDU (Paul Steele - Acadia University)
Subject: Fastback
Has anyone out there been having any problems with FastBack?
Specifically, everything seems to work great during backup, but I've
encountered several problems attempting to restore files from a backup
set. The most annoying one occurs when attempting to do a full or
partial restore. FastBack will indicate that a particular file
already exists in the file's home directory when it obviously doesn't
exist. If I answer Y to the message from FastBack
'Replace existing file?', FastBack then replies with the fatal error message
'Cannot remove file - press any key to continue'. This error message isn't
unexpected since the file definitely did not exist previous to the restore
operation. I made sure and did a DEL *.* before running FRESTORE. Once the
error occurs, the restore operation is stopped if a control-R had been in
progress. To make matters even stranger, the file in question appears to
have been restored even with the error message, although a few weeks ago
I seem to recall that the file was not restore during a similar error.
This problem seems to happen quite frequently. On a 2-disk backup set
on 1.2M floppies, about half of the files reported this error. Yet
checking the directory after the errors revealed all the problem
files. A second attempt to restore still gave the error, even though
the file did exist. The error condition could be removed by creating
a file by the same name using an editor or COPY CON file command.
Anyone have any ideas what's causing this problem? It has happened on
both an PC-AT and a Compaq Deskpro. Please respond to me directly and if
I get anything useful I'll forward it to INFO-IBMPC.
---> Paul@Acadia
------------------------------
Date: Thu 18 Sep 86 11:05:08-CDT
From: Pete Galvin <CC.GALVIN@R20.UTEXAS.EDU>
Subject: Personal Computer Support Group (PCSG)
Has anyone had dealings with PCSG? The produce the Lightning disk
cache program and the Breakthrough PC speedup card. Their adds in
PC Magazine make their board sound very nice (an 80286 for $395), and
they're giving a 60 day money-back guarantee. My question is, if the
board doesn't work in my clone, will I really be able to get my money back?
My other question is, has anyone used this board? It's fairly new and
consequently was't included in the recent speedup board reviews.
--Pete
------------------------------
Date: 19 Sep 86 14:31 EDT
From: Shoots.wbst@Xerox.COM
Subject: DOS Disk Sector Size Constraints
How can I get IBM PC-DOS (3.10 or 3.20), running on an XT, to accept a
block device driver for a disk with sectors larger than 512 bytes (e.g.
1024/2048/4096 bytes)?
There seems to be hooks in DOS for sector sizes larger than 512 bytes -
for example, the DOS disk Boot Sector includes a TWO-BYTE field for the
sector size, in bytes. I can't believe that IBM would have hard-wired
such a restriction into the software, yet when I try to install my
device driver with sector sizes larger than 512 bytes, DOS complains,
and does not do the installation properly. [It does, by the way, do
enough of the installation so that instead of getting an "Invalid Drive"
message when I try to access the disk, the software goes off the deep
end.]
I've tried several approaches, including changing the Attribute Field in
the Device Header (bit 13) to NON-IBM format. No matter what I try, I
get the same error message, apparently from "IBMBIO.COM", each time I
boot: "Sector size too large in xxxxxxx.sys".
I also tried making the disk look like one of the example disks shown on
page 2-25 of the DOS Technical Reference (First Edition 1985). The
description of the example disk says: "... Double sided, double density,
1024 bytes per sector...". DOS reported the same error message -
"Sector size too large..." Is the manual incorrect?
Thanks for any light you can shed on this issue.
Jim Shoots
------------------------------
End of Info-IBMPC Digest
************************
-------