Info-IBMPC@USC-ISIB.ARPA (Info-IBMPC Digest) (02/28/86)
Info-IBMPC Digest Thursday, 27 February 1986 Volume 5 : Issue 28
This Week's Editor: Richard Gillmann
Today's Topics:
Time and Date from Turbo Pascal (4 msgs)
Kermit+Lightning = Rubbish
NANSI.ASM (2 msgs)
Connecting to NBI Machines (2 msgs)
QUICK-BASIC Comm Files
Experience with QNX Operating System
Thanks to MicroSoft
Compiling Really Large Programs With Microsoft C V3.0
Color & Mono Cards in AT
FAT City Blues - and how I fixed my hard disk
ProComm
Re: Lotus printer problem
More SIG/M and PC/BLUE Volumes Available
Today's Queries:
QuicKey.asm Wanted
Microsoft MASM Assembler Wish List
Problem with 27 Lines on the EGA
Cluster Size Query
Prolog Query
TRS Model 100 to IBM XT Connection Wanted
XT-clone motherboard query
Color Attribute Query
Problem with MS-DOS command line length
Intel 80186 Assembler Query
Query: PCnet <--> 3Com Ethershare "Gateway"
Window Package for Xenix Wanted
dBASE File Format Query
----------------------------------------------------------------------
Date: 23 Feb 1986 22:09-EST
Subject: Turbo Date/Time Code
From: ABN.ISCAMS@USC-ISID.ARPA
To: info-ibmpc@USC-ISIB.ARPA, bschaar@USC-ISIF.ARPA
The request was for pointers to articles (or code) on date-time
manipulation in Turbol Pascal.
DEC-MARLBLRO (aka MARKET) has some excellent routines (for generic
MS-DOS systems, supposedly) in the following files, available via
ANONYMOUS FTP:
TURBO:D_T_MANI.LBR
TURBO:DATETIME.LBR
Source code, of course, in squeezed files within a standard .LBR file.
I'll be sending the requestor some extracts of documentation
separately.
Regards,
David Kirschbaum
Toad Hall
ABN.ISCAMS@USC-ISID.ARPA
------------------------------
Date: 24 Feb 86 12:25 PST
From: Ghenis.pasa@Xerox.COM
Subject: Date and Time from Turbo Pascal
To: info-ibmpc@USC-ISIB.ARPA
To get date and time from Turbo Pascal, use the MSDOS function to
execute the appropriate BDOS call. If you have Turbo 3.0 or later, on
the distribution diskette there is a file called DOSFCALL.DOC which
has the source for precisely this function.
------------------------------
Date: Sun, 23 Feb 86 19:26:56 PST
From: Ya'akov_Miles%UBC.MAILNET@MIT-MULTICS.ARPA
To: info-ibmpc@USC-ISIB.ARPA
Subject: Time of Day Function for Turbo Pascal
Function Secnds:Real;
{
This function returns the seconds past midnight as Real number
Input None
Output Secnds Seconds past midnight as a Real number
Strategy (1) Call DOS to get the time
(2) Convert to floating point seconds past midnight
}
Type
Result=Record
Ax,Bx,Cx,Dx,Bp,Si,Di,Ds,Es,Flags:Integer;
End;
Var
Sys:Result;
Begin
SYS.AX:=$2C00 { AH is get time };
Intr($21,Sys);
If Odd(Sys.Flags) then
Begin
Writeln('Error getting the time');
Halt;
End;
Secnds:=Lo(SYS.DX)/100.+Hi(SYS.DX)+60.*(Lo(SYS.CX)+60.*Hi(SYS.CX));
End;
------------------------------
Date: Wed, 26 Feb 86 09:11 EST
From: MKATZ%UMDA.BITNET@WISCVM.WISC.EDU
Subject: Time and Date from Turbo Pascal
To: BSCHAAR@USC-ISIF.ARPA, INFO-IBMPC@USC-ISIB.ARPA
I saw a message on VMBBOARD@WEIZMANN asking about Time and Date from
Turbo Pascal. I have used Bdos calls from Turbo in CPM86 to get the
date and time. No assembly language is needed. In MS-DOS the
procedure should be similar. Set up the registers like it says in the
Turbo manual (you have to declare a record for it). For date do an
interrupt 21h (there is a Turbo function to do interrupts but I don't
have the manual here so I am not sure what it is called - probably
Intr) with AH (thats the high byte of AX) = 2Ah. For For time AH =
2Ch. Date is returned as CX = year, DH = month, DL - day. Time is
returned as CH = hours, CL = minutes, DH = seconds, DL = 1/100
seconds. This should all work the first time, however I have found
more than a few typos in the Assembly book I am using so I can't
guarantee it.
Manasseh Katz
------------------------------
Date: Thu, 27 Feb 86 00:21:05 -0100
From: gaffney@nta-vax.arpa (Patrick Gaffney CMI)
To: info-ibmpc@usc-isib
Subject: Kermit+Lightning = Rubbish
When I use kermit to download a file to my PC that is running Turbo
Lightning the resultant file contains rubbish. If I remove Lightning
and repeat the process the file is ok. Has anyone else encountered
this effect?
Pat Gaffney
------------------------------
Date: 23 Feb 1986 15:22:56 CST
Subject: Re: Snowy Mode with NANSI.ASM
From: HUNEYCUTT@GUNTER-ADAM.ARPA
I'd suggest an 'extended' mode-set sequence to allow the programmer to
set the NANSI driver for two different kinds of CGA...those that snow
and those that don't.
To avoid snow on some cards (like IBM's), you have to put in some code
to test the retrace status..if the card is retracing (and the signal
therefore blanked), you can update the screen memory. If not, and you
update screen memory anyway, you'll get snow because of conflicting
access to video RAM. Newer designs (such as on the ZDS Z-15x and 2xx
machines) do this checking in the video interrupt handler code or in
the hardware of the card itself. If you check retraces on the newer
style card, you'll unnecessarily slow down screen displays (but be
guaranteed of no snow!).
I realize that adding 'nonstandard' sequences is a nasty thing to do
in a standard environment, but this is one case I feel the user should
be given the option.
Doug
[This is the joy of access to source code. This seems like a perfect case
for a conditional assembly. Any volunteers? -wab]
------------------------------
Date: Tue 25 Feb 86 14:30:35-EST
From: Paul G. Weiss <PGW@XX.LCS.MIT.EDU>
Subject: DOS Console Handling Query
To: info-ibmpc@USC-ISIB.ARPA
I have uploaded NANSI from the program library and it raises some
questions about DOS console buffering that I hope some DOS maven can
answer.
I noticed that when raw mode is turned on there is no processing of
escape sequences or tabs if I used the DOS write function call to
STDOUT. My question is how do device drivers, buffering, int 29h, raw
mode and BIOS teletype interface all work together? In light of this,
what is the difference between using DOS function calls 3f and 40 to
do console I/O and using the console-specific calls.
------------------------------
Date: Tuesday, 25 February 1986 13:26:19 EST
From: Paul.Birkel@k.cs.cmu.edu
To: info-ibmpc@usc-isib.arpa
Subject: Query: Exchanging files with an NBI Machine
Here's an interesting problem. I need to exchange files with an NBI
Word Processing "machine". Don't ask me why anyone would actually buy
one of these beasts instead of a CHEAPER (!) PC-AT or CP/M machine,
but here's the situation.
They have one or two 5 1/4 inch floppies, no hard disk, are probably 8
bit machines, and drive a multiple port letter-quality printer. We've
been told that to connect another brand machine to one of the "extra"
LQP ports will void the warrenty. Heaven forbid!
The better solution would be able to read/write to NBI disks, if
possible. Since there are the appropriate software packages to
transfer between CP/M formats and PC-DOS formats, it would be nice to
do the same with the NBI format. And seemingly reasonable, too.
Although our current machine is a CP/M, we have access to a PC-AT as a
potential intermediary. The question is, how to get from one of them
to the NBI? Assuming that files are ASCII (am I assuming too much?),
and that a standard floppy controller chip is used, this should be
possible.
Unfortunately, NBI has been very unhelpful (as you can gather from the
above comment). I guess they just want to sell more of their machines
rather than to talk with the rest of the world.
Can anyone help me with additional information, technical data, a word
of advice, solace? Also, if you know of any other forums than info-cpm
and info-ibmpc in which such a question could be addressed would you
please direct this message there? My sincere thanks.
paul.birkel@A.CS.CMU.EDU
(412) 268-3074
Carnegie-Mellon University
Dept. of Computer Science
Pittsburgh, PA 15213
------------------------------
Date: Wed, 26 Feb 86 08:09:15 -0500
From: Jeff Edelheit <edelheit@mitre.ARPA>
To: paul.birkel@cmu-cs-k.ARPA
Cc: info-ibmpc@usc-isib.ARPAC, info-cpm@amsaa.ARPA
Subject: Re: Connecting to NBI Machines
Paul - We use a lot of NBIs here. My first comment is that they do not
talk very well to anything! There is a Canadian company (the name
escapes me at the moment) that manufactures a box that hooks-up to
your PC/AT. This box has, if I remember right, one 8" drive & one
5 1/4 drive. You put their conversion floppy into the AT and your
source/destination floppies in and the conversion box attempts to
translate from one wp disk to the other. It will also do a wp to
ascii conversion. The big problem is that this box & software
supposedly costs BIG $$$ ($7k+). For the money, though, it is
supposed to work well. If you want to go that route, get back
to me and I'll try to dig-up some details.
The "cheap" way to go is to connect a pc to the NBI's serial port and
"transmit" or "receive" documents from/to the NBI. We have found
the fastest speed that really works is 4800 bps. Generally, the
screen shows a loss of characters, but the characters really do
show up. If you transfer a document from the NBI, anything that is
underscored gets transferred as just the underscores. (It looks like
NBI handles underscoring by typing the word, backspacing and underlining.)
Our search for a file transfer protocol for the NBI was unsuccessful.
BTW, the VT100 emulator for the NBI doesn't work if you try to use it
going into a UNIX host and want to do vi. NBI's response was
"Yes, we know of that problem; no, we're not going to fix it; and
you should realize that our VT100 emulator doesn't do anything
really sophisticated like true cursor addressing."
One more thing. NBI makes a board for the PC that allows you to do
NBI word processing on an IBM PC. Perhaps that will allow you to
read NBI disks on the PC. Since I don't have one of those boards,
I can't really tell you much. Maybe NBI can (ha!)
Regards,
Jeff Edelheit
(edelheit@mitre)
------------------------------
Date: Sun, 23 Feb 86 12:55:34 PST
From: Ya'akov_Miles%UBC.MAILNET@MIT-MULTICS.ARPA
To: info-ibmpc@USC-ISIB.ARPA
Subject: QUICK-BASIC Comm Files
Excerpts from a Local BBS
From: BILL ANGUS
Date: 23-Feb-1986 11:55:36
I understand from the people at microsoft that the feature which
allows one to open COM1 as if it were a file, will only work if the
com1 port does not receive a ctrl break character from the remote
station which may be communicating via this com1 port. The woman at
Microsoft who explained the problem to me said that DOS interupt 14h
which is used by the basic compiler to facilitate the opening of
communications, does a continuous check for ctrl break. If ctrl break
is encountered, then the program attempts to halt (!) processing. She
also referred me to the book PROGRAMMING THE IBMPC by NORTON (which I
don't have unfortunately). MY QUESTION IS... Does anybody out there
know if the following is the easiest way to prevent <ctrl break> from
getting through and crashing my program? 1) open com1 .... 2) execute
a com off command 3) whenever input output is desired, check for a
character from the remote user at the com port using the inp
function.... 4) if a character is sent and if it is ctrl break, then
disallow it else pass the character along to an input buffer in the
program.....
From: SYSOP
Date: 23-Feb-1986 12:31:03
From the description of the bug by Bill Angus, I would recommend that
you write an Assembler procedure for Quick-Basic which grabs the
contents of INT 14h (ie saves the four bytes at 0:50h and loads its
entry there) and then proceeds to clear the error bits out of the COM1
status at port 3FDh, before passing control onto the BIOS com INT 14h
handler, by PUSHing the four bytes (saved from 0:50h) on the stack,
then IRET.
This will guarantee that the BIOS never sees a communications error!
------------------------------
Date: 23 February 1986, 14:36:02 EST
From: Peter Allsop (Chemical Eng., UofW)
<ALLSOP%WATACS.BITNET@WISCVM.WISC.EDU>
To: info-ibmpc@usc-isib.ARPA
Subject: Experience with QNX Operating System
This is in response to a recent query by Tom Helbekkmo concerning the
QNX operating system.
I have been using QNX on an IBM-PC (576K RAM, 5M Davong, 1 floppy) for
4 or 5 years (I started with a pre-release version), and on a DEC
Rainbow for about 2 years (off and on). The majority of my work
involves real time process control, were speed and efficiency at run
time are more important than ease of software development. I am not a
Unix expert, nor any other kind for that matter, and cannot comment on
how Unix-like QNX is (Quantum claims 4.something compatibility).
Neither do I have any experience with the networked version of QNX,
although I have a few friends who use (and like) it. Weigh my
comments accordingly.
>>> The Operating System:
Basically I am very satisfied with the operating system, now that I
know how to use it. The user is given a great deal of control over
the environment, and the device interface proceedures are very easy to
use (eg: much better than Venix on the Pro-350). A number of useful
(to me) utilities are included, such as:
-Device independant graphics utilities, which allow you to define
your own devices after writing (and compiling) the program.
-User tasks can "adopt" devices, effectively replacing the
device administrator for that device.
-Define your own memory resident shared libraries.
-Intertask signalling and message handling proceedures.
-The basic utilities to allow the user to manage resources independantly
of the OS (semiphores, etc).
-An auto-answer modem control program, so you can sign on from home.
-Drivers for several different hard disks, and a RAM disk utility.
-A windows handling routine, allowing up to 4 windows on the console.
-A full screen editor that makes XEDIT on VM/CMS (KEDIT on IBM-PC)
look sick, both in speed and power.
-A whole bunch of other stuff that I rarely (never) use. These allow
system accounting, debugging, and ??.
The C compiler is very standard, and comes in two flavors: shared
library math (SLM) and inline 8087 math (IM). The SLM uses one of two
memory resident shared libraries (both supplied), one using the 8087
and the other ignoring it. The advantage of this version is that you
can move programs between computers without having to worry about an
8087, but it is *slow*. The IM version generates (you guessed it)
inline 8087 code, and is about 10 fold faster than the shared lib 8087
version. I think that Quantum is going to merge the two compilers,
the user supplying a compiler flag to select SLM or IM.
The code generated by the IM C compiler (the one I use) is very
efficient. I rarely get even a 2 fold speed increase when I re-code
in assembler, and most of my software involves a lots of iteration!
In fact I don't even bother using assembler any more, unless it is a
very heavily used math routine.
There are several other QNX compilers available, including BASIC,
Pascal, and Fortran (I think). Quantum claims that you can mix (link)
program segments coded in different languages together, but I've only
used C. There are also several "extras" available, including a word
processor, a spellin checker, a database manager, and a utility which
allows a DOS program to run under QNX.
QNX does have a few drawbacks. My major complaint is that the manuals
don't have an index!! This isn't a great hassle once you get to know
them, but in the interm ... it's hell! Another annoyance is the size
of the system itself, you only get about 40K of user space out of a
256K machine! Finally, the C compiler (at least) will only allow 64K
of code and 64K of data. This doesn't bother me, since I can always
request a chunk of memory from the OS and manage it myself (utilities
are provided), but if you don't want to ...
>>> The Company (Quantum):
This is were QNX falls down the most. Quantum is a technically
oriented company, and they aren't too swift at marketing. This means
that they tend to be a bit slow on delivery, and don't understand
user's complaints about the manuals (see above). Their technical
support, however, is excellent.
Quantum includes two types of support with every system: a telephone
hotline and an on-line update service. The hotline puts you in touch
with a systems programmer, who has access to a duplicate of your OS.
(Quantum maintains an on- line database which tells them which version
of each module you have). I find these people very helpful, and their
turn around on OS fixes is rarely greater than 24 hr. Even better,
though, is the on-line update system.
The on-line update system allows you to phone Quantum and sign-on to
their database system. This system maintains bug reports, explanatory
notes (eg: recovering erased files), current versions of the OS and
utilities, and a mail system. Using this you can download system
updates directly over the phone, or submit questions/bug reports with
examples. They are even talking about connecting this to DATAPAC
(thus TYMENET, ...). The update service is so good, in fact, that I
can almost forgive them their manual!
Peter Allsop <ALLSOP@WATACS.BITNET>
Dept. of Chemical Engineering
University of Waterloo
(The usual disclamers: I have no connection with Quantum except as a
(usually) satisfied user. The opinions expressed above are those of
the author, and do not (necessarily) reflect the opinion of the
Department, the University, or anyone else with any authority.)
------------------------------
Date: Sat 22 Feb 86 15:56:31-PST
From: Bob Knight <KNIGHT@SRI-NIC.ARPA>
Subject: Thanks to MicroSoft
To: info-ibmpc@USC-ISIB.ARPA
I want to express my thanks to the following people at MicroSoft:
Dan Newell, Cindy K, and Lori Zeebe
Through INFO-IBMPC, Dan knew of my problems with Quick Basic and passed
them to Cindy. Cindy apprised me of the availability of version 1.02 to
registered owners. Lori expedited my receipt of same today. Having
downloaded my application to New Mexico, preliminary results indicate
that 1.02 has fixed our problems.
It is rare that one finds such quick response to a customer problem in
a (relatively) large corporation. I find it gratifying to find same in
Microsoft. I wish them every success in the future.
Bob Knight
------------------------------
From: cramer%kontron.UUCP@BRL.ARPA
Subject: Compiling Really Large Programs With Microsoft C V3.0
Date: Thu, 20-Feb-86 11:25:33 PST
This is a helpful hint to those of you building really big programs
on the IBM using Microsoft C V3.0.
We have a large piece of C that we are developing simultaneously on
a VAX and IBM AT -- roughly 40,000 lines of C, all linked together,
no overlays. Unlike a lot of commercial products, our program has
very large quantities of static data. (Your average spreadsheet has
know problem gobbling up to and beyond 640K, but most of the memory
is allocated -- not static.)
If you don't read the Microsoft C manual in excruciating detail, you
would think that compiling in large model (/AL on the command line)
would be adequate for the largest program that will fit into the
address space. Not so! From section 8.1.1.2 of the Microsoft C
Compiler User's Guide:
All segments with the same group name must fit into a single
physical segment, which is up to 64K bytes long. This allows all
segments in a group to be accessed through the same segment
register. The Microsoft C compiler defines one group named
DGROUP.
The NULL, _DATA, CONST, BSS, c_common, and STACK segments are
grouped together in the data group, called DGROUP. This allows
the compiler to generate code for accessing data in each of these
segments without constantly loading the segment values or using
many segment overrides on instructions. DGROUP is addressed
using the DS or SS segment register. DS and SS always contain
the same value except when the "u" or "w" option of the /A
option is used.
As you can see by table 8.1 that follows in the same manual, even
a large model program will try to put all the global and static
data into one group, and that one group will be entirely in a
64K segment. The symptom is "fixup overflow near <address> in
segment <name> in <file>.OBJ(<file>) offset <offset>" messages
from the linker.
The section quoted above might tempt you to use an option like
/Alfu to allocate different segments for the stack and the
data segments. In fact, this is what I tried first, and for
reasons that are not immediately obvious, our program stopped
dead in its track, looping endlessly.
What does work is to use the options /AL and /Gt. From section
7.12 of the User's Guide:
/Gt [<n>]
By default, the compiler allocates all static and global data
items to the default data segment. The /Gt option causes all
data items greater than <n> bytes to be allocated to a new
data segment.
The effect is to create separate segments AND GROUPS for each
module's static and global data. This doubtless requires more
setting of segment registers -- but I can't see any obvious
slowing of our program after recompiling with the /Gt option.
One other item: a very large program will quickly exceed 128
segments, which is the default number of segments the Microsoft
Linker likes to work with. Use the /SEGMENTS:<nbr> option on the
link to deal with this.
------------------------------
Date: 24 Feb 1986 13:31:48-EST
From: mlsmith@NADC
To: Ghenis.pasa@Xerox.COM, info-IBMPC@USC-ISIB
Subject: Color & Mono Cards in AT
I have had both an IBM Monochrome and Color Graphics Adapter plugged
in for about four months on an AT. I do not use either of the programs
you mentioned. Despite appearances of simultaneous operation, the AT
only talks to one display at a time.I use the monochrome display as a
menu tablet, and then go to the color monitor for my programs. This
leaves the menu up. More elaborate schemes are certainly possible. Two
Adapters of the same type _is_ a problem, but I'm not sure about the
EGA. Does anyone know if you can have two EGA's one in Monochrome mode
and one in Color mode?
------------------------------
To: info-ibmpc@usc-isib.arpa
Subject: FAT City Blues - and how I fixed my hard disk
Date: Tue, 25 Feb 86 12:32:50 -0500
From: Mark Colan <mtc@ATHENA.MIT.EDU>
I sent a report a few weeks ago about having trashed my hard disk
AGAIN, and how I suspected that it was a software problem, not a
hardware problem.
I had been working with a large model Lattice C program, and tried
to use an invalid pointer. Since DOS has no memory protection,
it is possible to write over DOS, and whenever I do this, it always
seems to be the disk driver database I hit. The disk failed badly
after one particular execution of a program with a bad pointer, and
I deduced that I had written over the driver in such a way that
instead of writing a data block into a file, it wrote it in a
random, and particularly wrong, block on the disk.
The symptom was a lot of trashed files, and CHKDSK barfed badly.
Various raw disk manipulation tools hung or refused to run. I ran
the Advanced Diagnostics, Conditional Format, and it started from
track 305, rather than the expected 610. When the diagnostics
completed, it complained that there was less than 10 MB useable
on the hard disk.
The theory was that there was a place on the disk that told the
world, even Adv Diags, about the disk, and that Formatting did not
touch that area. Setup correctly identified the disk as Type 2,
and the interleave was correctly set to 3, yet I had only a 10 MB
disk. I tried to delete and restore the DOS partition, but after
the DOS format, DOS thought it was a 10MB disk. It worked, but
missing half the capacity.
That theory seems to have been proven correct. I was able to restore
my hard disk to relative normalcy by using the "Change Interleave
Factor" function on the "Format Menu" of the hard disk diagnostics.
The interleave factor is normally set to 3; I instructed the program
to "change" it to 3. My guess was that it might, as a side effect,
reinitialize other disk characteristics in the correct way.
It worked! The Advanced Diagnostics Conditional Format now counts
down from track 610, which means I again have a 20 Mb disk.
Interesting that at least some of the problems I formerly attributed
to bad hard disks on the AT were in fact software problems that
resulted of the missing memory protection in DOS.
Mark Colan
MIT Project Athena
------------------------------
Date: Tue, 25 Feb 86 08:44:44 CST
From: C346595%UMCVMB.BITNET@WISCVM.WISC.EDU (Bruce Barkelew)
To: info-ibmpc@usc-isib.arpa
Subject: ProComm
PIL Software Systems
PO Box 1471
Columbia, MO 65201
(314) 449-9401
I am the co-author of the communications program ProComm. I noticed
our program mentioned here, so I thought I would let you know some
more information. ProComm is a user supported product. We have just
released version 2.2 (02/21/86). Version 2.2 has many improvements
and additions. We now emulate 10 popular async terminals. The VT-100
emulation has been greatly improved. We support XMODEM, YMODEM, TELINK,
MODEM7 and KERMIT file transfer protocols. Our KERMIT implementation
has been completely re-coded from the ground up, and now supports all
the latest features such as data compression, file attributes, and the
new Sliding Window (full duplex) extension. Our script command language
has been expanded also. ProComm runs under MS-DOS 2.0 or greater, and
requires 128k of RAM. We a 24 hour support BBS running at (314) 449-
9401. The latest version is always available there.
I don't mean this to sound like a commercial, but I saw messages here
inquiring about us, so I thought I would supply the information. I can
be reached at the above address or at C346595 at UMCVMB.
-Bruce Barkelew
------------------------------
Date: 26 Feb 1986 13:18:30 EST
Subject: Re: Lotus printer problem
From: ABN.20E-27@USC-ISID.ARPA
To: INFO-IBMPC@USC-ISIB.ARPA
In regards to GARY SWALLOW's response to the problem of LOTUS and the
inherent ability to talk to the WANG PM012 DIABLO type impact printer,
I thank you! I did finaly get ahold of the LOTUS Tech rep and they
were not the most reassuring of supporters. The end result of that
phone call was that LOTUS prefers to talk at 300 baud not 1200, it
needs 8 bits set on, no parity with one stop bit. This done they
still didn't seem real positive of the results as the informed me that
if that didn't work to delete the serial driver. All said and done it
didn't have any new results in any form! BLEAH-
My next idea is to think about changing the config.sys (shell=) to
better talk to the system with LOTUS. I really would be greatful for
further help on both getting the printer to work with LOTUS through
switch changes and/or optimizing the config.sys file.
THIS LOTUS vs PM012 (DIABLO) IS BEATING ME SEVERELY AROUND THE HEAD
AND SHOULDERS.
Reply:
KURT A. NEUMAIER
ABN.20E-27
FT BRAGG, NC
------------------------------
Date: Wed, 26 Feb 1986 23:51 MST
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
To: INFO-CPM@AMSAA.ARPA, INFO-MICRO@BRL.ARPA
Cc: INFO-IBMPC@USC-ISIB.ARPA, INFO-HZ100@RADC-TOPS20.ARPA
Subject: More SIG/M and PC/BLUE volumes available
SIG/M volumes 210 to 251 are now available in PD:<SIGM.VOLnnn>.
PD:<SIGM.VOL000> and PD:<SIGM>SIGM.CRCLST have also been updated.
PC/BLUE volumes 125 to 175 are now available in PD:<PC-BLUE.VOLnnn>.
PD:<PC-BLUE.VOL000> and PD:<PC-BLUE>PC-BLUE.CRCLST have also been
updated.
All files were uploaded using MEX for the SIG/M disks and MEX-PC for
the PC/BLUE disks. Check your CRC values against our list in the
*.CRCLST files. For the PC/BLUE files, use CRCK4.COM. The CRCs of
the files in the PC-BLUE directories should match our values
regardless of whether you use MODEM or KERMIT protocols to download
the files. The CRCs of the ASCII files may not necessarily match, but
should be correct copies nonetheless.
If any files appear trashed, be sure to check the file type in the
CRCLST file to make sure you are not trying to display a binary file
as if it were ASCII, especially on other TOPS-20, TENEX, or ITS
mainframes. If the file is truly trashed, please let me know and I
will get correct copies re-uploaded.
--Frank
------------------------------
Date: 24 Feb 1986 15:49:11 PST
Subject: QuicKey.asm
From: Billy <BRACKENRIDGE@USC-ISIB.ARPA>
To: info-ibmpc@USC-ISIB.ARPA
The March 11 PC Magazine has published a program called program called
quickey.asm this speeds up the typomatic on the PC keyboard. If anyone
has downloaded the .ASM source files, would you please send it to us.
I'd like it for the library.
------------------------------
Date: Mon, 24 Feb 86 10:41:38 PST
From: Ya'akov_Miles%UBC.MAILNET@MIT-MULTICS.ARPA
To: info-ibmpc@USC-ISIB.ARPA
Subject: Microsoft MASM Assembler Wish List
Wish List for Microsoft MASM Assembler
______________________________________
(1) Provide an option to allow for "worst-case" resolution of undefined
forward references in pass 1, dealing with them the same way in pass 2.
Although specifying this option would generate bigger code, it sure
would speed programming, and avoid those annoying "PHASE ERRORS" in
pass 2 (see page 95 of MASM 4.0 reference manual)
(2) Provide an option which DISABLES STRONG TYPING for MEMORY OPERANDS.
It seems that 30% of my code contains the PTR override operator.
(see page 83 of MASM 4.0 reference manual)
(3) Provide an option to shell CREF.EXE from MASM automatically.
(see page 31 in MASM 4.0 user`s guide)
(4) Allow KEYWORDS in MACRO calls, for example
GET_TIME MACRO HOURS=A,MINUTES=B,SECONDS=C,HUNDREDTHS=D
MOV AH,2Ch
INT 21h
.IFNB <A>
MOV BYTE PTR A,CH
.ENDC
.IFNB <B>
MOV BYTE PTR B,CL
.ENDC
.IFNB <C>
MOV BYTE PTR C,DH
.ENDC
.IFNB <D>
MOV BYTE PTR D,DL
.ENDC
GET_TIME ENDM
(see page 121 and 108 in MASM 4.0 reference manual)
(5) Allow definition of LOCAL symbols outside of MACROS. Ideally these local
symbols would be "remembered" only within a given procedure. For example
FOO PROC NEAR
10$: JCXZ 20$
LOOP 10$
20$:
FOO ENDP
BAR PROC NEAR
10$: LOOP 10$
BAR ENDP
would be legal, and not result in "Redefinition of Symbol" errors.
------------------------------
Date: Sun, 23 Feb 86 09:09:40 PST
From: Lawrence_Anthony_Smith%UBC.MAILNET@MIT-MULTICS.ARPA
Subject: Problem with 27 Lines on the EGA
I am having difficulty in displaying 27 lines of character data
instead of the normal 25 lines. I am using a PC/AT with the Enhanced
Graphics Adaptor (EGA). I'm writing the program in Microsoft
Assembler V3.0.
Does anyone have any useful ideas about how to go about this task?
Lawrence Anthony Smith%UBC.MAILNET@MIT-MULTICS.ARPA
TRIUMF, U.B.C
------------------------------
Date: Sun 23 Feb 86 22:27-EST
From: Ed Barton <EB%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU>
Subject: Cluster Size Query
To: Info-IBMPC@USC-ISIB.ARPA
I have a poorly documented generic PC-compatible with a 20meg
hard disk. Unfortunately, disk space is allocated in 8K blocks
leading to a great deal of wasted space. I would appreciate
hearing from anyone who can explain what I can do to reduce
the allocation size (and who doesn't mind explaining it).
Please reply to EB%MIT-OZ@MIT-MC; thanks.
------------------------------
Date: 24 Feb 1986 04:57-PST
Subject: Prolog Query
From: BSCHAAR@USC-ISIF.ARPA
To: info-ibmpc@USC-ISIB.ARPA
A friend of mine needs a pointer to the developer's name,
address, and phone number of Prolog. Also, any pointers to
available sources for Prolog on the IBM PC/XT.
Thanks.
Brian Schaar
------------------------------
Date: Mon 24 Feb 86 11:50:06-EST
From: Thomas.Finholt@C.CS.CMU.EDU
Subject: TRS Model 100 to IBM XT Connection Wanted
To: info-ibmpc@USC-ISIB.ARPA
I am interested in software that allows me to use the XT hard disk
as a remote disk for a TRS Model 100 portable computer.
Thanks!
------------------------------
Date: Mon, 24 Feb 86 16:10:32 pst
From: Ivan Reid <ivan%dac.triumf.cdn%ubc.csnet@CSNET-RELAY.ARPA>
To: info-ibmpc@usc-isib.ARPA
Subject: XT-clone motherboard query
A friend recently acquired a Megaboard-type motherboard for an XT
clone. The board is silk-screened with IC identification, but came
without a circuit diagram. The only identification is 'MBE-XT'. Any
help in tracking down the manufacturer or a circuit diagram would be
greatly appreciated.
Ivan Reid, TRIUMF, Vancouver, BC.
------------------------------
Date: Tue, 25 Feb 86 10:56:54 est
From: John Pezaris <pz@mit-vax>
To: info-ibmpc@usc-isib
Subject: Color Attribute Query
The recent discussions on setting colors have brought back an old query
I was never able to resolve: is there any way to *read* (not write) the
current attribute that dos will use in writing to the screen?
Clearly, this information must be kept within dos, and is accessible
through some venues, for ansi.sys and various other packages are able
to modify it. However, I have not seen any hooks for retrieving the
information.
- John Pezaris (pz@mit-vax)
------------------------------
Date: Tue, 25 Feb 86 16:08:34 EST
From: Andy Adler <andya@bbnccp.ARPA>
Subject: Problem with MS-DOS command line length
To: Info-IBMPC@usc-isib.arpa
I am having problems with the MS-DOS limitation on command line
length.
The version of the MS C compiler that comes in the Windows Toolkit
combines p0.exe and p1.exe into one new p1.exe. Thus the command line
for the new p1.exe gets long since it receives switches for "two
programs". If I want to keep my include files in more than one
directory the multiple -I switches will overflow the command line. I
can work around the problem by keeping all my includes in one
directory with a relatively short path. However, this is not the REAL
solution.
Is there any way to lengthen the command line length limit? Has
anyone come up with a better work around for this problem?
Thanks,
Andy Adler
BBN Communcations.
------------------------------
Date: 25 Feb 86 11:27:56 PST (Tuesday)
Subject: Intel 80186 Assembler Query
From: Kadifa.osbunorth@Xerox.COM
To: INFO-IBMPC@USC-ISIB.Arpa
I need some pointers for an Intel 80186 compatible assembler, linker,
locater written in C. This needs to understand Intel Macros and other
assembly operations, and I am not looking for a Microsoft assembler.
Abdo Kadifa
Xerox
US Mail: 2400 Geng Rd
Palo Alto, CA 94303
------------------------------
Date: Wed, 26 Feb 86 02:14:02 est
From: tom allebrandi <edison!ta2%virginia.csnet@CSNET-RELAY.ARPA>
To: info-ibmpc@usc-isib.ARPA
Subject: Query: PCnet <--> 3Com Ethershare "Gateway"
We are currently installing a 3Com EtherShare network between our AT's
and our VAXCluster. We are also looking at a printer that only hangs
off of PCnet (the new IBM pageprinter). Does anyone know if there is
a good way to nail PCnet and EtherShare together? Current plan is
that the VAX is our 3Com server - we won't have a PC based server in
the EtherShare net. If we have to - we will put in a PC based 3Com
server and run the pageprinter off of it.
Tom #-}
ta2@edison.uucp
edison!ta2%virginia@csnet-relay.arpa
(804) 978-5566
------------------------------
Date: Wed, 26 Feb 86 10:52:41 est
From: mjgold@mitre-bedford.ARPA
To: INFO-IBMPC@USC-ISIB.ARPA
Subject: Window Package for Xenix Wanted
Does anybody out there possess any knowledge about a window package
that will run on the IBM PC/AT under the XENIX operating system. I am
aware of the packages that will run under DOS such as Microsoft's
WINDOWS but I am unaware of any software windows packages for UNIX on
the AT.
Any Help would be greatly appreciated.
------------------------------
Date: Wed, 26 Feb 86 16:31 CST
From: "Mark L. Ahlstrom" <Ahlstrom@HI-MULTICS.ARPA>
Subject: dBASE File Format Query
To: info-ibmpc@USC-ISIB.ARPA
Can anyone point me to a reference that clearly describes the internal
file formats used for dBASE II and dBASE III "dbf" files. I am
interested in being able to have a program that writes files that can
be read as dBASE database files.
Thanks, Mark
------------------------------
End of Info-IBMPC Digest
************************
-------