Info-IBMPC@USC-ISIB.ARPA (Info-IBMPC Digest) (03/18/86)
Info-IBMPC Digest Tuesday 18 March 1986 Volume 5 : Issue 35
This Week's Editor: Billy Brackenridge
Today's Topics:
Correction to Turbo Pascal Fast Screen Write
UCSD Pascal from Pecan Software
High Performance w/o an AT!
Turbo Pascal Screen Clearing
Nansi Bug Fix & Binaries Available
ClickArt Personal Publisher from T/Maker
Correction to Address of AK Technology
Microsoft C Bugs
Directories from Turbo Pascal
Directories from Turbo Pascal & Wang Compatibility
Wang Compatibility
MASM 4.0 OFFSET Bug (2 Msgs)
Microsoft Fortran & F77 (2 Msgs)
NBI to PC-DOS (and CP/M) Connections
Turbo Pascal Colors
XT/370 Speedup
XENIX Updates
Todays Queries:
MS-Windows Drivers
Pascal to C Translator
Symphony & MSWindows
DisplayWrite 3 EGA Support
FORMAT Equivalent Within a Program (2 Msgs)
Zenith PCs at Govt Contract Prices
Xenix Device Driver
Document Indexing Program
BRIEF vs EPSILON
----------------------------------------------------------------------
Date: Thu, 13 Mar 1986 15:26 CST
From: Dean Hoyt <NU068450%NDSUVM1.BITNET@WISCVM.WISC.EDU>
Subject: Correction to Turbo Pascal Fast Screen Write
In the file that I sent you about writing to the screen quickly in turbo
pascal I had the address wrong. They should have been
for the mono screen $B000:$0000
for the color screen $B000:$8000
Please if possiable correct the file I sent you. If not then add a notice
about this correction.
Dean hoyt
Bitnet address NU068450@NDSUVM1
Arpanet address NU068450%NDSUVM1.BITNET@WISCVM.WISC.EDU
where the wind chased the hills away.
[We didn't catch this in time. The local archives have been updated. -ed]
------------------------------
Date: Sat, 15 Mar 86 22:19 EST
From: Yedidyah Langsam <YDLBC%CUNYVM.BITNET@WISCVM.WISC.EDU>
Subject: UCSD Pascal from Pecan Software
Pecan Software has released UCSD Pascal working under a DOS Hosted
P-system. The compiler can produce either native code or P-code for the
IBM PC. This DOS Hosted p-system seems to be fully compatible with DOS.
It is a full implementation of Pascal. Since Pecan software simply
developed (or re-released it) the DOS hosted version of the P-system
without tampering with the compiler, it should be bug free and be
compatible with APPLE UCSD Pascal.
Pecan Software advertises heavily these days in Byte, PC WORLD and PC
Magazine.
I have no connection with them, other than having tried the system. The only
incompatibility I have found is that it will not work when Borland Lightning
is in memory. At $79. for the whole system, you can try it out....
------------------------------
Date: Sat, 15 Mar 86 22:20:09 cet
From: 10409813%WSUVM1.BITNET@WISCVM.WISC.EDU
Subject: High Performance w/o an AT!
For those of you who might care... I put a NEC V30 in my AT&T PC 6300
this weekend. The NORTON SysInfo rating went from a mediocre 1.9 to a
rather impressive 3.9! Overall performance (not just the mul/div that
SI tests) is up about 20-30% based on a DHRYSTONE benchmark. Results
of the benchmark went from 833 to 1086 dhrystones/sec. This is about
the same performance as a 6Mhz PC/AT! Considering that the 8087 runs
at 8Mhz and therefore outperforms the PC/AT on Floating Point operations
I am extremely glad that I didn't spend an extra 2000 dollars or so for
a "better" machine.
Also get DESQview and simply love downloading with KERMIT in the background
while doing real work in the foreground. This works quite well, and should
promise to increase productivity significantly.
Eric Schneider 10409813 @ WSUVM1 . BITNET
eric @ wsu . CSNET
------------------------------
Date: Sun, 16 Mar 86 12:39 EST
From: MKATZ%UMDB.BITNET@WISCVM.WISC.EDU
Subject: Turbo Pascal Screen Clearing
From: Jameson@UNCA-MULTICS.MAILNET
Does anyone know of a patch which will stop Turbo Pascal programs from
clearing the screen before they run, and possibly from leaving the
cursor at the bottom of the screen afterward? Many thanks.
Turbo Pascal 3.0 no longer clears the screen at the beginning (2.0 did),
but it still jumps to the bottom at the end. I suppose you could force
it to exit without jumping to the bottom by closing all files and then
calling DOS to exit instead of exiting normally through Turbo.
Manasseh Katz
------------------------------
Date: Sun, 16 Mar 86 00:36:32 PST
From: kegel%Juliet.Caltech.Edu@Hamlet.Caltech.Edu
Subject: Nansi Bug Fix & Binaries Available
To: cc.dlnash@a20.utexas.edu, info-ibmpc@usc-isib.arpa
Two notes about Nansi:
1. Peter Lyman at JPL informs me that the Nansi source file nansi.asm
had a TAB character in the device name field instead of five spaces;
this makes the device name field the wrong length. The device loaded,
but its name was CON\t%$#** or some such garbage; I think that INT 29 was
installed properly, so it probably worked on single-character writes.
the device chain for the device name, and would have fallen thru to the
default CONsole driver! Talk about mysterious symptoms...
The tab was inserted by an editor that thought it was doing
me a favor, I suppose; anyway, this is a serious problem, and anyone who
got the sources should change the line in nansi.asm that reads
db 'CON ' ; (8 chars)
to read
db 'CON' ; (3 chars...
db 5 dup (20h) ; ... and 5 blanks)
to avoid future screwups. Somebody at ISIB should change their copy, too.
(Congratulations to Peter for cracking this problem.)
2. I am posting a binary version of Nansi on my machine
for people who don't have MASM. The three files are as follows:
nansi_doc.cat - Documentation, examples, and Intel hex version of Nansi.sys.
nansi_src.cat - Source code.
nansi_demo.cat - Documentation and Intel hex code for view.com, a vi-like
file viewer which demonstrates the full speed of nansi.sys.
In case it matters, the files are on the local directory USERS:[ANONYMOUS].
You should log in using FTP to hamlet.caltech.edu with username anonymous and
password ftp. (Hamlet and Juliet share file systems, but only Hamlet is
supposed to be visible from Arpanet.)
Finals-weekly yours,
Daniel Kegel
[NANSI.CAT has been updated. The tab character was there! -ed]
------------------------------
Date: Sat, 15 Mar 86 19:54:26 pst
From: adobe!wff@decwrl (Ware and Freidenrich)
Subject: ClickArt Personal Publisher from T/Maker
A significantly more sophisticated (but not that much more expensive)
program than Newsroom is ClickArt Personal Publisher from T/Maker
Company in Mountain View, California. T/Maker is at 2115 Landings Drive,
Mountain View, California 94043, (415) 962-0195.
Personal Publisher is a WYSIWYG desktop publication tool that works with
dot matrix, HP LaserJet, and Apple LaserWriter printers. T/Maker's
popular ClickArt clip art files which have been reproduced on 5 1/4" media
and can be read by Personal Publisher into a document.
Carey Heckman
------------------------------
Date: Sun, 16 Mar 86 13:17:14 est
From: Mark D. Freeman <mdf@ohio-state.ARPA>
Message-Id: <8603161817.AA09854@ohio-state.ARPA>
Subject: Correction to Address of AK Technology
Corrected version:
AK Technologies Corporation
Columbus, Ohio
(614) 764-0737
I do have financial ties to this company, but not in regard to CXI products.
[AK Tech makes the IRMA replacement board and software for IRMA cards. -ed]
------------------------------
Date: Sun, 16 Mar 86 12:44:27 PST
From: Matthew J Weinstein <matt@LOCUS.UCLA.EDU>
Subject: Microsoft C Bugs
It appears to be unsafe in general to declare a single 'register'
variable in MS C large model in the presence of structure-valued
functions. The following type of code will break for some values of
STREXP[12]:
struct any {...};
int IntValued(struct any);
proc() {
register i;
...
if (IntValued(STREXP1) < IntValued(STREXP2)) {
}
}
where STREXP[12] are structure valued expressions (such as StrucFunc()
or (*(struct any *)"data")). Generally speaking, replacing the register
declaration with an integer declaration fixes the problem.
Microsoft has indicated that there will be no interim fix.
- Matt
------------------------------
Date: Sun, 16 Mar 86 12:44 EST
From: MKATZ%UMDB.BITNET@WISCVM.WISC.EDU
Subject: Directories from Turbo Pascal
To: CHADM1%UCONNVM.BITNET@WISCVM.WISC.EDU
There is a Turbo Pascal kermit available from KERMSRV@CUVMA which includes
a DIR routine for MS-DOS and for CPM-80 (I am working on one for CPM-86).
The pertinent programs are in QKKER.PAS, look for SYSFUNC.PASMS in that.
Manasseh Katz
------------------------------
Date: 16 Mar 1986 21:37-EST
Sender: ABN.ISCAMS@USC-ISID.ARPA
Subject: Directories from Turbo Pascal & Wang Compatibility
From: ABN.ISCAMS@USC-ISID.ARPA
Could someone tell me how to get a directory listing from a running
(compiled) TURBO PASCAL program on the IBM PC? Is there an assembler
routine that can be imbedded in the source code? Is there a DOS
routine one can hook to? Thanks.
Carl David
In MARKET's TURBOPAS directory:
MSLIB.PAS -- several routines that use DOS interrupts, etc. Two include
directory-related routines.
(Since Carl David has an address outside the ARPA, I'll forward this
code separately.)
RDIR.ARC -- Haven't downloaded this, but it's directory related and
should have appropriate procedures for MS-DOS.
Does anyone know why the WANG PC doesn't run "normal" packages like MS
DOS 3.1, Turbo Pascal, Wordstar, The IBM Personal Editor (just to name
a few packages I tried). I always get an error "Invalid/Unrecognized
Interrupt" or the PC just freezes up. Any suggestions are welcome.
Marc Chang Sing Pang
Compadre, Wangs were never claimed or sold as PC-compatible. For one thing,
they don't implement Int 10H (all the PC video stuff)! You can't even just
stuff bytes in video memory and expect something to appear .. gotta hit
another interrupt to force a refresh!
Heck, they don't even provide DEBUG with their usual menu systems. It also
fires up with Interrupt error messages, but appears to run (kind of).
I wouldn't even claim MS-DOS 2.0 "compatibility" for the Wangs since I've
personally tried to run programs I've checked for pure MS-DOS 2.0 functions
only .. and had them fail!
I purchased a "generic" MS-DOS version of Turbo Pascal 3.0, and
(thanks to some pointers from a kind NetLandian) managed to configure
it to a peculiar "almost ANSI" terminal that was supposed to work
with Wang PCs. I can now compile and run Turbo Pascal programs on a
Wang PC (and still have them fairly presentable (if limited) on PC
clones. But dumb dumb dumb Wang .. thought they'd learn from TI it
doesn't pay to try a "closed architecture."
David Kirschbaum
Toad Hall
ABN.ISCAMS@USC-ISID.ARPA
------------------------------
Date: Sun, 16 Mar 86 10:52:26 EST
From: Chris Schmandt <geek@MEDIA-LAB.MIT.EDU>
Subject: Wang Compatibility
Cc: singpang%hlerul5.bitnet@wiscvm.arpa
The Wang is fairly DOS level compatible with the IBM, but definitely
*not* BIOS compatible. Most likely your problem with "invalid interrupt"
is that the software is using a Bios call like INT 10H to write
directly to the screen. I've often considered writing my own version
of the Bios screen driver for the Wang, not a formidable task, but
never have the time.
There is some Wang product, that I think includes a new display board,
that allows full PC emulation.
------------------------------
Date: Mon, 17 Mar 86 10:50:39 est
From: dewar@nyu-acf2.arpa
Subject: MASM 4.0 OFFSET Bug
In a recent message, I noted that OFFSET does not always work in MASM
4.0. The editor noted that you could use LEA instead. Three quick comments
on this suggestion:
First, least serious, LEA is slower than MOV immediate
Secoond, in the example I had, LEA would not have worked, since I had
BP indexing present. LEA would have included this indexing, OFFSET
should have excluded it.
Third, most subtle, at least in the Intel semantics, OFFSET and LEA are
different in the presence of GROUPS. LEA will use the current ASSUME's
to obtain the segment for the relocation target. OFFSET will always
use the segment as the target relocation, unless you provide an explicit
GROUP: override. I have no idea what microsoft does here, but beware!
------------------------------
Date: 17 Mar 1986 10:08:31 PST
Subject: MASM 4.0 OFFSET Bug
From: Richard Gillmann <GILLMANN@USC-ISIB.ARPA>
To: dewar@NYU-ACF2.ARPA
I certainly agree that it would be desirable to use OFFSET if it
assembled correctly all the time. Using LEAs is just a work around,
but it's never failed me yet. If someone could formulate rules for
when it's safe to use OFFSET, that would be a big help. The way
LEA works in the presence of GROUPs is consistent with the way
Microsoft Pascal and C work, which is my main use of GROUPs.
[The Microsoft assembler/linker has gotten better over the years. See
some of the earliest INFO-IBMPC digests for horror stories. The
OFFSET bugs have been particularly difficult to trace. Sometimes the
linker catches an error other times it just generates wrong code.
Dick had some modules that were stable for years, and when other code
was added to the system suddenly the modules would go bad and always
the OFFSET operator was at fault. Of course it never failed in simple
test cases only when large multi segment links were involved. I gave
up using macros back with MASM 1.0 and even though MASM 4.0 is much
improved I still don't trust the assembler and try to keep my
assembly programs short and simple. -wab]
------------------------------
Date: Mon, 17 Mar 86 13:20:29 cst
From: pool@anl-mcs.ARPA (Pool)
Subject: Microsoft Fortran & F77
The most current release of Microsoft Fortran is a rather poorly
defined subset of F77. It is not easy to determine PRECISELY
which features of F77 have been deleted by straightforware reading
of the manuals.
Jim Pool
Numerical Algorithms Group
ARPANET: pool@anl-mcs
USENET: ihnp4!nag!pool
------------------------------
Date: Mon, 17 Mar 86 10:28:36 EST
From: Bernard_Tiffany%UMich-MTS.Mailnet@MIT-MULTICS.ARPA
Subject: Microsoft Fortran & F77
The latest Microsoft MS-DOS version (3.31) of FORTRAN implements
the subset of FORTRAN 77 with extensions to the full set. The last
time I've heard is that Microsoft is working on the full set as
their Apple MacIntosh version of FORTRAN 77 does implement the full
set.
The following are FORTRAN 77 full set features not implemented in
MS FORTRAN:
(1) Comments cannot be followed by a continuation line.
(2) The following statements are not yet available:
CHARACTER*(*) statements (length specification is an asterisk)
ENTRY statement
SAVE statement without a list
PRINT format, list
READ format, list
character statement functions
(3) The forms UNIT= or FMT= cannot be used in READ or WRITE
statements. These forms can be replaced by discarding "UNIT="
and "FMT=". A character array name may not be used as an unit
identifier or a FORMAT parameter in these statements.
(4) The edit descriptor Iw.m is not used in FORMAT statements. All
other edit descriptors are implemented.
(5) The OPEN statement cannot have STATUS='SCRATCH', STATUS=
'UNKNOWN', BLANK='ZERO', or BLANK='NULL'. To simulate the
BLANK parameter, the format edit descriptor BZ or BN may
be used. The UNIT parameter cannot be specified in the OPEN
statement.
(6) The CLOSE statement does not have UNIT and ERR parameters.
(7) BACKSPACE, REWIND, and ENDFILE do not have UNIT, ERR, and
IOSTAT parameters.
(8) All lower bounds of an array must be equal to 1.
(9) The DO variable cannot be REAL or DOUBLE PRECISION.
(10) DATA statements cannot have implied DO's.
(11) SUBROUTINE statements cannot have dummy arguments (expressed
as *).
(12) Expressions (other than constants or PARAMETER names) cannot
be used in dimensions or lengths for CHARACTER statements.
(13) Character concatenation operator // is not implemented but
can be simulated using substrings. The character functions
INDEX and LEN are not available.
------------------------------
Date: Mon, 17 Mar 86 15:56 EST
From: Paul.Birkel@A.CS.CMU.EDU
Subject: NBI to PC-DOS (and CP/M) Connections
I've received a number of responses to my query last month, and made a
number of phone calls. Here's what I found out:
There are three and two-halves solutions to my problem. As you would
expect, functionality is proportional to cost.
The first solution, and the most cost-effective one, is a piece of software
which NBI had Microsoft write about two years ago. It took a little while
to figure this out, but it's called:
OASys 4000SC MS-DOS Conversion Utility
This assumes, of course, 5 1/4" disk drives. This package allows you to
read and write such disks (DSDD - 48 tpi) plus it allows some mapping
between WP tokens and ASCII characters. The mapping is limited but does
take care of things like CR/LF, tabs, backspaces and form feeds so that
your ASCII files will be in a readable "generic" form. There is no
"format code/command mapping". It runs on all MS-DOS machines (NBI has
their own clone, the 4100PC), and costs $200. One caveat on the AT is that
you have a problem with the 96 tpi drive since the 4000SC is (typically,
unless you have the "high capacity" drives) equipped with 48 tpi drives.
The solution is to buy a second 48 tpi drive, about $100 additional plus
your effort in installing it (easy). That totals $300 and buys you a
simple, direct file transfer not dependent on physical proximity. For a
CP/M'er use a similar transfer program (Media Master, Uniform, etc.) to
go from CP/M to MS-DOS first. Unfortunately, I couldn't find any software
supporting a direct CP/M to 4000SC route. Sigh.
Solution one and one-half is a NBI card known as the M-400. It costs $700
and buys you a 68B00 (remember the Commodore PET?)-based co-processor running
an early version of WP called "Docu-Writer". It also reads and writes NBI
disks and resides on the PC bus. Although "Docu-Writer" is less powerful
than WP, it offers the same interface as WP so that your word processing
skills transfer easily. It runs in most (all?) PC/PC-XT clones. It DOES
NOT run in the AT/AT-clones due to the higher system clock speed. It appears
likely that it never will as NBI has other plans for AT owners. If you don't
have an AT-type machine and you would like to leverage your WP skills then
this card may be for you since you still get the MS-DOS conversion utility
functionality discussed above.
The other solution one and one-half, is a commercially available box for
disk conversions:
Keyword Office Technologies, Inc.
2816 11th Street NE
Calgary, Alberta, T2E 7S7
(800) 227-1817 x825A
Two US (West Coast) offices:
649 Mission at New Montgomery
San Francisco, CA 94105
(415) 543-5426
Contact: Deborah McAfee
2047 E. Hamilton Ave.
San Jose, CA 95125
(408) 371-7770
The list price for the Keyword 7000 is $7996 (US).
Solution number two is based on a serial link between the NBI and the target
machine. This requires the NBI ASYNC/BISYNC Advanced Communications package
which will run you $2500, plus the cost of an external modem and installation.
All told you're touching $3,000. What you get is the ability to do terminal
emulation-like things and serial file transfers. You also get a software
package called TAILORS that lets you do very reasonable (but apparently not
complete) mappings between the file formats on each end. You use your own
word processor on the PC-DOS/MS-DOS or CP/M or what-have-you end and one
of the commercially available communications packages. Of course you may need
either two modems, or proximity in order to run a cable, but you get added
flexibility. Like to take your dBase or 1-2-3 file and ship it over to the
NBI to put into a document? Well, TAILORS is supposed to make that possible.
But it's not cheap.
Solution number three is the Rolls-Royce of systems; the System 64, or OASys.
It'll run you upwards of $15,000 and more depending on configuration. What it
buys you in this context is:
1) A star-organized LAN with a PC-DOS 8086 central processor, hard
disk, and 6809-based channels.
2) Transparent file access from any "device" where "device" may be
an NBI machine, or a PC-class machine, including file format conversions.
3) The ability to run WP through your PC-class machine (actually
on the 6809 <I think>). You can even run WP from home over a dial-up line.
This is only a brief description, but you get the general impression.
Slick, but a rather expensive for my needs.
This investigation has been an education for me. Although I still think
that technically the 4000SC is not impressive for the price (one can go
buy a PC plus a major word processing package for less), what you do
get is hand-holding and a clear upgrade path: a networking solution.
Although I won't pay that much for the hand-holding, many office automation
managers will (and perhaps reasonably so). My problem in initial NBI contacts
was probably due to too much knowledge and too little understanding of the NBI
philosophy/market-place on my part. I've had many contacts with NBI personnel,
and all have been pleasant and helpful, but it was a user of NBI equipment on
this net that actually pointed me to the disk conversion solution.
While I'll probably never buy NBI equipment, if I were responsible for
automating a large word processing environment I'd certainly consider NBI,
especially since they appear to be offering a reasonable LAN solution while
IBM is still (basically) dithering.
So . . . back to the beginning:
Can anyone tell what the actual format of a 4000SC 5 1/4" floppy is so that
I can roll my own CP/M conversion utility?
Paul A. Birkel
Dept. of Computer Science
Carnegie-Mellon University
Pittsburgh, PA 15213
(412) 628-3074
------------------------------
Date: Mon, 17 Mar 1986 17:53 EST
From: Jim Ennis <JIM%UCF1VM.BITNET@WISCVM.WISC.EDU>
Subject: Turbo Pascal Colors
To: info-ibmpc <INFO-IBMPC@USC-ISIB.ARPA>
Hello,
Can anyone tell me how to set the colors for the editor/envrionment
in Turbo Pascal. I don't like the brown on black and I would appreciate
any help in changing the colors.
Thanks,
Jim Ennis
University of Central Florida
JIM@UCF1VM.BITNET@WISCVM.ARPA
------------------------------
Date: Mon, 17 Mar 86 12:35:06 PST
From: Bruce_A._Cowan%SFU.Mailnet@MIT-MULTICS.ARPA
Subject: XT/370 Speedup
I put a little module in my XT370 that runs the 8088 at about 6.7MHz
instead of the normal 4.77. The 8088 runs fine, but the 370 part
fails with the fast clock. The module I plugged in is potted in
epoxy so I don't know exactly what it does, other than feed the 8088
a faster clock (and I don't have a PC/XT Tech reference to look at
the schematic), but I'd guess that the processor clock also ends up
on the CLK line on the bus and that the 370 card uses that for its
processor clock.
Since the AT/370 uses the same 370 processor chips, and it runs with
a 6MHz clock, I'd guess that it ought to be possible to speed up the
XT/370 at least that far. However, the CLK signal on the AT's bus is
6MHz with a 50% duty cycle, whereas on the PC it is 4.77MHz with a
33% duty cycle. So, 6MHz with 33% duty cycle might be outside the
capabilities of the 370 processor chips.
I'm planning to try changing my XT/370 to 7.16MHz with a 50% duty
cycle as soon as I can get an 8MHz NEC V20. I'll let people know if
that works.
------------------------------
Date: Tue 18 Mar 86 08:40:32-PST
From: William Pearson <PEARSON@SUMEX-AIM.ARPA>
Subject: XENIX Updates
There have been several questions lately on what IBM updates are
available and how to use non-standard (non 20 Mbyte) hard disk drives
with IBM PC/XENIX for the AT. Although I was able to get the disk installed
without the IBM updates, I finally received them and they would certainly
have made the process easier. There are two updated disks available from
IBM (that I know of), I requested them through the IBM dealer I bought XENIX
from (he was not able to find them until I gave him exact names) and
received them from
IBM
PC Assistance Ctr/Zip 4409
1000 NW 51st Street
Boca Raton, FL 33431
I received two disks, one dated 6/85 and titled:
IBM Personal Computer Xenix 1.0
Soft Dev Sys Maintenance Diskette
and one dated 9/12/85 titled:
IBM PC XENIX
INSTALLATION DISKETTE
1.01
9/12/85 850919A
I was curious what had changed with the new installation diskette,
so I checked the dates on the files, and found most changes dated
6/85 or 9/12/85. I have included a list of the modified files below.
fd
Jun 26 1985 bin
Jun 25 1985 boot
Jun 26 1985 etc
Sep 12 1985 tmp
Jun 24 1985 xenix
Jun 25 1985 xenix.fd
fd /bin
Jun 26 1985 adb
fd /etc
Jun 24 1985 badtrack
Jun 24 1985 boot1
Jun 24 1985 fd96boot0
Sep 12 1985 fdisk
Jun 24 1985 hdboot0
Sep 12 1985 hdinfo
Sep 12 1985 hdinit
Sep 12 1985 mnttab
Sep 12 1985 utmp
Sep 12 1985 xinstall
fd /dev
Sep 12 1985 console
Sep 12 1985 fd0
Sep 12 1985 fd096
Sep 12 1985 fd096ds15
Sep 12 1985 hd00
Sep 12 1985 hd0a
Sep 12 1985 null
Sep 12 1985 rhd00
Aug 30 1985 rhd0a
Aug 30 1985 rhd10
Sep 12 1985 root
Sep 12 1985 swap
There are several other updates from Microsoft that IBM has
apparently not yet distributed, which means they are virtually unavailable
(the receptionist at Microsoft was very rude when I asked about them)
including one dated 12/85 which provides the huge compiler model. But
the Installation Disk 1.01 is the one you need for non-standard drives.
Bill Pearson
-------
------------------------------
Date: Sun, 16 Mar 86 23:13:01 PST
From: kegel%Juliet.Caltech.Edu@Hamlet.Caltech.Edu
Subject: MS-Windows Drivers
About Microsoft Windows:
Microsoft only supports the IBM CGA and EGA graphics boards as of now
(although I hear rumors of something great in the wind).
Do any graphics board manufacturers, or graphics software houses,
have Windows drivers for their products?
(What I'm secretly hoping for is a 640x480 16 color board with a real
palette and most of the Windows routines implemented in silicon...)
- Daniel Kegel
[As has been mentioned in recent digests the Genius display has a MS Windows
driver. I spoke with the manufacturer in our unsuccessful attempt to get a
working BIOS from them. At the time they were quite excited by the MS Windows
drivers. I gather Microsoft developed the drivers even though the Genius isn't
one of the "official" Microsoft supported devices. MSWindows already takes up
enough distribution disks. -wab]
------------------------------
Date: Mon, 17 Mar 86 08:24:17 est
From: Scott Guthery <sguthery%slb-doll.csnet@CSNET-RELAY.ARPA>
Subject: Pascal to C Translator
Does anyone know of a good Pascal to C translator for the PC? The
operative word is `good'. Thanks, Scott
------------------------------
Date: 18 Mar 86 10:37-EST
From: R.Rasulis <ext715%BOSTONU.bitnet@WISCVM.arpa>
Subject: Symphony & MSWindows
Has anyone had any luck running Symphony w/ MS Windows? It doesn't work
using MS WIndows off the shelf, so you must have had to "fix" it.
Please share your patch w/ me.
Please reply directly to me
*eom :- R.Rasulis -:
------------------------------
Date: 18 Mar 86 12:18 EST
From: Jim Moore <moore@ncsc>
Subject: DisplayWrite 3 EGA Support
To: info-ibmpc@usc-isib
I've tried this before with no response, but here goes again:
If you use DisplayWrite X.XX with and EGA, how do you get ON-SCREEN
underlining and boldfacing??? Any help is appreciated.
[In a later message Jim Moore added that published reports claimed
bold and underline was possible on the EGA, but he is only able to get
colors. Unfortunately an editor crash lost this paragraph of text. -wab]
Jim
Naval Coastal Systems Center
------------------------------
Date: Sun, 16 Mar 86 04:56:45 PST
From: dgb%DEImos.Caltech.Edu@Hamlet.Caltech.Edu
Subject: FORMAT Equivalent Within a Program
Does anyone out there know exactly what is involved in doing the
equivalent of a DOS FORMAT from within a running program? We have an
application where is it advantageous to leave a program running for days
at a time, acquiring radio spectra. The observers aren't too good about
keeping a supply of formatted floppies around, and one of these days they're
going to find themselves with a full memory of data, and no blank floppies
to write it to. There is no other PC for many miles of the observatory, so
this could potentially be a real problem. Since we need all the available
RAM we've got, I'm rather loathe to set aside the 30K+ that I would need to
spawn a new command interpreter to run FORMAT. I would much rather use a
program overlay. Does anyone know exactly what is involved?
1) This routine would only need to operate on data floppies, so that
I don't have to deal with getting a system set up. The drives in
question are 'standard' D9 format. Ie. DSDD, 360K, 40 track, etc...
2) The BIOS can do the hard work of actually formatting the disk. The
tricky part is going to be setting up all the DOS work areas such as
the boot track, directory, FAT(s).
3) It will be running on a two floppy system, so I can cheat, and copy
the boot track from the system disk. (I would prefer to avoid this,
and might just store a copy of the boot track in memory, to avoid
problems when running on the HD based development systems. Any better
ideas?)
4) I have the usual refs for such things. DOS technical apendix, Tech
Ref, Peter Norton's book, etc. I might be able to piece a workable
routine from that, but I would be worried that some critical field
wasn't getting initialized or something. I don't want to have data
floppies floating around with 'bombs' in them from my homebrew format
routine. I would really like to hear from someone who knows the
subject!
If it's too much of a hassle, I won't worry about it, and just renew
my efforts to get our people to format the floppies when they buy
them. But I just know that we're going to see trouble from this one
day.... As usual, thanks in advance for any help.
--Daniel Briggs
dgb@DEImos.Caltech.Edu
------------------------------
Date: 16 Mar 1986 18:33:35 PST
Subject: FORMAT Equivalent Within a Program
From: Billy <BRACKENRIDGE@USC-ISIB.ARPA>
To: dgb%DEImos.Caltech.Edu@HAMLET.CALTECH.EDU
The Tall Tree products for RAM disk emulation and the JFORMAT program
all come with source code. It would be a good place to start looking
to write such a routine.
Tall Tree Systems
(415) 964-1980
Tech Info
(415) 964-1397
-------
------------------------------
Date: 16 Mar 86 11:25:02 GMT
From: brad @ DCA-EUR.ARPA
Subject: Zenith PCs at Govt Contract Prices
When Zenith had their first contract with the AF/Navy a
couple of years ago for Z-100s, Government Employees Association
(GEA) worked out an arrangement with Zenith to sell Z-100s to
individuals connected with the Govt at the Contract Price.
Question: Does anyone know if an organization, such as GEA, is
working out a similar arrangement with Zenith for the new contract
with the Miliary?? Those of us working for the Military in
Stuttgart Germany are very interested.
Brad
------------------------------
Date: Mon, 17 Mar 1986 12:34 O
From: Guy Sirton <MLSIRTON%WEIZMANN.BITNET@WISCVM.WISC.EDU>
Subject: Xenix Device Driver
I am having problems writing a device driver in XENIX (V1.0 running on
a regular PC-AT).
The problems are:
1) Accessing storage (for memory-mapped devices). I overcame this problem
by defining a 'far' pointer but I am wondering if there is any built-in
kernel routine to do it.
2) Creating the new kernel. When I type 'make' in /usr/sys/conf I get
the following result:
ld: Unresolved extrenals:
__stkgro in file(s):
/lib/Mlibc.a(~_chkstk.o)
__Syspc in file(s):
/lib/Mlibc.a(exit.o)
__syscal in file(s):
/lib/Mlibc.a(exit.o)
*** Error code 1
Stop.
3) Poor documentation. The documentation at the lowest level is really poor
some routines (such as seterror() ) are mentioned but not explained and I'm
pretty sure (by 'string'ing lib_io and the kernel) that there are routines
that aren't even mentioned. The index is also in a very poor state...
Anyone who can help me in these problems and/or has a list of un-documented
routines please mail me back.
Guy
------------------------------
Date: 17 Mar 86 13:36 PST
From: Ghenis.pasa@Xerox.COM
Subject: Document Indexing Program
What are the available programs for creating a table of contents and
index for a WordStar document, both public domain and commercial? How
capable and user-frienldy are they?
Thanks in advance.
------------------------------
Date: Sun, 16 Mar 86 10:43:14 pst
From: George Cross <cross%wsu.csnet@CSNET-RELAY.ARPA>
Full-Name: George Cross
To: info-ibmpc@usc-isib.arpa
Subject: BRIEF vs EPSILON
I am trying to decide between BRIEF and EPSILON. Is there someone out there
who has used both? The way I read it, BRIEF and EPSILON are emacs-like,
fully customizable in Mock-Lisp (respectively Mock-C), but EPSILON supports a
kind of multi-tasking so you can continue editing while compiling and BRIEF
does not. What about performance? (Especially assuming a floppy-only system)
---- George
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
George R. Cross cross@wsu.CSNET
Computer Science Department cross%wsu@csnet-relay.ARPA
Washington State University faccross@wsuvm1.BITNET
Pullman, WA 99164-1210 Phone: 509-335-6319 or 509-335-6636
[We still keep our version 2 epsilons around for running on floppy
disks. While the newer versions run just as fast on a hard disk
system the older is still useful when floppy disk space is at a
premium. Even with a floppy only system for another $400 you can get
a 2MB JRAM card and edit any sized file with either version. -wab]
------------------------------
End of Info-IBMPC Digest
************************
-------