hicks@WALKER-EMH.ARPA (Gregory Hicks COMFLEACTS) (01/17/88)
Info-IBMPC Digest Wed, 12 January 1988 Volume 7 : Issue 2
This Week's Editor: Gregory Hicks -- Chinhae Korea <hicks@walker-emh.arpa>
Today's Topics:
Review of Microsoft C V5.0
Hercules-to-Epson Turbo Pascal code
Network article in ACM Journal (2 msgs)
Character ROM for EPSON printer (2 msgs)
Today's Queries:
BUFFERS vs. ZCACHE.SYS
Real Time operating systems query
Conversion Request for Displaywriter files
HP LaserJet Font Formats
Minix on an AT/Compatible
floppy drive info
Columbia PC floppy controller
Compilers for '386 with large array spaces
INFO-IBMPC BBS Phone Numbers: (213)827-2635 (213)827-2515
----------------------------------------------------------------------
Date: Tue, 24 Nov 87 17:28:15 EST
From: Mark Colan <mtc@ATHENA.MIT.EDU>
Subject: Review of Microsoft C V5.0
I. INTRO
I received the update to Microsoft C, version 5.00. I ordered the up-
date last June; I understand that Microsoft is now shipping the update on
an first-received, first-sent basis.
Getting the new version of C seems to be a wise investment. The
upgrade costs only $75, and you get a lot for that small sum.
The upgrade replaces EVERYTHING in the MSC4 release. I got three re-
placement manuals with binders (for standard MSC, Codeview, libraries,
etc), one soft-cover (400+ page) book for Quick C, and nine distribution
disks. I have only begun to examine the package, and since it is a sub-
stantial upgrade, this review is somewhat superficial.
II. THE MSC5 COMPILER
The new features of the compiler proper include:
faster compile time
faster generated code, particularly for large model
detection of local variables which are declared but not used
full function prototyping ala ANSI and C/2 (the OS/2 C compiler)
built in overlays. For example: cl main.c (ovr1.c ovr2.c) nonovr.c
compiles a program that uses ovr1 and ovr2 as overlays, and
only calls them into memory as needed.
const keyword modifies declarations to indicate that the value should
not change during execution. Its opposite, volatile, is
implemented syntactically (you can specify it) but not
semantically (its just a comment for now)
loop optimization, intrinsic functions
support for code that will be loaded into ROM
new error message numbering
long double replaces long float
new pragmas for local control of various new features - like
optimization types, structure packing, intrinsics
The old "msc" command is gone. They only support the "cl" command to
start the compiler; however, they have enhanced CL to make it more com-
patible with MSC, and give instructions for converting a makefile from
using MSC to CL.
III. RUN-TIME LIBRARY
A. General
There are a number of new calls, many of which are aimed at improving
compatibility with Xenix and Un*x System V, and ANSI C. The few dif-
ferences between MSC4 and MSC5 are offset in the library reference manuals
so that they are quite noticeable. For some reason, most of the new
library calls are named with a leading underscore - like _clearscreen,
_dos_read, _bios_disk.
The manuals says that all ANSI C library functions are now implemented.
There are a family of routine calls to assist in debugging heap (malloc)
related problems. There are new families of routines for DOS and BIOS in-
terfaces and a graphics library; these are further described below.
A single module, setargv.obj, is used for all memory modules for
automatic wildcard expansion from the command line, instead of the MSC4
method of a separate module (ssetargv, etc) for each memory model.
B. New DOS and BIOS Interface Functions
They have a new family of calls for DOS interface functions, which I
really wish had the same names and calling convention as their OS/2 coun-
terparts, but don't. For many DOS calls you used to use int86 to get to,
you can now use a more specific routine name. There are three advantages
to this approach, in my mind: much stronger type-checking for the argu-
ments, since they have templates for the specific DOS functions; smaller
risk of coding errors, since there are fewer arguments to code, on the
average, and you don't have to figure out which register gets which value;
and much more readable code, as the names of these routines are mnemonic
and because there is no temptation to use the DOS function call number.
There is also a similar interface to BIOS functions, for you low-level
hackers.
C. Graphics Library
Another family of function calls that seems very useful implements a
graphics library. I can't yet vouch for the performance for these calls,
but the choice of graphics functions seems well thought out. They imple-
ment a clipping region, logical-to-physical translation, etc. There is
support for using multiple pages, for those adapters which support them (a
question of how much memory on board). You can draw on a page which is not
shown, then flip the active page to show it, while beginning a draw
sequence on another inactive page. This can be used to give the appearance
of lightning-fast drawings and animations.
They support IBM graphics adapters (and their clones) only, however;
there does not seem to be any support for Hercules graphics, or any of the
special modes commonly found on the "super-EGA" clones (that can do
640x480, up to 800x600). The VGA IS supported.
Again, I don't see any counterpart of these graphics functions in OS/2,
and I think they exist as an ALTERNATIVE to Windows (and PM). But they DO
look like they'd be fun to hack around with... and its good that such a
facility exists standard with MSC; it eliminates a multitude of mediocre
graphics libraries available from third-party vendors.
IV. CODEVIEW
I also have not examined CodeView in any detail. I expect that it is
less buggy, but not a great deal different than the original release.
There are a few improvements, though:
can use LIM/EMS memory for CodeView components, allowing you to
debug much larger programs than the original version
interoperability with other MS languages, including MASM (who cares
about the others?)
support for 386 instructions and registers
8087 emulator - debugger displays pseudo-8087 registers as if you
actually had an 8087 installed
complete support for overlaid modules
a few new SYMDEB commands - Compare, Fill, Move, Input, and Output
a utility to compress the symbol table required for CodeView. After
compression, CodeView requires less memory for compressed
symbols, and starts faster. The EXE file is smaller, too.
Last and not least - they include a keyboard template for the enhanced
keyboard! About time...
V. QUICK-C
Quick-C looks great! Its perfect for developing new general-purpose
functions. The Quick-C environment appears to be a text editor with a
function key to compile, run, or debug the resultant program. It is
Microsoft's answer to Turbo-C, and is available separately from MSC5 for a
comparable price, yet comes free with the MSC5 update. Quick-C by itself
seems to justify the cost of the upgrade!
The book is written with new C programmers in mind. Part 1 has chap-
ters for a quick start into the C language and the graphics library. Part
2 describes the interactive environment in good detail, and Part 3
describes the tools used in non-interactive mode.
Although the debugger has many of the same features as CodeView, such
as multiple breakpoints, watching variables, stepping thru the program, and
switching between the QC screen and the output screen, it is NOT CodeView,
but a useful subset.
The book says you CAN use CodeView to debug a program created with
Quick-C.
The user interface to the Quick-C interactive development environment
claims to imitate the Presentation Manager, but in character mode. First
glance shows this to be true. You can use either the mouse or the keyboard
to get at the pull-down menus, and there are accelerator keys available
which are listed the same way as for the PM. The /h switch tells Quick-C
to use the maximum number of lines available for the screen, which is 43
for EGA, 51 (?) for VGA.
You can access any functions from Quick C that are available to MSC5.
They apparently supply the MSC5 library and language reference manuals with
your Quick C purchase! You can access functions written with MSC5 calling
convention in Assembly language, and presumably other other MS languages.
Obviously, the price for quick compilation is very sub-optimal gen-
erated code. This does not bother me, because once you have debugged your
QC program or routine call, you can then use MSC5 to build an optimal ver-
sion of it.
VI. UTILITIES
The ERROUT utility is provided as a hack around DOS's inability to
redirect stderr, which is where MSC's compiler diagnostics are written.
The same #*&! brane-damijed make-like program maintenance utility with
no noticeable enhancements. Why don't they just leave this turkey out of
the package?
The new SETUP utility for installing your compiler is good. It asks
several configuration questions and then builds a composite library with
all of the options you asked for. This will eliminate much of the need to
specify several different libraries. The utility for building a composite
library IS documented, so you could create your own composite from non-
Microsoft libraries.
------------------------------
Date: Wed, 6 Jan 88 12:59 EST
From: P150BK19@VB.CC.CMU.EDU
Subject: Hercules-to-Epson Turbo Pascal code
Procedure HGCopy;
(* This procedure produces a hard copy of a Hercules screen on an Epson-
compatible printer (mode 1) using inline code, which is considerably faster
than the HardCopy procedure provided with the Turbo Graphix ToolBox. On a
Panasonic XK-P1080i, which can print 8-bit double-density graphics (mode 1)
at 6 inches per second, this routine essentially keeps the printer fully
occupied. About half of the speedup over the ToolBox version comes from
using inline code to map the graphics bits to a print row, and the other
half comes from using inline code to print the row itself (instead of a
"write" call for each and every byte of dots). While the procedure uses
variables which are defined from the Graphix ToolBox, owning the ToolBox is
not strictly necessary (of course you must then supply your own drivers).
The key variables are:
GrafBase : segment address of active screen
(hardware screen is $B000);
XScreenMaxGlb : width of screen (in pixels) - 1;
XMaxGlb : (XScreenMaxGlb - 7) / 8; width of screen in bytes - 1;
The screen is mapped to a print row which is 8 bits high, corresponding to
8 scan lines. The Hercules scan lines are stored in 4 sectors, the low
address of which are separated by $2000. Each print row thus contains two
successive scan lines from each sector. It is also assumed that the screen
has 352 scan lines (as is used in the ToolBox, in spite of the Hercules
specification of 348), corresponding to exactly 44 8-bit print rows. This
can also be changed directly in the main portion of the procedure. *)
[HERC-EPS.PAS has been added to the Info-IBMPC Lending Library.]
------------------------------
Date: Wed 06 Jan 1988 15:29:23 EST
From: <JORDAN@LL.ARPA>
Subject: Network article in ACM Journal
In a recent issue of INFO-IBMPC Digest you mentioned an article describ-
ing various computer networks (Fido, Bitnet, Ham Radio, etc.). I cannot
locate the article using the reference you gave - August 87 issue of the
Proceeding of the ACM. In fact I cannot locate the Proceedings of the ACM!
Our librarian has Journal of the ACM, which is a quarterly, not published
in August, and Communications of the ACM which does have an August issue
but does not have the article you referred to. Could you let me know the
correct reference for the article? I imagine the IBM-PC net would also
like to know.
Mike Jordan (JORDAN @ LL.ARPA)
------------------------------
Date: Wed, 6 Jan 88 21:01:35 GMT
From: Gregory Hicks COMFLEACTS <hicks@walker-emh.arpa>
Subject: Network article in ACM Journal
You are correct. The publication is question was the Communications of
the ACM and NOT the Proceedings of the ACM. I published a correction to
the error in Info-IBMPC Digest V6 #74. The original error was Issue V6
#73. The title for the correction was "Alternate Networks". It mentioned
that the article was titled "Notable Computer Networks" published in the
October '86 Issue of the Communications...
Please apologize to your librarian for me for making her do all the
searching.
Again, Regret the error.
Regards,
Gregory Hicks
------------------------------
Date: Wed, 06 Jan 88 20:50:50 -0800
From: Wayne Iba <iba%cip.uci.edu@ICS.UCI.EDU>
Subject: Character ROM for EPSON printer
A friend is looking to upgrade his EPSON MP-80 printer with oriental
alternate characters to allow printing of IBM graphics and scientific
characters. Does anyone (1) have experience with this sort of thing and/or
(2) have any clue as to where to find the ROM chip and how to be sure the
thing will end up working?
Thanks, --wayne
------------------------------
Date: Wed, 06 Jan 88 21:49:58 -0800
From: Rob Kling <kling@ICS.UCI.EDU>
Subject: Character ROM for EPSON printer
There is a company called Dresselhaus Computer in Rancho Cucamonga that
makes an upgrade chip for Epson RX, FX & MX printers to bring it up to the
FX185 class machiines ... with IBM character sets and NLQ.
Their product, "Dots Perfect" liists for $80. I have not used it, but
once saw it favorably reviewed.
Their 800 # (good anywhere ) is 800-368-7737 and their local number is
714-945-5600.
Rob Kling
Information and Computer Science
UC-Irvine
------------------------------
Date: Tue, 5 Jan 88 14:32:20 CST
From: moore@ncsc.ARPA (Moore)
Subject: BUFFERS vs. ZCACHE.SYS
Has anyone compared the value of using ZCACHE.SYS in Zenith's MS-DOS
3.21 _instead_ of the BUFFERS= statement in CONFIG.SYS? If nothing else,
ZCACHE lets you use extended memory to do the caching, rather than wasting
the DOS space. Any comments?
moore@NCSC.arpa
------------------------------
Date: Tue, 5 Jan 88 08:36:19 CST
From: steve@ncsc.ARPA (Mahan)
Subject: Real Time operating systems query
I need a real time operating system for a PC clone (Probably a
Zenith Z-248) that is compatible with DOS applications yet permits time
scheduling and real time interrupts. I would like to do the development
work in the DOS environment, to utilize existing development tools. It
would be nice if the operating system was compatible with NOVELL networks
and standard HPIB cards. Operating system would be used in a real time
data collection and analysis system for the Navy Experimental Diving Unit.
Also, does anyone have any specifics on the 80386 upgrade for the Z-
248 system (clock speed, performance, ordering info, etc..?)
Please reply directly to me; I will summarize responses to the net.
steve@ncsc.ARPA
Steve Mahan
Naval Coastal Systems Center
904-234-4224
------------------------------
Date: Tue, 05 Jan 88 08:55:55 EST
From: Ray Stell <FINPROG@VTVM1>
Subject: Displaywriter files
Does anyone know of any process for converting Displaywriter files to
DOS format. Any suggestions will be appreciated.
------------------------------
Date: Wed, 6 Jan 88 08:18:30 EST
From: Tom Reid <reid%software.org@RELAY.CS.NET>
Subject: HP LaserJet Font Formats
I would greatly appreciate any help in tracking down the file formats
for the HP LaserJet soft fonts.
Thank you.
Tom Reid,
Software Productivity
Consortium, Reston, VA.
------------------------------
Date: Thu, 7 Jan 88 09:20:18 cst
From: krantz%ctrvax.dnet@net.Vanderbilt.EDU (ALAN KRANTZ)
Subject: Minix
There are plans to use Minix to teach an operating system's course next
semester. We have the sources for an IBM-AT but would like to run it on an
HP-Vectra. It doesn't run as is. The best I can tell is that HP has a third
set of interrupts where as an AT has only 2 sets and that the HP is getting
an interrupt minix doesn't reconize. Does anyone have or know of a port of
Minix to an HP-Vectr (an AT clone).
Thanks,
Alan Krantz
------------------------------
Date: Thu, 7 Jan 88 08:22 CST
From: <MADS%UNO.BITNET@CUNYVM.CUNY.EDU>
Subject: Floppy Drive Technical Information Request
Wanted: Technical information on Shurgart SA 450 double density drives.
The Shugart SA 450 drive was used on older Kaypro II computers and
Xerox 820s and, probably, Big Boards. I would like a technical manual or
sufficient information to configure it for an IBM PC clone. I can read PC
diskettes ok but can't write to the disk.
Please contact me directly via BITNET.
mads@uno
------------------------------
Date: Thu, 7 Jan 88 14:21:03 EST
From: Kenneth Van Camp (US Army FSAC) <kvancamp@ARDEC.ARPA>
Subject: Columbia PC floppy controller
My father-in-law recently picked up an old Columbia PC for a song, and
promptly proceeded to fry the floppy disk controller by plugging it into a
hard disk. He found a local dealer that used to carry the Columbia line
who says the Columbia cannot take a standard IBM PC-compatible floppy disk
controller. (The bus looks the same to me; presumably there are some
timing problems?) The dealer said he has been waiting for several months
for one for his own Columbia, but even he can't get them. My father-in-law
also found one mail-order dealer (name unknown to me) who gave him pretty
much the same story.
My questions are: (1) Is it true that a standard PC floppy controller
will not work with the Columbia; and (2) Does anyone know of any sources we
might contact who might have the Columbia floppy controller in stock?
--Ken Van Camp <kvancamp@ARDEC.ARPA>
------------------------------
Date: Thu, 7 Jan 88 16:16 CST
From: KOEHLER%SASK.BITNET@forsythe.stanford.edu
Subject: Compilers for '386 with large array spaces
I want to do some numerical plasma simulations. I know that I can do
them by spending lots of money to buy CPU cycles on one of the campus main-
frames but it occurs to me that I might do better buying something like the
new Compaq 386/20 with co-processor, lots of memory etc and get the same
result for about the same expenditure. Even if it takes longer, I end up
with the machine to boot.
My question is the following. Are there any existing '386 com-
pilers (any of Fortran, Pascal or C) which allow one to access LARGE arrays
(say 1000 by 1000) directly AND which can use the Weitek co-processor? I
don't care whether the compiler uses machine memory either directly as ar-
ray space or if it simulates it with 'virtual memory' in which the machine
memory would be used as RAMdisk (or both). The point is that I don't want
to 'program around' the problem of large arrays by using pointers to files,
etc. It would probably be too expensive computationally.
Hopefully this question has been asked before and someone can just
point me to the answers?
Jim Koehler
------------------------------
************************
End of Info-IBMPC Digest
-------