hicks@WALKER-EMH.ARPA (Gregory Hicks COMFLEACTS) (02/15/88)
Info-IBMPC Digest Mon, 15 Feb 88 Volume 7 : Issue 14
This Week's Editor: Gregory Hicks -- Chinhae Korea <hicks@walker-emh.arpa>
Today's Topics:
Bitnet Server OVERLOADED
Caution for those considering MSC 5.0 (2 msgs)
HPGL to PostScript filter
DSZ0208.ARC now available from SIMTEL20
File I/O and Slow Windows
Floppy/Hard drive configuration for XT
VT-100 Emulation
MindReader v1.03 artificial intelligence text editor
MSC 5.0 Bugs, Microsoft ``support''
New Assembler from SLR Systems
Text to Postscript converter
QVT - a VT220 Emulator available from SIMTEL20
Random Number Generator (2 msgs)
Turbo TSR Request
Turbo C vs Quick C
WXTERM (Windowed Xmodem Terminal) Source Code Needed (2 msgs)
Today's Queries:
Aligned Memory Allocation With MSC 5.0
Upgrading PS/2 to 640K
FORTH Compiler
Hard Disks on the IBM PS/2
NROFF-like DOS formatter
Windows for C
Info-IBMPC Lending Library is available from:
Bitnet via server at CCUC; and from SIMTEL20.ARPA (see file
PD1:<msdos>files.idx for listing of source files)
SIMTEL20.ARPA can now be accessed access from BITNET is via
LISTSERV@RPICICGE.BITNET using LISTSERV Commands
INFO-IBMPC BBS Phone Numbers: (213) 827-2635 and (213) 827-2515
----------------------------------------------------------------------
Date: Friday, 12 February 1988 19:52-MST
From: "John S. Fisher" <FISHER@CICGE.RPI.EDU>
Subject: Bitnet server overloaded
As many of you on the Bitnet-side of this list realize there have been
some difficulties getting files from the Bitnet file server at RPICICGE.
Three independent but simultaneous events seem to have caused serious
network congestion through the main cooridor of Bitnet. The particular
events are not important except for the fact the RPICICGE server was one
source for the over-run of network data.
Since I cannot allow my server to be an unfair burden to the network I
have placed it into restricted service: File requests were limited to one
per day, and directory listings were usually disabled. Februrary has just
not been a good month.
Some analysis of the types of requests flowing into the server indicated
that most of the load was coming from people requesting directory listings
at regular intervals (probably just to see what was new). I cannot really
blame people for their actions, the server gave them no good alternative.
At any rate, in an attempt to keep the server within acceptable traffic
loads, I have made a couple of changes to how it operates:
1.) The /PDDIR command is be reworked. If just a directory name is
specified (as in /PDDIR PD:<CPM>) the server will return a list of the
subdirectory names. Formally, it returned a complete listing of all files
available from the server.
2.) If /PDDIR is used with more than just a directory name specified, it
expects a new parameter, a number following the name pattern. The number
specifies a limit on age for entries to be listed. If the number is
omitted, the default is 30 meaning list no file older than 30 days. For
example, /PDDIR PD:<CPM.*>*.* 14 would search for any files in the CPM
directory that have been add/updated in the last two weeks (but see #3,
next).
3.) If /PDDIR is used with an asterisk appearing in the subdirectory name
(as in /PDDIR PD:<CPM.*>*.* and /PDDIR PD:<CPM.SYS*TL>*.*) then the search
is unconditionally cut-off after 21 entries are found. That means that
/PDDIR PD:<CPM.SYSUTL>*.* 99999 would list all entries in the SYSUTL
subdirectory, but /PDDIR PD:<CPM.SYS*TL>*.* 9999 would list only the first
21 entries.
4.) Both /PDGET and /PDDIR keep track of the number of requests and the
number of bytes the command generates. (Formally, only the /PDGET command
keep counters, and the counters were for number of files.) Requests are
denied with the counters reach 5 requests or 100,000 bytes, which ever
comes first, in one day. (However, the first file requested during any
day may exceed 100,000 bytes.) Counters are also kept by network node to
prevent people from defeating the command limits by "cycling-through"
userids.
5.) The server keeps a local cache of recently requested files. In many
cases a file at Simtel20 would be updated, but the server on Bitnet would
still have a cached copy of the old version. The server now tries to
compare date-of-last-change to determine if the cached copy is the most
current. Obsolete copies are discarded and the newest version fetched in
its place.
To make matters worse, complete testing of these changes has been
frustrated by some local problems that have prevented reliable access to
the Internet. The server is presently sitting with a two-day backlog of
requests. But, be that as it may, most of the changes are long overdue.
The limit parameters in place are best-guesses by me and are subject to
change.
Regards,
JSFisher, maintainer of many (too many) things.
------------------------------
Date: 4 Feb 88 23:10:15 GMT
From: Mark Chance <mc35+@andrew.cmu.EDU>
Subject: Caution for those considering MSC 5.0
In recompiling my application under 5.0 I discovered an annoying feature
which effectively prevents me from using 5.0. My application is pretty
large and I need a lot of stack space. I am using the large model and by
adding the -Gt option to force data items to their own segment things are
pretty cool. Now along comes 5.0 and I specify 20000 bytes stack space,
the linker says 'Error: stack+data>64K'. I say how can that be? Well the
punch line is that 5.0 puts strings in the CONST space which is in the
stack segment !!! :-(. So cluttering up my precious stack space is 40K
worth of strings that used to be distributed among the various FAR-DATA
segments. I intend to complain to Microsoft about this since I have not
found any compiler switches to avoid this. Any other ideas?
Mark Chance Information Technology Center
mc35+@andrew.cmu.edu Carnegie-Mellon Univ.
------------------------------
Date: Wed, 1988 Feb 10 13:54 EST
From: Bob Babcock <PEPRBV%CFAAMP.BITNET@husc6.harvard.EDU>
Subject: Caution for those considering MSC 5.0
mc35+@andrew.cmu.edu (Mark Chance) writes:
>Well the punch line is that [MSC] 5.0 puts strings in the
>CONST space which is in the stack segment ....
>that used to be distributed
>among the various FAR-DATA segments.
I ran into just the opposite problem. Having just purchased Turbo-C
1.5 and MSC 5.0 as possible replacements for Computer Innovations C86,
I found that some global variables which were in DGROUP under Turbo-C were
put into another segment by MSC. This caused my assembly language
subroutines to quickly go south. I would have expected the linker to
warn me that something was wrong, but it didn't. Anyway, my question
is: can I force MSC 5.0 to put all global variables into DGROUP when
using the large model? The manual seems to indicate that only initialized
global data will go here, but isn't all global data implicitly
initialized to zero if not otherwise specified?
------------------------------
Date: Sat, 13 Feb 88 14:29:47 PST
From: dukelow@cod.nosc.mil (Robert A. Dukelow)
Subject: HPGL to PostScript filter
> Date: Thu, 28 Jan 88 17:53:04 EST
> From: Jon Radel <6033138%PUCC.BITNET@CUNYVM.CUNY.EDU>
> Subject: Query on HPGL to Postscript
>
> I've heard rumors of a HPGL to Postscript translator, but have been unable
> to find any hard facts. Has anyone heard of such for PC or mini?
>
> --Jon Radel
There has been some discussion of this in comp.lang.postscript. Following
is a message I just posted there a few days ago. Didn't think to cross
post it here:
Several months ago I requested information on filters to convert HPGL plot
files to PostScript. I got a number of responses which I greatly
appreciate. A few were dead ends but the following proved useful to me.
The first that I tried was 'glops' from Dave Feldman
(david@dsl.cis.upenn.edu.arpa). I had to do some modification to get it to
work on my plot files (primarily to get it to ignore HPGL commands that
were not implemented and to be more forgiving of extra semicolons and
white space that some plot packages put into the HPGL file). If you want
something that you can port to any machine that has a C compiler and are
willing to hack a little then this is probably a reasonable alternative. I
was able to get it running on both a VAX under BSD 4.3 UNIX and Apollo
Domain without too much hassle. There are a few things that don't come
out quit right for me though and I don't have enough time to play with it.
I got my copy of glops around November 2, 1987 and haven't checked to see
if Dave has an improved version by now.
The second program I tried (although I have to admit that I have used it
less than glops) was 'hpgl2ps' for which the sources were posted to the
net (in comp.sources.misc) on December 20, 1987. This came from Don
McCormick at Applied Physics in Australia. This is again in C and I had
only a little trouble getting it running on my Apollo. It works quite well
for HPGL files where everything (including text) is made directly from
vectors - but I did have some problems with scaling when text is involved.
I have not tried to resolve any of the problems. This, again, could be a
good starting point if you want source and are willing to hack a little.
Don't know if it is still being worked on by Don.
The alternative which has turned out best for me is a commercial program
called PSPlot from:
Legend Communications, Inc.
54 Rosedale Ave.
Brampton, Ontario, Canada
(416)450-1010
PSPlot cost about $150 (US) and (as far as I know) is available only for
IBM-PC compatibles. I really haven't had it very long but it ran all of my
test cases with no problems. The HP-GL conversion is really just one
option of a program designed to edit PostScript files and communicate with
the printer in various ways. I can't really comment on all of the other
features since I have really only been interested in the conversion part.
The nice thing about this package is that it provides lots of options for
scaling and rotating the plot and you can easily translate pen colors into
various combinations of gray scale, line style (combinations of dotted and
dashed lines), and/or line width. I can't claim that I have exhastively
tested the program - but it works flawlessly with all the HP-GL output I
had available to test it on. If you can easily work in the PC environment
then you might want to give this a try. If you don't have a PC it might be
worth checking with them to see if they can support any other
environments.
Bob Dukelow
dukelow@nosc.mil
------------------------------
Date: Fri, 12 Feb 1988 23:19 MST
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: DSZ0208.ARC now available from SIMTEL20
The latest version of Chuck Forsberg's popular DSZ x/y/zmodem protocol
(shareware) program is now available from via standard anonymous FTP
SIMTEL20.
Filename Type Bytes CRC
Directory PD1:<MSDOS.MODEM>
DSZ0208.ARC.1 BINARY 60812 EAABH
This version offers improvements in the area of dealing with congestion on
packetized networks.
If you are a registered user of ZCOMM you can use your ZCOMM serial number
with the PUTSNP program to serialize DSZ.
--Keith
------------------------------
Date: 10 Feb 88 13:58:32 GMT
From: Ken Konecki <kk@richp1.uucp>
Subject: File I/O and Slow Windows
VC008329%NDSUVM1.BITNET@cunyvm.cuny.EDU (MITCHELL L GRAVES) writes:
>
> I have been using Turbo C for anly a few months now and I'm having a couple
>of problems with a program I'm writing.
>
...After using fgets() there is a printf:
> printf("Password is: |%s|",&password);
>
>This is what it looks like when I print password:
>
>Password is: |ORANGE
>|
The reason is fgets(buf,n,stream) keeps the newline character if it reads
one. You can remove it easily by adding this line:
fgets(buf,n,stream); /* your specific fgets goes here */
buf[strlen(buf)-1] = '\0'; /* ZAP that newline */
>
>Problem Two:
>
>I am drawing windows on the screen when prompting for passwords & things
>of that nature. I can watch the window being drawn (Very Sloooww!). I heard
>there is a way to write the screen to a buffer (or something like that) and
>later call it up so I don't have to watch the window being slowly drawn each
>time. Can anyone help me out?
(Under the assumption you're using and IBM PC or AT and you're using text
mode to do your painting.) I've never done this in Turbo C, but used to do
it in Turbo PASCAL all the time.
To write the screen the screen to a buffer just copy the screen memory to
your buffer and to put it back, just reverse the process. Monochrome
screen memory begins at 0xB000:0x0000 (segment:offset) and color memory
begins at 0xB800:0x0000 (segment:offset). All you have to do is set a
pointer to the beginning of the right kind of memory (you can find out if
you have a color or monochrome from a BIOS call, but I don't know which
offhand) and do a memcpy(buf,screen,4000) to save the entire screen and
memcpy(screen,buf,4000) to restore it. If you need more help, just send
me e-mail (address is ihnp4!richp1!kk).
Ken Konecki @ ihnp4!richp1!kk
"A squeegee by any other name wouldn't sound as funny"
------------------------------
Date: Fri, 12 Feb 88 12:13:17 EST
From: Shuo Huang <hs@eevlsi.ee.columbia.edu>
Subject: Floppy/Hard drive configuration for XT
In Info-IBMPC Digest V7 #8, article from WASHBURN @ Walker-EMH.arpa
> .. is looking for the following configuration with XT clone:
> Drive A 1.2 Meg Floppy
> Drive B 360K Floppy
> Drive C 30 Meg hard disk drive RRL w/ST-238
> Opt Drive D 30 Meg Hard disk drive RRL w/ST-238 same controller
> Drive E 720K 3 1/2 " floppy
> Questions 1. Has anybody done something like this or similiar?
> 2. Which Floppy controller is best for the above config?
> 3. How can you configure a Taiwan Floppy controller card
> to be drives E and F instead of A and B.
One of my friend bought an AST personal computer(AT). His floppy/hard
disk drive controler can handle 3 floppy drives and 2 hard disks. One of
the 3 floppys must be 3-1/2" 720K. I am not sure if the 3 floppys have to
be named A, B, and C? However I don't know if your XT can have that kind
of controler.
/hs
hs%eevlsi.ee@cu20b.columbia.edu
------------------------------
Date: Sat, 13 Feb 88 12:19:58 EST
From: Ruth_Barnard@um.cc.umich.edu
Subject: VT-100 Emulation
Could you pass along to the person who wants VT-100 emulation program,
ProComm has it (I assume it is "full"). -r
------------------------------
Date: Fri, 12 Feb 1988 23:41 MST
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: MindReader v1.03 artificial intelligence text editor
Now available via standard anonymous FTP from SIMTEL20...
Filename Type Bytes CRC
Directory PD1:<MSDOS.EDITOR>
MIND103.ARC.1 BINARY 174898 CBB9H
MindReader is a powerful shareware text editor from Brown Bag Software
that uses Artificial Intelligence to suggest completion of words and/or
phrases, making typing easier and faster. It is designed for the business
professional (non-typist). It allows an unskilled typist to complete a
document in a fraction of the keystrokes normally required with a
conventional word processor, checking spelling "on-the-fly" before words
are actually even completed. The more you use MindReader, the smarter it
gets. It also contains a pop-up Calendar, "Rolodex" and Diary. It is
especially suitable for the physically handicapped.
--Keith
------------------------------
Date: 4 Feb 88 15:20:00 GMT
From: mcdonald@uxe.cso.uiuc.EDU
Subject: MSC 5.0 Bugs, Microsoft ``support''
I ordered my Microsoft C 4.00 to 5.00 upgrade in middle December. It still
hasn't come. Our purchasing agent called them and they said that it wasn't
shipping due to bugs. They hoped to have some sort of product out soon
(read: some bugs fixed).
Remember that their Fortran 4.00 was so buggy that they shipped free fixed
versions (4.01) .Maybe they'll do this for C. In any event, at least
around here they are charging only $45 for the 4.00->5.? upgrade.
Doug McDonald
University of Illinois.
------------------------------
Date: Thu 11 Feb 1988 15:02:28 EDT
From: <SAGE@LL.ARPA>
Subject: New Assembler from SLR Systems
I would like to make the PC-DOS/MS-DOS communities aware of a new
assembler from SLR Systems in Butler, Pennsylvania. Although I follow to
some degree developments in the 16-bit world, my own personal activity is
in the 8-bit world, where I write extensively in assembly language.
In the CP/M world the SLR assembly language tools are well known for
both their quality and their speed. The speed difference is the most
spectacular feature. The first time I used SLRMAC to assemble a ZCPR
file, the assembly ended virtually simultaneously with the appearance of
the signon message after the assembler loaded. I was sure then that I was
dealing with another cheap assembler and would find a zero-length output
file. To my surprise, the output file was there and ran perfectly. Since
then I have just gotten used to the fact that Steve Russell can make his
tools run at speeds others cannot even approach. And he does this while
offering better convenience features in the programs as well.
After this experience with SLR's products in the 8-bit domain, I was
excited to hear that Steve was working on 16-bit versions of the tools.
The first, an assembler called OPTASM, is now available.
It takes a somewhat different approach from the CP/M products, which
were unusual in doing their work with only one pass through the source
file rather than the usual two. In fact OPTASM does the opposite. In
order to optimize the more complex 16-bit object code, it makes a variable
number of passes through the code so that it can, among other things, (1)
resolve forward references without generating phase errors or resorting to
insertion of NOP instructions and (2) optimize short and near jumps. The
output code from OPTASM ranges from slightly shorter to dramatically
shorter than the output from MASM.
Despite making multiple passes (apparently up to 8!), efficient coding,
I/O, and memory management by OPTASM allow it to run THREE TO FOUR TIMES
FASTER than MASM.
For test purposes I tried assembling two pieces of source code:
MXTID.ASM from Ron Fowler's MEX-Plus telecommunications program and
GR.ASM, some Lincoln-written assembly-code subroutines for efficient
graphics output from a C program. Here are the results I obtained on my
Compaq Deskpro 386. Times on a standard AT would, presumably, be twice as
long for both assemblers.
MASM OPTASM
---- ------
MXTID.ASM size 46,208 46,208
Assembly time with listing
and crossreference output 14 s 3 s
MXTID.OBJ size 5,969 3,981
GR.ASM size 69,283 69,283
Assembly time with listing
and crossreference output 17 s 4 s
GR.OBJ size 5,488 4,056
I will have to admit that I had a lingering doubt about these results
(how could the code get that much shorter?), so I took the GR.OBJ module
back to the author of the plotting program and had him link it into the C
program. Worked perfectly!
From glancing at the user manual, it appears that OPTASM offers the
same kind of extremely useful convenience features that Steve put into the
8-bit tools. Here are just a few examples:
1. Symbols can be defined from the command line, as in
OPTASM /Dtest=true MYPROG;
This makes it easy to try different options without having to edit the
source file each time.
2. OPTASM allows a large number of configuration options. The CONFIG
utility makes it easy for the user to customize OPTASM to his own needs
and tastes.
3. Options can be controlled (overriding the configured options) by
directives in the source, from the command line, or from an environment
variable OPTASM. Thus it is easy to make temporary changes to the default
options.
4. The search path for INCLUDE files in the source can be specified from
the command line. Many directories can be included in that path, limited
only by the length of the command line.
5. OPTASM includes a built-in MAKE facility. This can be used for
complete management of module dependencies or simply to perform assemblies
of many files with a single loading of OPTASM. OPTASM even allocates
buffers to keep source resident in memory to the maximum extent possible
(for example, so that common include files or macro libraries do not have
to be read in again from disk). I created a MAKE file to assemble the
GR.ASM file above five times without listing or crossrefernce files.
Total assembly time (all 5 assemblies) was only 5 seconds!!! With listing
output the time was 15 seconds; the time was dominated by output to disk
of the listing file.
The cost of OPTASM is $195. For more information or to order a copy,
call SLR Systems at 412-282-0864 or 800-833-3061 or write to them at SLR
Systems 1622 N. Main Street Butler, PA 16001
DISCLAIMER: I do not have any financial stake in SLR Systems. My wife's
company, Sage Microsystems East, has been selling their 8-bit products and
may now add the 16-bit ones, too. My comments above are motivated only by
a desire to see excellence rewarded (so that it may continue).
------------------------------
Date: Tue, 9 Feb 88 16:24:59 PST
From: forags@violet.Berkeley.EDU
Subject: Text to Postscript converter
Following is a Turbo-Pascal program which was posted to another newsgroup
several months ago. It translates text files to Postscript. It's not
perfect, but several of our users have found it quite useful.
Al Stangenberger Dept. of Forestry & Resource Mgt.
forags@violet.berkeley.edu 145 Mulford Hall
uucp: ucbvax!ucbviolet!forags Univ. of California
(415) 642-4424 Berkeley, CA 94720
[This program is available from SIMTEL20.arpa as follows:
Filename Type Bytes CRC
Directory PD1:<MSDOS.TURBOPAS>
POSTSCRIPT.CVT.1 ASCII 25798 3857H
--Keith]
------------------------------
Date: Sat, 13 Feb 1988 15:18 MST
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: QVT - a VT220 Emulator w/Kermit & XMODEM available from SIMTEL20
Now available standard via anonymous FTP from SIMTEL20...
Filename Type Bytes CRC
Directory PD1:<MSDOS.MODEM>
QVT23.ARC.1 BINARY 72676 5A41H
QVT is a VT220 emulator for MSDOS with Kermit & XMODEM file transfer
protocols.
--Keith
------------------------------
Date: 7 Feb 88 17:03:38 GMT
From: wacey@cars.rutgers.EDU
Subject: random number generator
I need a random number generator with a Gaussian distribution. It
should have a settable standard deviation. I would prefer it
written in C but any language would be appreciated. Thanks
iain wacey
------------------------------
Date: 11 Feb 88 01:16:45 GMT
From: Doug Gwyn <gwyn@brl-smoke.arpa>
Subject: Random Numbers
becmug@ernie.Berkeley.EDU (BECMUG Guests) writes:
> I've just learned C, and am thinking of good ways to generate random
>numbers. Does anyone have any suggestions?
Start by reading Donald Knuth's "The Art of Computer Programming, Vol. 2:
Seminumerical Algorithms", Chapter 3 (Random Numbers).
Until you basically understand this material, you're probably best off by
simply using the pseudo-random number generator in your C library (usually
called rand(), sometimes random(); on System V drand48() is pretty good).
There are a few good algorithms in the professional literature and a bunch
of not-so-good ones.
The main moral to be drawn from Knuth is: if you really need good
randomness properties, you had better thoroughly test whatever generator
you're considering.
All that said, here's a typical (portable) linear-congruential
pseudo-random number generator, taken from the draft ANSI C standard;
rand() returns an integer uniformly distributed from 0 through 32767
(inclusive), and srand() is used to initialize a sequence to a particular
seed, or to avoid getting a predictable sequence (by setting a seed based
on some system variable such as process ID or time-of-day).
static unsigned long int next = 1;
int rand(void)
{
next = next * 1103515245 + 12345;
return (unsigned int)(next/65536) % 32768;
}
void srand(unsigned int seed)
{
next = seed;
}
------------------------------
Date: Thu, 11 Feb 88 14:48:24 EST
From: David Kirschbaum <kirsch@braggvax.arpa>
Subject: Turbo TSR Request
Paul Nolan asked about tips on how to do Terminate-and-Stay-Resident in
Turbo Pascal.
Assuming he's talking v3.0 (I can't say if the referenced code works with
v4.0 or not), I'd strongly suggest the package STAY42.ARC in SIMTEL20's
PD1:<MSDOS.TURBOPAS> archives.
Fully documented code (plus functioning example) for TSR'ing in Turbo.
Use it all the time.
Regards,
David Kirschbaum
Toad Hall
kirsch@braggvax.ARPA
------------------------------
Date: 10 Feb 88 16:59:11 GMT
From: Bill Wilson <wew@naucse.uucp>
Subject: Turbo C vs Quick C
Educators can pick up Turbo C for $39.95 directly from Borland. Most of
the articles I have read indicate that Turbo C is superior to Quick C. On
our campus here we have also had Quick C blow away hard drives, so be
careful.
Bill Wilson
------------------------------
Date: Sat, 13 Feb 1988 14:52 MST
From: Keith Petersen <W8SDZ@SIMTEL20.ARPA>
Subject: WXTERM (Windowed Xmodem Terminal) source code needed
WXTERM is a terminal/file transfer program for MSDOS that does Windowed
Xmodem and Xmodem protocols. The WXTERM.ARC as distributed did not
include source code. I believe this is written in Turbo Pascal and
originates with some folks associated with the "PLINK" (People Link)
service. It is public domain and distribution is encouraged because they
want to see more people using the WXmodem protocol.
On CP/M computers we have no implimentation of ZMODEM (which I consider to
be a better protocol for the new high-speed modems and packetized
networks). I had hoped that someone would write a Zmodem program but none
seems forthcoming. The protocol seems too complex to try to write an
assembly-language version for CP/M. Compiled "C" versions are too big to
fit in most people's transcient program space.
The only alternative seems to be to go to WXmodem. Does anyone have the
latest Turbo Pascal source for it? I'd like to try to convert it to run
on CP/M.
--Keith Petersen
Arpa: W8SDZ@SIMTEL20.ARPA
Uucp: {decwrl,harvard,lll-crg,ucbvax,uunet,uw-beaver}!simtel20.arpa!w8sdz
GEnie: W8SDZ
RCP/M Royal Oak: 313-759-6569 - 300, 1200, 2400 (V.22bis) or 9600 (USR HST)
------------------------------
Date: Saturday, 13 February 1988 17:05-MST
From: Dave Goldblatt <dave@CLUTX.CLARKSON.EDU>
Subject: WXTERM (Windowed Xmodem Terminal) Source Code Source
I would suggest using SEAlink over WXMODEM, as it is supported over a much
larger base. SEALink is built into the Opus bulletin board system, and is
present in MANY of the newer terminal programs. It is fully compatible
with Xmodem, and uses a 6-block window for greater efficiency over
packet-switched networks and the like. It is also VERY easy to implement.
I'll see if I can dig up the sample source code for it; if you have a
local Opus bulletin board, see if they have the BinkleyTerm program
available; in the source for Binkley are routines for Zmodem, Xmodem,
Ymodem, and SEAlink.
-dg-
Internet: dave@clutx.clarkson.edu or dave@sun.soe.clarkson.edu
BITNET: dave@clutx.Bitnet or USERBH0U@CLVM.Bitnet
uucp: {rpics, gould}!clutx!dave
Matrix: Dave Goldblatt @ 1:260/360
------------------------------
Date: Wed, 3 Feb 88 08:41 PST
From: "Ouri ELZUR - ICT <ELZUR%IIL%sc.intel.com@RELAY.CS.NET>
Subject: Aligned Memory Allocation With MSC 5.0
I am using the MSC compiler ver 5.0. Can anyone suggest a way to allocate
a 64KB memory, in an IBM PC AT or a clone, which is ALIGNED to the 64K
boundary (0x____0000)?
Is it expandable to 128K as well?
Can it be used in conjunction with SMALL model?
THANKS !
CSNET: ELZUR%IIL@SC.INTEL.COM
BITNET: ELZUR%IIL%SC.INTEL.COM@CSNET-RELAY
------------------------------
Date: Sat, 13 Feb 88 14:28:25 EST
From: rdavenport@GTEWIS.ARPA
Subject: Upgrading PS/2 to 640K
Hello all...
I've got an IBM PS/2 Model 25 with 512K and I want to upgrade it to
640K, without paying the $50 the IBM dealer wants for the job.
I know the 25 uses a different kind of chip (single in-line?) for
memory and they're mounted differently than the old PC.
Does anyone know what type of chips I will need and where I can get
them, and where they go in the machine (not having found the right IBM
manual around)? I looked inside the thing and think I know where they go
but I want to be sure.
thanks,
rob
/------------------------------\
| Robertson G. Davenport |
| MAP : Billerica, MA 01821 | C the world....
| BELL: (617) 671-5180 |
| ARPA: rdavenport@gtewis.arpa |
\------------------------------/
------------------------------
Date: Thu, 11 Feb 88 10:20 EST
From: Jim Fullton <FULLTONJ%UNCG.BITNET@CUNYVM.CUNY.EDU>
Subject: FORTH Compiler
We are looking for a FORTH compiler that will run on an IBM-PC,
but generate ROM-able object code for the 8085 microprocessor. Can
anybody on the net help with this?
Thanks
Jim Fullton
------------------------------
Date: 11 Feb 88 16:17:44 GMT
From: Michael Stopper <psuvax1!bumpy@cisunx.cs.psu.edu>
Subject: Hard Disks on the IBM PS/2
Computing and Information Systems at the University of Pittsburgh
recently purchased about 50 IBM PS/2's, Models 50 and 60. We have been
having a lot of problems with the hard drives (types 30 and 32). The
biggest problem is this: the da*n hard drives sometimes forget how to
boot themselves!!
A FORMAT or even FDISK does not solve the problem; the disk simply will
not boot and defaults to cassette basic. However, if the computers are
booted from drive A: (a 1.44 meg floppy) drive C: becomes accessible, and
any files that were installed via SELECT or even COPY appear in the
correct directories.
We have heard rumors from IBM (at least that's where they say the rumors
come from) that the first several thousand PS/2's shipped have problems
with either drive controller cards or battery power on the motherboard.
Could anyone offer help with either a program to recover the boot sector
of the hard drive or advice on where to seek other help. We are in dire
need of assistance; as of this writing 6 of the Model 50's at this campus
computing lab have this problem, and various others at other computing
sites on campus are inflicted with the same bug.
Has anyone else experience this type of bug??? (or perhaps I should say
flaw)??
Any help would be greatly appreciated
------------------------------
Date: Thu, 11 Feb 88 10:54:53 CST
From: mlw@ncsc.ARPA (Williams)
Subject: NROFF-like DOS formatter
Is anyone aware of a text formatter that uses NROFF's command structure?
PD is nice, but not essential. The goal is to create formatted output on
a PC from files originally formatted specifically for NROFF -- another set
of formatting commands will not meet the requirement. Thanks in advance.
Mark L. Williams
(mlw@ncsc.arpa)
------------------------------
Date: Sat, 13 Feb 88 21:10 AST
From: <FSBJB%ALASKA.BITNET@CUNYVM.CUNY.EDU>
Subject: Windows for C
I currently use MS C 5.0 for a lot of applications. I am now in the
market for a windowing library. I'm looking for a package that provides
robust win- dows and menus, ie. pop up, pull down, lotus style, etc.
Something which easily allows for context sensitive help. Basically a
prepackaged user inter- face.
I've read a little on Windows for Data by Vermont Software, and also on C
Tools Plus/5.0 by Blaise. Both seem adequate. However, having never used
any package of this type I would really like some suggestions as to what
is the best package out there, price aside. (let's not get carried away)
Any recommendations would be appreciated. Thanks Brad.
[Start with the Windows package from the Info-IBMPC Lending Library. It's
available from SIMTEL20 in file PD1:<msdos.screen>windows.cat ... gph]
------------------------------
************************
End of Info-IBMPC Digest
-------