Info-IBMPC@USC-ISIB.ARPA (Info-IBMPC Digest) (03/11/86)
Info-IBMPC Digest Monday, March 10, 1986 Volume 5 : Issue 32
This Week's Editor: Phyllis O'Neil
Today's Topics:
LPTX
Alternate Character Sets
Clearing the Screen (2 messages)
Re: Microsoft C Compiler Wish List
FORTRAN to C query
Redistributing INFO-IBMPC
RE: AT&T PC6300 Color Display
NEC V30 in a Compaq Deskpro
SAVVY
Turbo Pascal's 64K Limitation
Today's Queries:
Help with FTP between PC and VM
Help needed with device driver
INTERRUPT ROUTINES--QUERY
Discrete simulation languages query
.OBJ file format query
Sort and German DOS 3.x query
PC's Limited AT Query
----------------------------------------------------------------------
Date: Mon, 10 Mar 86 16:15:09 est
From: Mike Ciaraldi <ciaraldi@rochester.arpa>
To: info-ibmpc@usc-isib.arpa
Subject: LPTX Problems (more details)
I downloaded LPTX a few weeks ago from the ARPA archives, and found
it works partially.
My first problem was not knowing that it had to be processed by
EXE2BIN. At first I thought the "No Stack Segment" message from LINK
was an actual error. Once I got that figured out, it would actually
run.
Results:
Under DOS 2.1 it seems to work fine for me. This is on a standard IBM
PC with Color Graphics Adapter and dual floppies. I tried several
different things, such as copying a file to PRN, using printer echo
(ctrl-P), etc., and they all seemed OK. I was NOT using any other
memory-resident programs.
Under DOS 3.1, it worked all right for printer echo and other commands
that didn't require disk use. When I tried to do a DIR > PRN or a DIR
with printer echo, the first 512 bytes would go into the printer file,
then the whole system would lock up. Repeating, other ways of
producing printer output (e.g. from a BASIC program) that did not use
the disk caused no trouble.
So, it would appear that there is a conflict when DOS is trying to
handle two disk requests simultaneously, one producing the data and
one receiving it.
Looking through the code, I see that there is a place where the author
saves away the system stack, explaining in a comment that this gets
around the restriction against doing#zDOS calls from inside an
interrupt handle. The comment makes reference to the DOS 2.1
reference manual. So, my suspicion is that something changed between
DOS versions, and LPTX does not take that into account.
I hope someone else with more experience than I can figure out how to
fix this, as LPTX seems very handy.
Mike Ciaraldi
ciaraldi@rochester
seismo!rochester!ciaraldi
------------------------------
To: jmsk@mc.lcs.mit.edu
Cc: info-ibmpc@isib
Subject: Alternate Character Sets
Date: Sun, 09 Mar 86 23:07:23 -0500
From: jcmorris@mitre.ARPA
In your posting of 8 March you asked about the STSC handling of the special
character sets used in its APL product.
The STSC APL*PLUS/PC package can work with all three standard IBM CRT
interfaces (mono, CGA, and EGA). The special PROM is required with the
monochrome adapter; it's recommended but not mandatory with the CGA, and
cannot be used with the EGA. (There are also several different PROM's
for use with other manufacturers' boards.) Assuming that one of the IBM
boards is being used, the no-PROM approach uses the techniques shown in the
standard IBM documentation.
You don't say in your note which CRT adapter you're using. If it's the
IBM mono or CGA, both boards use the same PROM. I've not actually done
it, but it doesn't look to be too difficult to figure out the addressing
scheme and design your own character set if you've got access to a PROM
burner. The EGA uses proprietary chips and doesn't have a socketed PROM
to be replaced. The IBM manuals show how to specify your own character
set for the CGA and EGA. There is no way to avoid a special PROM if you're
using the monochrome adapter.
Joe Morris (jcmorris@mitre)
------------------------------
Date: Mon 10 Mar 86 12:42:35-CST
From: Pete Galvin <CC.GALVIN@R20.UTEXAS.EDU>
Subject: Re: Clearing the screen
To: JAZBO%BROWNVM.BITNET@WISCVM.WISC.EDU
cc: INFO-IBMPC@USC-ISIB.ARPA
I believe the best method is one described in the IBM Tech. Ref. It
is simply a call to the bios video routines scroll function. Tell
it to scroll 25 lines, and the screen is cleared. Sorry I don't
have the numbers in front of me...
--Pete
------------------------------
Date: 10 Mar 1986 11:01:27 PST
Subject: Re: Clearing the screen
From: Richard Gillmann <GILLMANN@USC-ISIB.ARPA>
To: Pete Galvin <CC.GALVIN@R20.UTEXAS.EDU>
cc: JAZBO%BROWNVM.BITNET@WISCVM.WISC.EDU, INFO-IBMPC@USC-ISIB.ARPA
I agree that the BIOS call is the best bet. Most MS-DOS machines have
a mode that will emulate the IBM BIOS to that extent. The only way to
clear the screen that does not depend on ANSI.SYS nor on the IBM BIOS
is to write 25 linefeeds to the screen. And even this won't be
compatible with displays with more than 25 lines, like the EGA in some
modes.
------------------------------
Date: Mon, 10 Mar 86 09:55:22 CST
From: nather@ASTRO.UTEXAS.EDU (Ed Nather)
To: info-ibmpc@USC-ISIB.ARPA
Subject: Re: Microsoft C Compiler Wish List
>From: Ya'akov_Miles%UBC.MAILNET@MIT-MULTICS.ARPA
>It would be nice if Microsofts "C" compiler ver 3.0 was enhanced by
>
> (1) Improving the optimizer such that string constants are folded.
> Currently the following "C" statements
>
> PRINTF("\nThis string is stored twice by Microsoft `C`");
> PRINTF("\nThis string is stored twice by Microsoft `C`");
>
> causes the string constant to be replicated, wasting space.
I don't think they can do that ... the C langauge allows you to write
to a string constant and change its value, so each one must be unique.
While there is no way to address the one in your example, it is a special
case which the compiler would have to identify. And if it were identical
to one that you *could* address ...
> (2) Increasing the module size that the optimizer will handle before
>
> warning: function `xxxxxx` too large for post-optimizer [0]
That one should be easy.
------------------------------
Date: Mon, 10 Mar 86 13:51:47 CST
From: fenchel@rsch.wisc.edu (Bob Fenchel)
To: info-ibmpc@isib
Subject: FORTRAN to C query
Anyone have, or know of a program that can do a reasonable job
translating from FORTRAN to C?
------------------------------
To: info-ibmpc@usc-isib.arpa
Subject: Redistributing INFO-IBMPC
Date: Mon, 03 Mar 86 16:07:23 -0500
From: Craig Partridge <craig@loki.bbn.com>
A few weeks ago a note went out to this list which, among other things,
expressed some annoyance at those of us who run CSNET for not offering
redistribution facilities for mail digests like INFO-IBMPC. We at
CSNET view this as a somewhat unfortunate situation -- we like to see
ourselves as helping the research community, yet in this particular
situation our hands are tied. I've included parts of the original
message below with an explanation of why we are unable to help out.
I hope this will give people a better sense of why the problem exists.
> Date: 19 Jan 1986 13:34:50 PST
> Subject: New Year's Resolutions
> From: Billy <BRACKENRIDGE@USC-ISIB.ARPA>
> To: info-ibmpc@USC-ISIB.ARPA
> The editors of INFO-IBMPC met last week. Several changes have taken
> place.
>
> [much text deleted]
> We are unresolved as to what to do about sending back digests and
> library files to unconnected networks. We never have responded to
> requests from usenet hosts unless they were closely connected to th
> arpanet, and we are getting increasingly fed up with sending things
> via mail to csnet and bitnet. The only reason these nets don't have file
> access to our archives is because the political administrators of
> these networks are unwilling to implement gateways that can handle
> file transfer. I fail to see why we should have to send files as mail
> because the users of these connected networks are unwilling or unable
> to put pressure on the administrators of their nets to allow them
> file access to ARPA hosts. In the mean time some requests will get
> answered and others won't depending on the mood of who is editing at
> the moment. This sounds harsh but only reflects the reality of the
> last year or so as requests have grown beyond our capability to handle
> them.
We'd love to offer file access to ARPA hosts. In fact we at CSNET
had plans to implement (indeed had started work on) a mail interface
to the FTP protocol. But when we mentioned this idea to various
parties involved in running the DDN we were told that we could not
offer mail oriented FTP. Apparently FTP is involved in a large
fraction of the security incidents on the DDN, and if we made FTP
available to a larger community (i.e. those people who can reach the
Internet via mail), the security problems and concerns could become
much more serious.
>
> If someone had a mail based server that could automaticly respond to
> these requests, this could solve the problem for the short term.
>
> [more deletions ]
Such programs exist. Both CSNET and BITNET have information
servers that are capable of automatically handling requests via mail.
Other versions exists on the UUCP network. MOSIS (at ISI) also offers
this capability. We (at CSNET) are, however, in no position to start
archiving all of the various mailing lists that our members are
interested in (we just don't have enough processing and disk resources
to handle this much data).
As I've said, we'd like to help out, and we are not unaware of
this problem. If we find a solution at our end you'll be the first
to know.
insert
Craig Partridge
CSNET Technical Staff
craig@sh.cs.net (for the daring) or craig@csnet-sh.arpa
I stand by my statements that the reason csnet subscribers can't get
FTP access to our files and archives is political not technical. If
"the various parties involved in running the DDN" really believe FTP
access to the ARPANET is a security breach there is something
seriously wrong with the DDN. I am sure there is some appropriate
mailing list to discuss whatever politics may be involved in this
decision, but this isn't the one.
I spoke with the MOSIS people and their software is too specific to MOSIS
to work for INFO-IBMPC.
In the mean time there is a program called netlib that runs on unix
that allows people to fetch files from libraries via net mail. I'd
like to get that up running. I don't speak unix and don't want to do
it personally but would be glad to give assistance to any volunteers.
-wab]
------------------------------
Date: 10 MAR 86 14:32-N
From: INNO%HWALHW5.BITNET@WISCVM.WISC.EDU
To: INFO-IBMPC@USC-ISIB.ARPA
Subject: RE: AT&T PC6300 Color Display
I have an Olivetti M24 with a color monitor. It has almost the same
hardware as the AT&T 6300. I recognized the problem of the color
monitor. I had the problem too, when I was running the product
SUPERKEY. When I tried to exit the same problem occurred: a snowy
display and the left margin in the center of the screen. I didn't
have the problem when I booted from an original IBM PC-DOS V2.00
floppy. For the rest I never have problems with my color monitor,
even if I run some graphics color demos for the IBM-PC.
Inno Frencken
Computing Centre
Agricultural University
Hollandseweg 1
6706 KN Wageningen
The Netherlands
phone: 08370-83875
EARN-id: INNO
EARN-node: HWALHW5
------------------------------
Date: Mon 10 Mar 1986 12:39:11 EST
From: <SAGE@LL.ARPA>
Subject: NEC V30 in a Compaq Deskpro
To: info-ibmpc@usc-isib
I am running my Deskpro Model 4 with an NEC V30 chip in it. The
Norton utility performance index doubled, indicating that some
instructions now run twice as fast as before. I ran one benchmark
using a compute-bound PMATE text-editing macro and found a speed
improvement of about 10-15%. My hard disk seems to run noticeably
faster. The one problem I have had is with the tape backup. Things
seem to go too fast for it! I solved the problem by switching the
computer to its low-speed clock when making the tape backups.
------------------------------
Date: Mon 10 Mar 86 10:24:47-PST
From: CRESWELL@SRI-AI.ARPA
Subject: SAVVY
To: INFO-IBMPC@USC-ISIB.ARPA
I purchased Savvy about 6 months ago and have used it for database
applications for medium sized files. It is easy to use...seems to do
all I want it to...though I'm not using it for extremely exotic
purposes. Purchased it through the mail for a good deal....installed
in my PC hard disk and had it up and running in about an hour. The
little instruction books are well written. The manual, like most
manuals, is "ok" if you really need to delve into the guts of things
altho' I've found that the menus/user books have provided most
everything I need.
------------------------------
Date: 10 Mar 86 10:58:53 PST (Monday)
From: Eldridge.ES@Xerox.COM
Subject: Turbo Pascal's 64K Limitation
To: Marvin Zauderer <ZAUDERER@SU-SUSHI.ARPA>
cc: info-ibmpc@USC-ISIB.ARPA, Eldridge.ES@Xerox.COM
It is true that Turbo Pascal is limited to 64K of code space and 64K of
static data space, but this is not really a problem. To get around the
code space limitation, Turbo Pascal provides an overlay facility.
Chaining can also be used where appropriate.
The 64K limitation on the data space applies only to static data
structures. If you use dynamic data structures, then you have access to
all available memory in the machine. Dynamic data structures are
allocated off of the heap. There is a limitation of 65521 bytes for a
single dynamic variable.
I have heard that Nostradamus software offers a utility that extends the
code and data space range of Turbo Pascal, but I have no experience with
it.
George (Eldridge.es@Xerox.com)
------------------------------
Date: Mon, 10 Mar 86 10:28:07 cet
Subject: Help with FTP between PC and VM
From: UZR500%DBNRHRZ1.BITNET@WISCVM.WISC.EDU
I am developing a FTP-program running on the IBM-PC (every
version). Our PC has a coax kable and neither IRMA nor AST-PCOX card
for emulation and FTP from/to our IBM/370 host under VM/CMS. At the
moment we would need some information exchange with other people who
have the same problems or who have already written such a program,no
matter in which programming language it has been written. We have
several programs which are solving our problem. But every is too slow
or it does not run exactly. We have problems in compiling BASICA-pro=
grams with the IBM-BASIC-COMPILER and with the QUICK-BASIC-COMPILER.
At the end of our list,writing this program in TURBO-PASCAL brings
some other problems,too.So,if there is someone who has the same pro=
blem or better who has already solved it,I would like to correspond
with him in order to solve it.
Thank you very much.
Sincerely yours
Thorsten Glattki
Glattki, Thorsten 0228/73-2747 UZR500 at DBNRHRZ1
RHRZ Universitaet Bonn
Zimmer 003
Wegelerstrasse 4
D-5300 Bonn 1
Ferderal Republic of Germany (West Germany)
------------------------------
Date: Mon, 10 Mar 86 03:11 EST
From: Paul Schauble <Schauble@MIT-MULTICS.ARPA>
Subject: Help needed with device driver
To: Info-IBMPC@USC-ISIB.ARPA
I am attempting to write a device driver for a slightly strange disk
and have run into a problem. The disk is different from a standard PC
disk in that it uses a 2K byte sector size. I know that DOS has some
procedure for dealing with other sector sizes: I have previously seen
device drivers that use other than 512 byte sectors. However, when I
try to load my driver, it gets the message "Sector size too large in
driver.sys".
Does anyone know if anything special is needed to set the sector size
that DOS uses? Or, just exactly what is the problem here?
Thanks,
Paul
------------------------------
Date: 10 MAR 86 10:48-N
From: DOMMELEN%HWALHW5.BITNET@WISCVM.WISC.EDU
To: INFO-IBMPC@USC-ISIB.ARPA
Subject: INTERRUPT ROUTINES--QUERY
Has anyone in this audience a routine which does the following:
1. Generates a timer interrupt and calls a routine e.g. each second.
2. Can be locked into the system, so keeps interrupting when a FORTRAN
program runs.
3. Maybe can do something like the ON KEY .. GOSUB functions of GWBASIC.
I'm asking this for a custumor who is working with an Olivetti M21 and
wants to write his program in Microsoft FORTRAN. Probably these routines
should be made in MASM, which is available also.
Any suggestions are welcome.
Wim van Dommelen, Computer Centre Agricultural University, Wageningen Holland.
DOMMELEN@HWALHW5.BITNET
------------------------------
Date: Monday, 10 March 1986 13:57:55 EST
From: Joe.Newcomer@a.sei.cmu.edu
To: info-ibmpc@usc-isib.arpa
Subject: Discrete simulation languages query
(I'm asking this for a friend)
Are there any discrete system simulation languages (the last one I
used was Simula) available for the PC. He needs to simulate a
system with lots of discrete servers (neg. exp. arrival and service
times) with setup and "latency" considerations. Graphics output
nice but not required. A self-contained system is desired; native
language is C (he has no Fortran, so Fortran-based preprocessor simulator
things will not work).
joe
------------------------------
Date: Monday, 10 March 1986 14:00:48 EST
From: Joe.Newcomer@a.sei.cmu.edu
To: info-ibmpc@usc-isib.arpa
Subject: .OBJ file format query
(for another friend)
I know someone who wishes to port his favorite compiler to the PC.
Ideally, he'd like to write .obj files directly instead of invoking
the assembler. The .OBJ file format is rather obscure and the Intel
document hasn't helped us much. Does anyone have a public domain or
small $ .OBJ-file-writer? Desire is to support the equivalent of
Lattice's S,P,D and L models. I don't have time to get involved in
this deeply so am looking for ways to help.
joe
------------------------------
Date: Mon, 10 Mar 86 15:59:36 PST
From: kegel%Juliet.Caltech.Edu@Hamlet.Caltech.Edu
Subject: Sort and German DOS 3.x query
To: info-ibmpc@usc-isib.arpa, m70b%cbebda3t.bitnet@wiscvm.wisc.edu
The stated problem is, why does SORT seem to ignore the umlaut on letters?
Sort is presumably using the generalized mechanism provided by DOS for
resolving ordering of ascii characters. The DOS function call "Get/set
country information" allows you to get or set the address of the subroutine
used to order characters. Although the documentation in the DOS 3.0
Technical Reference manual does not specify what exactly the subroutine does,
tracing thru it with DEBUG reveals that it is something like the following:
translate proc far
push bx ; save caller's register
mov bx, offset value_table ; get address of our order-value table
xlat cs:[bx] ; replace char in AL with its order value
pop bx
ret
translate endp
value_table db 0, 1, 2, 3, 4, 5 ; and so on
The value_table used by DOS simply assigns the value 'A' to all letter A's
regardless of case or accent.
To replace the default character-ordering subroutine, you would need to write
a small program which would set the address of the your subroutine, then
terminate and remain resident.
Warning: the above example subroutine is typed from memory, and may be
incorrect; you will have to trace thru the default subroutine to make sure.
Have fun, and good luck!
- Daniel Kegel
1-60 Caltech, Pasadena, CA 91126
------------------------------
Date: Mon, 10 Mar 86 01:34:41 EST
From: "Keith F. Lynch" <KFL@MC.LCS.MIT.EDU>
Subject: PC's Limited AT Query
To: info-ibmpc@USC-ISIB.ARPA
Does anyone have any info on the PC's Limited AT compatible? Is
it any good? How can it be so much cheaper than the competition?
------------------------------
End of Info-IBMPC Digest
************************
-------