Info-IBMPC@WSMR-SIMTEL20.ARMY.MIL ("Info-IBMPC Digest") (05/28/90)
Info-IBMPC Digest Mon, 28 May 90 Volume 90 : Issue 96
Today's Editor:
Gregory Hicks - Chinhae Korea <GHICKS@WSMR-Simtel20.Army.Mil>
Today's Topics:
360k disks on 1.2M drive
Re: Cygnet's Little Black Book
Kermit 3.01 bug ?
Problems downloading large files.
Problem with QUICKCACHE II (Ver. 4.20)
public domain unix?
Re: overwriting the psp
TeX PD DVI Drivers
Unix
Arabian Word Processing Software
Send Replies or notes for publication to:
<INFO-IBMPC@WSMR-SIMTEL20.ARMY.MIL>
Send requests of an administrative nature (addition to, deletion from
the distribution list, et al) to:
<INFO-IBMPC-REQUEST@WSMR-SIMTEL20.ARMY.MIL>
The Lending Library is available from: WSMR-SIMTEL20.ARMY.MIL (see file
PD1:<MSDOS.FILEDOCS>AAAREAD.ME details on file directories and
descriptions.)
Archives of past issues of the Info-IBMPC Digest are available by FTP
only from WSMR-SIMTEL20.ARMY.MIL in directory PD2:<ARCHIVES.IBMPC>.
WSMR-SIMTEL20.ARMY.MIL can be accessed using LISTSERV commands from
BITNET via LISTSERV@NDSUVM1, LISTSERV@RPIECS and in Europe from EARN
TRICKLE servers. Send commands to TRICKLE@<host-name> (example:
TRICKLE@TREARN). The following TRICKLE servers are presently
available: AWIWUW11 (Austria), BANUFS11 (Belgium), DKTC11 (Denmark),
DB0FUB11 or DTUZDV1 (Germany), IMIPOLI (Italy), EB0UB011 (Spain),
TAUNIVM (Israel), and TREARN (Turkey). SIMTEL20 is not accessable on
the first Wednesday of each month from 6-8pm Eastern Standard Time.
If you are unable to access SIMTEL20 via Internet FTP or through one of
the BITNET/EARN file servers, most MSDOS SIMTEL20 files, including the
PC-Blue collection, are available for downloading on the Detroit
Download Central network at 313-885-3956. DDC is a networked system
with multiple lines that support 300, 1200, 2400, and 9600 bps (HST).
This system is a subscription system with an average hourly cost of 17
cents per hour. It is also accessable on Telenet via PC Pursuit and on
Tymnet via StarLink outdial. New files uploaded to WSMR-SIMTEL20 are
usually available on DDC within 24 hours.
----------------------------------------------------------------------
Date: Fri, 18 May 90 09:58:36 ITA
From: Paolo Mattiangeli <MERCEDES%IRMUNISA.BITNET@CUNYVM.CUNY.EDU>
Subject: 360k disks on 1.2M drive
Can anyone please let me know if there is a way to format 360k floppy
disks on a 1.2M disk drive, under DOS 3.3?
Many thanks
P.
Paolo Mattiangeli
Universit{ di Roma "La Sapienza"
Dipartimento di Fisica N.E.
P.le Aldo Moro, 4 - 00185 Roma Italy
E-mail: MERCEDES@IRMUNISA.BITNET
"My words are mine"
------------------------------
Date: Thu, 17 May 90 21:23 EDT
From: DATAUB%VASSAR.BITNET@CUNYVM.CUNY.EDU
Subject: Re: Cygnet's Little Black Book
Originally, I wrote this letter to the network in the hope that
I would get a solution out of it.
>> I have a PS/2 Model 80. At work, I have access to a Compaq/386,
>>as well. No matter what (386) machine I try to run Cygnet's Little
>>Black Book on, it will lock the machine up (I have tried many others).
>>If I try the program on a 286 or 8088, it works fine. I know that the
>>286 instruction set is a subset of the 386 set, and when the 386 was
>>built, they left off a few commands that were available in those
>>previous processors. I'm sure that the program is trying to access
>>some of those instructions.
>> What I'm looking for is a TSR that will allow me to run The
>>Little Black Book on a 386. Cygnet went out of business and the
>>company that took them over dropped the program.
>> Now I have the program, all the data, a 386, and I can't run it.
>>Also, I love the program because it actually prints an actual little
>>book and has an algorithm in there to figure out spacing, and such.
>> If anyone knows of either a better program that will print a
>>little book that keeps names, adresses, phone numbers and notes OR
>>knows of a TSR that will allow me to run the program, please let me
>>know. I would prefer the latter since I am so attached to the program,
>>however any suggestions would be much appreciated.
This is the reply that I got from David Zielke,
zielke@phy.duke.edu:
>I had the same kind of problem running programs on my 386 when I first
>got it and was very concerned with possible compatability problems.
>One of these was a program called STORM which is a hurricane tracker.
>It would die half way through drawing the North American Continent.
>At any rate, the solution is any package which will manage to kick the
>processor into 86 emulation mode. One which does this is Windows/386,
>I think that DesqView/386 does the same thing although I have not
>tried it.
>
>However, something like this should solve you problem.
I would like to reply to the network because, to many, this answer
may seem viable. The problem is that while Windows/386 and
Desqview/386 do put the processor into 86 mode, I think that the
program is calling some functions that are only on the 8086/80286
instruction sets (many instructions were added in the upgrades, but 1
or 2 were also deleted). If anyone else knows of a way to make this
program (The Little Black Book by Cygnet (which is out of business)),
please let me and/or the network know.
Thanks in advance...
Danny Taub
Dataub@Vassar.Bitnet
Dataub%Vassar.Bitnet@Cunyvm.Cuny.Edu
------------------------------
Date: Fri, 18 May 90 19:28:00 BST
From: Nino Margetic <nino%mph.sm.ucl.ac.uk@NSFnet-Relay.AC.UK>
Subject: Kermit 3.01 bug ?
Just to bring to your attention: when given a remote single-character
host command, Kermit-MS v.3.01 (and for that matter v.3.00 also)
complains and fails with a message: ?More parameters are needed.
Furthermore, if one types a white space after the single-character,
everything is OK. This wasn't the case with Kermit v.2.32. Is it a bug
or a feature?
Example:
Kermit-MS> remote host l<RET>
?More parameters are needed
Kermit-MS> remote host l <RET>
^ note the white space
... execution of the l command ...
-Nino
Janet: nino@uk.ac.ucl.sm.mph \ Nino Margetic
Earn/Bitnet: nino%mph.sm.ucl.ac.uk@ukacrl.bitnet \ Dept. of Medical Physics
Internet: nino%mph.sm.ucl.ac.uk@cunyvm.cuny.edu \ University College London
Uucp: ..!psuvax1!cunyvm.bitnet!mph.sm.ucl.ac.uk!nino\ Tel: (+44)(071) 380-9846
------------------------------
Date: Thu, 17 May 90 20:27 EST
From: <T_ADAMS%UNHH.BITNET@mitvma.mit.edu>
Subject: Problems downloading large files.
I have been able to successfully download and run small files.
However, whenever I receive files from Simtel20 which are sent
uuencoded through mail in many pieces I am unable to uudecode them. I
have extracted the parts into one file and used a text editor to remove
the headers. However, when I download them to my pc I am unable to
uudecode it. Any help would be appreciated. Thanks.
--Tiffany Adams
------------------------------
Date: 18 May 90 18:06 GMT+0100
From: Guenter Schulz <schulz%ipsi.darmstadt.gmd.dbp.de@RELAY.CS.NET>
Subject: Problem with QUICKCACHE II (Ver. 4.20)
The latest version (4.20) of QUICKCACHE II in SIMTEL directory
<MSDOS.DSKUTL>QC420-1 and QC420-2 appears to have a severe bug
in the Buffered_Write Option.
When Buffered_Write is enabled, there is actually not any byte written
to the disk at any time. Depending on the application writing to the
hard disk you either get a message "no space on disk" or e.g. the
NORTON COMMANDER built-in editor fools you by creating a new file which
actually appears in the directory listing window, but which vanishes
somewhere in nirvana when the next called program returns to the
COMMANDER shell again. The disk integrity is not destroyed by this
strange behaviour.
As I first could not imagine that Glassel & Assoc. had overlooked a bug
of this order, I fiddled around with almost any possible parameter
combinations and settings, but with no success. The bug even appears on
an entirely different machines (orig. IBM-AT03 /w PC-DOS 3.3 and 30 MB
MFM-HD or 386-based COMPAQ compatible with COMPAQ-MS-DOS 3.31 and 360
MB ESDI-HD etc.). The funniest thing I found out purely accidental was
that on the 360 MB disk which contains five logical disks from C: to G:
the error only occurs on drive C: while on the other logical disks
everything seems to happen like it is expected. And believe me, I did
not forget to enable drive C:!!
If anybody on this list has got an idea what's going on there or - even
better - knows a cure for the problem or - the best what could happen -
is from Glassel & Assoc. in Stacy, MN or can establish a contact to
them (I heared they are monitoring CompuServe Forum IBMHW, DL0), could
you please inform me or respond to this list? I'm rather at my wits'
end...
Guenter Schulz.
------------------------------
Date: Fri, 18 May 90 09:43 EST
From: "JEFF CASEY / (617)253-0885" <CASEY@ALCVAX.PFC.MIT.EDU>
Subject: public domain unix?
I keep hearing rumors of public domain unix systems compatible with PC
architecture (prefereably 386). Does anyone know if such an animal
exists? How compatible are such creatures with DOS applications? Any
information appreciated. Thanks.
Jeff Casey MIT Plasma Fusion Center
CASEY@ALCVAX.PFC.MIT.EDU
------------------------------
Date: Thu 17 May 90 16:21:08
From: tweten@prandtl.nas.nasa.gov
Subject: Re: overwriting the psp
From: djb@wjh12.harvard.edu (David J. Birnbaum)
> I would be grateful for any suggestion about how one relocates a
>program backward over this space. The assembler will generate
>addresses according to the position of information within the code
>during assembly. If I load the program and then use movs to copy
>everything back a certain amount, I'm not sure how I can ensure that
>the embedded addresses will still work.
There are a couple of techniques which work:
1. Don't use instructions with imbedded code addresses. Short
jumps (most notably all the conditional ones) don't assemble into CS
relative addresses, they assemble into IP:CS relative addresses. If
you move all the code, the distance between the jump and its target
remains constant and the jump instruction does not have to be changed.
2. If you do really need to embed a segment register relative
address in your code, assemble it to start a multiple of 16 bytes from
its eventual location overlapping the PSP. Then you make sure that CS
is set to a value which is "too small" by the multiple of 16 when you
branch to the relocated code.
If the relocated code gets executed as a result of an interrupt,
just decrement the CS value you put into the vector. If you transfer
execution to the relocated code directly from code which is not
relocated, do so with an indirect long jump, and "fix" the CS portion
of the doubleword before doing the jump.
Needless to say (but I will anyway), any other segment registers
used by the relocated code should be loaded off of CS.
I have the source for one of my TSRs here at work (a screen blanker
which works with several display types), but it is a bit more
complicated than one I have at home (a ROM disk I/O interrupt filter
which slows CPU speed for floppy format and verify). If you'd like I
can mail you the source for the disk I/O filter so you can examine my
adopted solutions to the relocating TSR problem.
------------------------------
Date: Thu, 17-MAY-1990 15:15:15.06 PDT
From: <larsen%SLACSLD.BITNET@CORNELLC.cit.cornell.edu> (Allen Larsen)
Subject: TeX PD DVI Drivers
To all PC-TeXperts:
Having found TeX to be useful on our VAX at work, I decided to set up
TeX on my PC at home. I have been successful in setting DosTeX from
SIMTEL and it works fine. My problem is that I have not been able to
get the dvi drivers to work. I have a Panasonic KX-P1124 printer and
the dvi drivers DVIEPS and DVIPAN from SIMTEL. When trying to run the
dvi drivers, I get the error:
Font xxxx ... Unable to open, continuing with zero size font.
Or something to that effect. I have set the FONTDIR environment
variable to: D:\DOSTEX\FONTS\PK\ where the directory structure for
DosTeX is:
D:->DOSTEX-->FONTS-->TFM
| |
| +->PK-->288 Where here are various directories numbered
| | somewhere from ~200 - ~350. Each of these
-->INPUTS +->... have a number of PK font files and work fine
| with the TeX82 executable and the DVI2HERC
+->... previewer.
I also have gotten weirder errors such as CANNOT LOAD COMMAND.COM where
the system hangs, and UNABLE TO ALLOCATE MEMORY. I have tried many
different ways to make these work, but have had no luck.
I have removed all of my TSRs except my mouse driver and have ~560K of
free memory before attempting to run these drivers. The drivers do say
that they are experimental, but I have looked everywhere (in the public
domain) and have noticed that these seem to be the drivers of choice.
If anyone would be able to assist me, it would be very much
appreciated. What are the font file names that the program searches
for? Is it that DVIEPS cannot find the files? I don't know if this is
the case because it occasionally will make it through the first page
and almost the second page before the font messages appear and the
system hangs.
If possible, could any replies be routed directly to me as well as to
the distribution list as I am not sure that postings to the list are
reaching me.
Thankyou,
Allen Larsen.
Bin 71, Stanford Linear Accelerator Center
P.O. Box 4349, Stanford, CA, 94035 Phone: (415) 926-4270
INTERNET: Larsen@sld.slac.stanford.edu BITNET: LARSEN@SLACSLD
------------------------------
Date: Fri, 18 May 90 00:07:20 -0400 (EDT)
From: Alfred Benjamin Woodard <aw1r+@andrew.cmu.edu>
Subject: Unix
I am interested in getting unix to run on my pc. Can anyone tell me my
options. I know Xenix is around but is there any other alternitives. I
would prefer the bsd variant.
-ben
aw1r+@andrew.cmu.edu
------------------------------
Date: SAT, 19 MAY 1990 17:45 JST
From: "KAZUYUKI KONKO" <KONKO%JPNTIU01.BITNET@CUNYVM.CUNY.EDU>
Subject: Arabian Word Processing Software
I'M LOOKING FOR AN ARABIAN WORD-PROCESSOR SOFTWARE, THAT RUNS ON AN
IBM-PC.
IF YOU KNOW ABOUT IT, PLEASE TELL ME:
1. THE NAME OF SOFTWARE.
2. THE SELLER'S COMPANY NAME AND ADDRESS.
PLEASE WRITE BACK TO ME !
ANY HELP WOULD BE APPRECIATED , THANK YOU.
| KAZUYUKI KONKO | COMPUTING CENTER |
| KONKO@JPNTIU01.BITNET | TOKYO INTERNATIONAL UNIVERSITY |
| | 1-13-1 MATOBAKITA |
| TEL +081-492-32-1111(413)| KAWAGOESHI, SAITAMAKEN , 350 , JAPAN |
------------------------------
End of Info-IBMPC Digest V90 #96
********************************
-------