[mod.computers.ibm-pc] Info-IBMPC Digest V4 #141

Info-IBMPC@USC-ISIB.ARPA (Info-IBMPC Digest) (12/24/85)

Info-IBMPC Digest      Monday, 23 December 1985      Volume 4 : Issue 141

This Week's Editor: Billy Brackenridge

Today's Topics:
		Tandy 1000 Software Incompatibilities
			 Good RAM Test Needed
			     "fp" Utility
			    DEBUGGER QUERY
		  PC Paint vs. IBM Graphics Printer
			 Kermit Through a TAC
			 Xenix Badtrack/Clock
	   Memory Above 640K for the IBM PC/XT (Compatible)
			     MASM Support
			  Halting a Program
	   Xenix Xmas Present:  >64K data in Medium Model!
		       DOS vs Direct Screen I/O
			     X.PC Arrives
			   Franz-Like Lisps
	       Fortran Compiler for IBM PC/AT (no 8087)
      IBM compatible PC-10, PC-20 and Commodore Related Magazine
			  KERMIT for DG/1 ?
			Venix/Xenix for the AT
		     HELP: nroff <-> WordPerfect
	    Need Some Coprocessor Pointers and Information
		     Xmodem Protocol Description
	    Picking a Data Base Package & Computer System
		       EGA Vert. Retrace Query?
			  How to get PC-HACK
		       Multi-user DBMS packages
	      Using "cd" (or "cwd") with FTP to SIMTEL20
		   Adding a Hard Disk to the AT...
			 "fp" Utility Needed
			    Xenix and News
			  Cheap PC Clones...
		  Anyone out There Using MS Windows
		  Tecmar Megafunction or Equivalent
			    PCjr Questions
      Creating Commodore Files that can be read by MS or PC DOS
			Software design tools
			   PCUNIX by WENDIN
		ATT DOS 2.11 Backup/Restore /P option
				   
----------------------------------------------------------------------

From: Stephan Alexa Cooper <ins_asac@jhunix.uucp>
Subject: Tandy 1000 Software Incompatibilities
Date: 19 Dec 85 20:16:11 GMT

Sorry to post this, but I got a query a while back asking for
a list of IBM PC programs that Do NOT run on the Tandy 1000.
Here is a summary: (note - this list was compiled from other
sources, I did not write this, just put it together from other
people's replies):

Tandy 1000
==========
RE: its compatibily, It is quite compatible up to a point: I have
found that several games fail to start up (the original version of the
diskette) which indicates problems with the floppy disk controller. I
looked at the schematic diagrams of the t1000 and the XT controller
and they are quite different - the Tandy uses a couple of PAL's and
large devices while the XT controller uses a lot of TTL MSI. Not
having a hardware ref manual for t1000, I don't know if the t1000
emulates the XT controller to a high degree but I doubt it.

Something which annoyed me considerably more: expansion cards of the
right size (10'' or less) don't quite fit: part of the IBM-PC form
factor is a little tab in the end of the metal plate used to hold the
card to the chassis. Well the t1000 motherboard is flat against the
chassis not having any space for the tab. There are two solutions: cut
the tab or remove the metal plate. I removed the plate of a RS232 card
(because of the warranty) but that is not a very good solution because
then the card wobles.

Not wanting to give a bad opinion of the machine, I fully recommend
it.  It works very well, generates little noise, it has a small
footprint, it is cute, and I think it is great. As someone said, it is
what the PCjr should have been. Price/performance-wise, if you buy it
through the mail, it is unbeatable.


> I'm thinking on buying one of these, but I wonder
> how compatible it is with an IBM/PC.
> Can you buy expansion cards and plug them in?
> Can you put an 8087? What about software: would
> it run DBase III, Symphony, etc?

The machine is a cross between the PC and the jr.  One BIG compat. problem
has to do with DMA.  The base machine has none, but the memory cards add
DMA circuitry.  The as a result, you can not use any add-in cards with
memory unless you have first added a tandy memory card.  since the machine
only has 3 slots, this is a pain (tandy has no multi-function card for
this beast last time I checked.)

The keyboard is a bit different.  (BTW - they don't have a scroll lock key,
which some packages want (like 1-2-3), but there is a key combo that emulate
it, I forget which).

As a guide to compatibility, Lotus 1-2-3's IBM version can be made to 
run on the machine (not well, but functional).  However, the hassles/
problems were significant enough that a migration for the tandy was
done.

With the current price trends for the IBM PC, why not wait until
the next round of price cuts (this fall?? if you believe S.Katt)
and get a 'fully compatible unit'  :-).
----- 

> as a result, you can not use any add-in cards with
> memory unless you have first added a tandy memory card.  since the machine
> only has 3 slots, this is a pain (tandy has no multi-function card for
> this...

However, there are third party memory boards that DO work.  The one I have
(an MFB1000, by PBJ(tm)) is one such card.  It comes with a clock, the
capacity for 512K more, and an RS232 port.  The machine itself has a built in
printer port, so I still have two slots left (and I have 640K, a printer port,
and an RS232 and a clock).  This is definitely NOT a pain
(This is definitely NOT a flame, either...just an explanation.)

I would recommend the T1000, as it is (and probably always will be, less
expensive, especially if not bought from a Radio Shack store, but from
a warehouse or computer outlet).
-----

   A couple of weeks ago, I posted an inquiry to the net asking for what
software people knew would not run on a Tandy 1000. At that time, I
promised a summary of responses; well, this is it.

   Six people responded to the original article. Unfortunately, most of the
replies were from people considering the Tandy, rather than from owners.
Nevertheless, a small list of software did evolve:


		Alphabet Zoo- IBM Version (Spinnaker)
		Buzzard Bait (Sirius)
		Mastertype (Scarborough Software)
		Math Blaster (Davidson & Associates)
		Murder by the Dozen (CBS Software)

		CopyIIpc
		PCWRIT

		Prowriter utilities (C. Itoh)

		Telios (seems to talk to the modem, but won't let me in on
			the conversation.)
		PC-VT

Notes:
  The programs are arranged as follows: the first group are
game/educational programs, second are copy programs, third are utilities,
and last are communications programs.

   According to reports, there is one problem with hardware compatibility,
the length of the board. The 1000 is designed to take boards up to 10.5"
long. Unfortunately, many popular boards exceed that length. Any board
which will fit in the short slot of the XT or in the Portable PC should be
right at home in the Tandy.


             Steve Cooper
 Johns Hopkins University
Homewood Computing Center
...!seismo!umcp-cs!jhunix!ins_asac

------------------------------


Date: Thu, 19-Dec-85 18:51:29 PDT
From: bcsaic!asymet!fred@uw-june (Fred Wamsley)
Subject: Good RAM Test Needed

We're looking for a RAM test (to be run on a PC AT) which is more thorough
than the diagnostics which come with the machine.  Most of our AT's run at
9 Mhz, and we need something which will catch intermittent failures from
chips with marginal timing.

	Thanks in advance, Fred Wamsley  Asymetrix Corp.
uw-june!bcsaic!asymet!fred@uw-beaver


------------------------------

From: johnl@ima.uucp
Subject: "fp" Utility



/* Written 11:54 pm  Dec 16, 1985 by mas@charm in ima:net.micro.pc */
> I am looking for a utility program called " fp " or so.  It creates " 
> shared" directories for data files, quite similar to " path" for 
> executable files.  

Try getting "file facility" for $19.95 from IBM.  We use it around here
and it works reliably.  Somebody brought in a copy of "fp" which caused
all sorts of mysterious problems on his machine until I exterminated it
and gave him file facility instead.  Order by calling 800-IBM-PCSW, it's
part number 6276530.

John Levine, ima!johnl

------------------------------


Date:     19 Dec 85 23:31:00 EST
From:       PP147363  <PP147363%CU%CARLETON.BITNET@WISCVM.WISC.EDU>
Subject:  DEBUGGER QUERY

 Has anyone out there ever seen a debbuger that runs off the
 serial port of the PC ? It would be kind of nice to be able
 to see the debug output on a terminal not interfering with
 your real screen. Nothing fancy needed, breakpoints, trace
 (icing like symbols, windows :-), If you've seen macdb for
 the mac you'll know what I Mean.

 Thanks
 John

[I use Codesmith which supports all the Icing you mentioned above. It also 
supports simultaneous use of color and monochrome monitors. Even with just
one monitor it never interfers with what is on the screen. Their phone
number is: (213) 439-2414 -wab]

------------------------------


Date: 20 Dec 85 06:47 EST
From: David Potter - McDonnell Douglas/AUGMENT Div.  <DAP.TYM@OFFICE-1.ARPA>
Subject: PC Paint vs. IBM Graphics Printer

Re your problem with double-spaced output from PC Paint and the IBM
printer -- contact Mouse Systems (the PC Paint developers) for a fix,
which is a do-it-yourself debug operation, as I recall.  I may even
still have the instructions around here somewhere myself -- will pass
it along if I can find it -- but anyway it is a known, easy-to-fix
bug.

Regards -- David


------------------------------


Date:     Fri, 20 Dec 85 9:47:42 EST
From:     Steven Segletes <steven@BRL-TBD.ARPA>
To:       info-ibmpc@usc-isib.ARPA
Subject:  Kermit Through a TAC

There has been mention on the net recently of the difficulty of using kermit
through a TAC.  The problem can be circumvented by disabling the interception
of the `@' character.  Of course, this disables the (re)programming of the TAC
port until you log out and log back onto the TAC.  The procedure is

@b i s
@b o s

These two commands to the TAC request binary input and output to the port,
thus preventing the interception of any characters as special characters.

Steve Segletes
U.S. Army Ballistic Research Laboratory
Aberdeen Proving Ground, MD 21005-5066

<steven@brl.arpa>

p.s. the order in which the two commands are issued is important.  Using the
wrong order will result in the second command being passed through to the host
system.  It is possible that I have specified the wrong order above (I haven't
used this feature in a while), but it should be immediately obvious if I did.

------------------------------


Date: 20 Dec 1985 09:45:20-EST
From: mlsmith@NADC
Subject: Xenix Badtrack/Clock


	Try reinstalling Xenix and when the badtrack program runs, make sure
that the tracks printed on the front of the CMI are found. If not, add them
as well as track 2 (if not listed). Reinstall Xenix and let us know if that
was it. DOS and Unix should read the same time from the same clock! If you
have user files, save them to floppy before reinstallation and good luck!

					mlsmith@nadc.ARPA



------------------------------


Date: 13 Dec 85 08:40 GMT
From: meaders @ KOREA-EMH
Subject: Memory Above 640K for the IBM PC/XT (Compatible)

Looking for information on using memory above the present limit
of 640K.  I have recently assembled a MegaBoard made by Design 
Telecommunications Corp.  In the literature they claim that four banks
of 256K Rams can be installed on the motherboard.  They also briefly 
mentioned the requirement for a reprogramed PAL or PROM and a differant 
BIOS EPROM.  Anybody give me additional info?


------------------------------


From: microsof!gordonl@uw-beaver.arpa
Subject: MASM Support
Date: Fri Dec 20 09:37:38 1985

Re: MASM update policy:

   From: Kim DeVaughn <kim@mips.uucp>
   Date: 11 Dec 85 19:53:49 GMT
	
  Of course, even though I have their buggy Rev 2.x assembler, they won't give
   *me* a break on a new revision ... *my* floppy is from Fujitsu, even though
   it is  says "(c) Microsoft".  And it is MICROSOFT that threatens the wrath
   of God if I don't abide by *their* license agreement.  Talk about having it
   "both ways"!
   
   Fujitsu, of course, has no intention of supporting their customers in this
   matter ... "it's not *our* assembler ... call Microsoft".   Bahhh!  

You don't understand the business arrangement here.  Microsoft sold
Fujitsu the rights to encorporate the MASM code in a product of theirs.
We receive a small fee for this, a few dollars per copy.
The OEM (Fujitsu) is responsible for producing, shipping, and supporting the
product.

I have an Audi, and I happen to know that the climate control system
was designed and built by GM.  But I'm not confused over who sold
me the system, who took the majority of the profit from it, and who is
responsible for supporting it - its AUDI.  If I hear that GM is upgrading
the system on GM cars, all that tells me is that I can ask AUDI to do
right by me and offer the same upgrade.  I realize that GM has no
responsibility towards me - they sold a design and some parts to another
company, and that deal - private between the companies - put the whole
of the support effort on AUDI, in exchange for which they get the bulk
of the money.  I have no explicit or implicit deal with GM - they have no
responsibility towards me.

The thing that confuses you is that it says (c) microsoft on the disk
and you sign a MS license agreement, wheras you don't see GM on the
climate control box.  THis is because of the way that intellectual
property works - GM doesn't have to copyright their climate box, since
it can't be reproduced in a XEROX machine.  And if some company were 
to knock off the design, they have patent protection.

In the case of intellectual property, we have to assert copyright
ownership, rather than patent.  The law requires that each copy carry
the copyright notice - prominantly.  I don't know if the GM gear has to
carry patent numbers, but if so they can be under the covers.
The license agreement is also necesary to keep
from loosing our ownership of the product.  Our name appears on parts
that were sold to OEMs stricly because of legal necessity; the actuality
is that you bought a Fujitsu assembler, and that's where you have to get
your support.  Fujitsu's statement is either made from ignorance, or
you misunderstood when they said, "We don't support this (our) product.
Microsoft sells and supports an identical product, you can see them."

If you buy a Microsoft assembler from Microsoft, you can get support
from Microsoft.

	Gordon Letwin
	Microsoft


------------------------------

Date: Fri, 20 Dec 85 09:58:36 EST
From: Andy_Mondore%RPI-MTS.Mailnet@MIT-MULTICS.ARPA
Subject: Halting a Program

One way you can halt a program is to include "break=on" in your
config.sys file.  This allows Ctrl-Break to be processed whenever
a DOS function is called, whether or not it is an I/O function
call.  However, if you are in a loop, you still need to call a
function in the loop for the break to be processed.  This also
assumes, of course, that the program has not turned off interrupts,
in which case the only thing you can do is a cold boot.

------------------------------


From: Herm Fischer <hermix!fischer@rand-unix.ARPA>
To: info-ibmpc@isib.arpa
Subject: Xenix Xmas Present:  >64K data in Medium Model!
Date: Fri Dec 20 11:30:54 1985

Xenix 3.0 comes from IBM/Microsoft with a large model;  however, as most
experimenters have noted, large model does not work too well.  (For example,
termcap, yacc-generated programs, and other features seem to have large
model troubles.)

But, I discovered that you CAN get medium model programs to allocate
(dynamically) more data segments!!!

First, you need to create a medium model "large data" malloc'er routine.

   Extract from the large model library malloc.o and sbrk.o.  Then use
   adb to patch all name symbols to new values:  I changed *oc to *pb,
   (eg malloc, calloc, and realloc -> mallpb, callpb, etc), free to 
   frfd, and sbrk to sbsj.  Note that the program is checksummed, so that
   for every letter you move up in the alphabet you must move another
   backwards!  The names to change are malloc, calloc, realloc, free,
   and sbrk.  These will now be your medium model large data allocators.

Second, you need to rename the files, e.g., malloc.o -> mallpb.o and
sbrk.o -> sbsj.o.  These need to be included in your compiles or link
steps.

Third, in your medium model programs use the -M[2]el flag, which allows
the far keyword.  Then, mallpb and frfb (et al) have to handle data which
is defined as "char far *" instead of "char *".  For example, the
definition for mallpb is "char far *mallpb();".

You cannot pass as subroutine arguments far pointers to medium model
subroutines.  For example, printf, strcpy and the like, all expect non-far
pointers.  (I wrote my own replacements to copy far-pointer strings to
regular medium model (near pointer strings) so they can be printf'ed.)

Each allocation by mallpb must be less than 32K.  On my system, cumulative 
mallpb's grab up to 500K of data before dieing.  I haven't figured out how 
to get mallpb to nicely tell me it exhausted the amount of space the 
kernel wants it to have.  

Beware that conflicts between stack allocation, medium and large malloc's,
and the like, cause a "memory fault" signal, which is trapped by adb, but
logs you off the shell.

Ignore the linker warning about "mixing models".

   Merry Xmas (with bigger trees [not so pun-nish, now] ),

   Herm Fischer
       {hfischer@ada20.arpa; {randvax,ihnp4,decvax}!hermix!fischer }


------------------------------


Date: Fri, 20 Dec 85 11:21:47 mst
From: Kelvin Nilsen <kelvin%arizona.csnet@CSNET-RELAY.ARPA>
To: Info-IBMPC@usc-isib.arpa
Subject: DOS vs Direct Screen I/O
   
    
    
Steve Walton made a request that future terminal emulation projects use
DOS calls for screen updating:
    
    	It was mentioned that "there are relatively few machine instructions
    	between the DOS screen update and a call to BIOS."
    
    	You'll get a lot of debate on this, BUT even if it were true,
    	there are more fundamental problems:
    
    		Writing screen updates through DOS often encourages that 
    		updates be nicely packaged into character-at-a-time 
    		instructions.
    
    		This is a problem when updating large portions of the screen.
    		Traveling up and down the call chain for each character
    		or short string of update instructions is MUCH more 
    		expensive than a simple block move. I've noticed that the 
    		AT BIOS has fancier screen calls which allow line at a 
    		time updates instead of requiring calls to update each 
    		character position.  Better than the PC, but still not
    		good enough.
    
    		Hiding terminal emulation in a device driver makes it much
    		more difficult to provide asynchronous screen updates.  Screen
    		update instructions sent to an intelligent terminal by a
    		full-screen editor are often more efficiently written to the
    		screen after a group of instructions has been merged together.
    		At high baud rates, the merging of instructions is not
    		perceived by the user.
    			Examples:
    				Insertion of text on an existing line often
    				takes the form of one insert character 
    				instruction for each character of the 
    				inserted text. Have you seen how slow this
    				takes place on a sun workstation?  
    
    				Scrolling within an emacs window is 
    				accomplished by deletion of several lines
    				followed immediately by insertion of the
    				same updated lines.  This appears to the 
    				user as the entire screen jumping up and back
    				down again.  From a human factors standpoint,
    				it is desirable here to merge the delete and
    				insert instructions into a single screen 
    				update.
    
    Another problem.  I'm not sure that WINDOWS will cooperate with an 
    alternative ANSI.SYS.  I have seen no documentation on it at all, so
    please correct me if I'm wrong, but I would expect that WINDOWS is itself
    a replacement for ANSI.SYS.  However it works, WINDOWS cannot be totally
    ignorant of the type of terminal emulation going on, and likewise the
    terminal emulation driver cannot be ignorant of WINDOWS.
    
    The more sophisticated DOS becomes, the more sophisticated application
    software is going to need to be.  My idea for how communications 
    applications will run under DOS 4.0 and up is at the level of multiple
    sessions through the communications software. That is, the communications 
    software will replace WINDOWS.  So called well-disciplined applications 
    can run in sessions of the communications program using the ANSI (or 
    whatever) emulation that is part of the program anyway.  To run 
    "undisciplined" full-screen packages, the communications program goes 
    into the background (where it is still running, just not visible) and 
    understands that it will need to rewrite the entire screen when brought 
    to the foreground.
    
    Or, maybe WINDOWS will provide decent enough communications capabilities 
    that all of us communications programmers will be put out on the street.
    
    kelvin nilsen
    

------------------------------


From: Chuck Forsberg WA7KGX <caf@omen.uucp>
Subject: X.PC Arrives
Date: 18 Dec 85 13:29:39 GMT


Omen Technology has recently received Version 2.3 of the Tymnet X.PC
driver.  This version corrects a stack usage incompatibility with DOS
which caused poor error recovery to line hits as well as crashes with
some multitasking systems such as DESQview, Windows, etc.  The fix
should also help Microsoft Access users attempting to use X.PC over
imperfect phone lines.

X.PC provides an end to end, error corrected, flow controlled connection
that allows unattended, automatic access of information services through
Tymnet.  Just think, no }}i characters to confuse your scripts!

Version 15.16 of Professional-YAM communications software (YAMKXPC.EXE)
takes full advantage of X.PC with the public domain YMODEM-g and Kermit
Sliding Windows file transfer protocols.  These provide high throughput
file transfers resistant to delays introduced by timesharing systems,
satellites, networks, and X.PC itself.

YAMKXPC supports concurrent capture on up to three X.PC virtual channels,
or full script operation on one channel with concurrent capture (or upload)
on the other two.

Please contact Omen Technology for more details.

-- 
  Chuck Forsberg WA7KGX   ...!tektronix!reed!omen!caf   CIS:70715,131
Omen Technology Inc     17505-V NW Sauvie Island Road Portland OR 97231
Home of Professional-YAM, the most powerful COMM program for the IBM PC
Voice: 503-621-3406 TeleGodzilla: 621-3746 (Hit CRs) L.sys entry for omen:
omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp

------------------------------


From: michael b maxwell <michaelm@bcsaic.uucp>
Subject: Franz-Like Lisps
Date: 17 Dec 85 21:40:38 GMT


I'm looking for lisps that are available on pcs running MS-DOS, XENIX,
Sys V, or OS-9.  The lisps should meet the following criteria:
	-include a compiler
	-resemble Franz or Common Lisp in their syntax
	-be able to access a "reasonable" amount of memory (640k is
	  *not* a reasonable amount!)
	-have "hooks" to the operating system (like Franz Lisp's
	  *process)
In addition, my understanding is that structures like vectors and hunks
are much faster to access than lists, since you don't have to follow
pointers (assuming the language has been written in a reasonable way!).
So my dream lisp should have such data structures, and preferably a
defstruct macro to make accessing them easier.
I'm aware of Gold Hill Common Lisp (which will have a compiler and large
memory capabilities "real soon now").  And I've heard that commercial
Franz is available for Sys V, but at a price...  Any others?  Please mail
replies to:
-- 
Mike Maxwell
Boeing Artificial Intelligence Center
	...uw-beaver!uw-june!bcsaic!michaelm

------------------------------


From: Gary Vecellio <vecellio%BUFFALO@CSNET-RELAY>
Subject: Fortran Compiler for IBM PC/AT (no 8087)
Date: 19 Dec 85 15:19:23 GMT
To:       info-ibmpc@usc-isib.ARPA


Could someone point me in the direction of a Fortran
compiler for an IBM PC/AT (without an 8087 chip). The main
criteria is compatibility with Vax VMS Fortran 77 and PDP
RSX-11 Fortran. We do a lot of byte calculations so a 
integer*1 would be useful.

			Thanks in advance.
			Gary Vecellio

UUCP ..!{watmath|dual|decvax}!sunybcs!vecellio
CSNET  vecellio@BUFFALO.CSNET-RELAY

------------------------------


From: Kevin Hoskins <kev@voder.uucp>
Subject: IBM compatible PC-10, PC-20 and Commodore Related Magazine
Date: 19 Dec 85 16:44:22 GMT

     My mail does not seem to be going out. Therefore, for the people 
that have responded and asked for the address of The Transactor, here
it is:

          The Transactor
          277 Linwood Avenue
          Buffalo, NY
                      14209-9990

     Subscriptions are $15 for 6 consecutive issues, back issues are 
available at $4.50 each, and disks containing programs from volume 4 
to the present are $7.50 each.

      Kevin
 

------------------------------


From: Dick Lane <lane@u-mt.uucp>
Subject: KERMIT for DG/1 ?
Date: 20 Dec 85 06:21:43 GMT


    Is there a version of KERMIT which is tailored to run on the Data
General/One ?  (A friend has bootstrapped the generic MS-DOS version to run on
the DG/1, we're looking now for a version adapted to the DG/1's communications
port.)  If you know where such a thing might exist, please send me Email with
pointers (path to me:  ... ! ucbvax ! ucdavis ! u-mt ! lane ), thanks.



    Some people here may want to consider a commercial program for file
transfers and terminal emulation.  Use of KERMIT protocol and VT100 emulation
seem most important, emulation of a Tektronix 4010 would be nice; our
communications are with DEC-20's, VAX's running Unix or VMS, and miscellaneous
MS-DOS machines (each has KERMIT).  The following table summarizes a few
features of some programs whose literature asserts they run on the DG/1.

		    File Transfer	Terminal Emulation	Copy
Program		ASCII	KERMIT	XMODEM	VT100	Tek4010		Protc'd  Price
------------------------------------------------------------------------------
PC-PLOT 	*			*	*		N	  $ 95
COMMX/PC	*		*	*				  $ 99
Crosstalk XVI	*		*	*			N	  $195
MITE/MS		*		*					  $195
poly-COM	*			*				  $200
Relay Gold	*	*	*	*			N	  $149
SmarTerm 100	*		*	*				  $175
Softerm PC	*		*	*			Y	  $195

    ZAP ($85), VTEK ($150), EM100 ($149) and EM4010 ($249) also seem
interesting (ZAP, VTEK and EM4010 will emulate a Tek4010) -- however, they do
not claim to work with the DG/1. Perhaps the recent bargain price on DG/1's to
university students and faculty has created a larger market which will
encourage program developers to add the DG/1 to their repertoire.

    I would appreciate comments -- based upon experience -- about good or bad
features of those or other programs.  I will summarize to the net.

		Thanks	  --	Dick
-- 
US Mail :	Dick Lane,	University of Montana, Missoula, MT	59812
    Department of Mathematical Sciences			Computer Center
phone :		(406) 243-2607					(406) 243-5455
UUCP :	... ! ucbvax ! ucdavis ! u-mt ! lane

------------------------------


From: "Josh Sirota [wizard]" <JSS@lsrhs.uucp>
Subject: Venix/Xenix for the AT
Date: 20 Dec 85 16:24:44 GMT


Can anyone out there give some advice about getting Venix or Xenix for
the AT?  I have recently gotten a Televideo AT, and I have a 30 MB disk.
Has anyone tried either one on the Televideo, or does anyone have any
strong feelings one way or the other?  And how much do they cost?

Thanks.

        Josh Sirota
        lsrhs!jss@{bbncca,wjh12}.arpa
	{genrad!grkermit,maynard}!lsrhs!jss

------------------------------


From: bcking@faust.uucp
Subject: HELP: nroff <-> WordPerfect
Date: 19 Dec 85 20:26:00 GMT


We need a way to exchange WordPerfect files and nroff files.  Does
anybody know how to do this?

What we have is a bunch of PCs running WordPerfect (we like it a lot,
especially 4.1), and a bunch of minis (VAXen and PDP-11s running Unix)
that know about nroff/troff.  And a couple of Imagen laser printers.
It sure would be nice to be able to take an nroff input file, mess with
it using WordPerfect and print the result on the laser printer.  And
then take a WordPerfect file, send it to the VAX and add a bunch more
text to it, then troff it to the laser printer.

We'd like to preserve formatting info (like indents and stuff) and
"hard" pagination and RETURN, but put off line wrapping, word spacing,
page numbering, etc.  

What may make this a little easier is that WordPerfect already has a
convert program that can deal with WordStar, DCA and DIF.

	== Christine King
	   {ihnp4,ima}!inmet!bcking
	   Intermetrics, Inc.  733 Concord Avenue Cambridge MA 02138

------------------------------


From: Bob Erickson <bob@hhb.uucp>
Subject: Need Some Coprocessor Pointers and Information
Date: 20 Dec 85 15:47:49 GMT

I'm looking for the following combination of hardware and software
to plug into a PC/XT/AT system.

 A coprocessor board with either  a 32XXX or 68XXX microprocessor.
 Minimum of 2MB of memory.
 Berkeley UNIX 4.2.
 Full TCP/IP ethernet support using either a smart 3COM or Excelan board.

	
I would appreciate any information on anyone making such a combination.



========================================================== Be

Company: 	HHB-Softron
		1000 Wyckoff Ave.
		Mahwah NJ 07430
		201-848-8000

UUCP address:	{ihnp4,decvax,allegra}!philabs!hhb!bob

------------------------------


From: Tom Reingold <reintom@rocky2.uucp>
Subject: Xmodem Protocol Description
Date: 21 Dec 85 03:32:51 GMT

Here it is.  I got it from a bulletin board.  I don't remember which
one.

		Tom Reingold
		New York City



              XMODEM File Transfer Protocol

                    By Larry Jordan

When transferring files between computers using the telephone
system, there is always the chance that electrical noise will
result in data transmission errors. To ensure proper transfer of
files it is necessary to detect data transmission errors and to
retransmit data that contains errors. Most people think that
asynchronous parity error detection provides that capability. It
does not. Parity error detection does tell you when a data
transfer error has occurred, but it is up to you to retransmit
the data to correct errors. The problem is that parity error
detection is not actually performed by most IBM PC communication
packages. If a package does perform the error detection, it may
not inform you of errors in such a way that you know to
immediately retransmit the data. ASCOM, for example, places an
asterisk in a file where parity errors are detected, but you
may not realize the errors occurred until long after the file is
transferred. To ensure "error-free" data transfer you need a
protocol file transfer technique. Andrew Fluegelman has added
such a technique to PC-TALK.III called the XMODEM protocol.

A protocol is a set of rules and conventions that apply to a
specific area of communications that allow participants to
properly communicate regardless of the hardware brand or software
package being used. The protocol file transfer is a set of rules
for transferring files which specifies a set of ASCII handshaking
characters and the sequence of handshaking required to perform
certain file transfer functions. Protocol handshaking signals
allow communication software to transfer text, data and machine
code files, and to perform sophisticated error-checking. The
handicap in using protocol file transfer techniques is that the
computers on both ends of the communications link must be using
compatible software; there is no standard that controls these
protocols and almost all communication packages that have a
protocol file transfer option use a protocol unique to that
package. This means that a business or group of people must
standardize its microcomputer communications software to take
advantage of protocol transfers.

The Ward Christensen XMODEM protocol is one specific file
transfer protocol that may become a default standard in personal
communications because of its widespread use on  bulletin
boards and because of its inclusion in low cost personal computer
communication packages such as PC-TALK. It has not gained
widespread acceptance in business communication packages partly
because the protocol is public domain; most business
communication package designers use unique protocols to force
businesses to use their software on both ends of communication
links. By providing you with this insight into protocol transfer
and explaining in detail the operation of the XMODEM protocol, I
hope to add momentum to the development of a "standard protocol"
whether it be the XMODEM model or some other model. Users of
communication software deserve a standard protocol that will
allow them to use the technique with any microcomputer regardles
of the software packages employed.

The XMODEM protocol is illustrated in Figure 1. As you can see
from that figure, XMODEM does not begin the transfer of data
until the receiving computer signals the transmitting computer
that it is ready to receive data. The Negative Acknowledge (NAK)
character is used for this signal and is sent to the transmitting
computer every 10 seconds until the file transfer begins. If the
file transfer does not begin after 9 NAK's are sent, the process
has to be manually restarted.

After a NAK is received, the transmitting computer uses a Start
of Header (SOH) character and two block numbers (a true block
number followed by a 1's complement of the number) to signal the
start of a 128-byte block of data to be transferred then sends
the block followed by an error-checking checksum.  The checksum
is calculated by adding the ASCII values of each character in the
128 character block; the sum is then divided by 255 and the
remainder is retained as the checksum.  After each block of data
is transferred, the receiving computer computes its own checksum
and compares the result to the checksum received from the
transmitting computer.  If the two values are the same, the
receiving computer sends an Acknowledge (ACK) character to tell
the receiver to send the next sequential block.  If the two
values are not the same, the receiving computer sends the
transmitter an NAK to request a retransmission of the last block
This retransmission process is repeated until the block of data
is properly received or until 9 attempts have been made to
transmit the block.  If the communications link is noisy,
resulting in improper block transmission after 9 attempts, the
file transfer is aborted.

XMODEM uses two block numbers at the start of each block to be
sure the same block is not transmitted twice because of a
handshake character loss during the transfer. The receiving
computer checks the transmitted block to be sure that it is the
one requested and blocks that are retransmitted by mistake are
thrown away. When all data has been successfully transmitted, the
transmitting computer sends the receiver an End of Transmission
(EOT) character to indicate the end of file.

The XMODEM protocol offers the IBM PC several advantages over other
protocols and file transfer methods. First, the protocol is in
the public domain which makes it readily available for software
designers to incorporate into a communications package. Second,
the protocol is easy to implement using high level languages such
as BASIC or Pascal. Third, the protocol only requires a 256-byte
communication receive buffer which makes it attractive for IBM PC
owners who only have 64K systems. Forth, the protocol allows a
user to transfer non-ASCII 8-bit data files (i.e., COM, EXE and
tokenized BASIC) between microcomputers because it calculates the
end of a file based on file size and uses handshake signals to
indicate the end of a file instead relying on an end of file
marker character (control-Z) to terminate a file transfer.
Fifth, XMODEM error-checking is superior to normal asynchronous
parity error checking.  The parity method of error-checking is
95% effective if the software on the receiving end checks for
parity errors.  XMODEM error-checking is 99.6% effective, and the
software on the receiving end must check for errors.  Parity
errors detected also do not result in automatic retransmission of
the bad data; XMODEM detected errors result in data
retransmission until no errors are detected or until 9
retransmissions have been attempted.  Finally, the protocol is
used by many CP/M bulletin boards and having the protocol in a
communications package allows the IBM PC user to receive
error-checked files from these bulletin boards.

Andrew Fluegelman has given the XMODEM protocol a real boost in
the IBM PC world by including it in his package. He has also
added significant power to the package by including the protocol
Rumor has it that Don Withrow will soon add to the XMODEM
momentum by adding it to his HOSTCOMM software package. Keep up
the good work guys -- we will get a standard one way or the
other!

[This article was derived from material contained in a book
written by Larry Jordan and Bruce Churchill to be published this
Summer by The Brady Company. The article will also be in the
5th issue of PC World magazine.]



             XMODEM Protocol File Transfer


Receiving                                      Transmitting
Computer                                         Computer
Ready to                                         Ready to
Receive                                          Transmit
   |                                                |
   |                                                |
   |---------------------\NAK\--------------------->|
   |                                                |
   |<------/SOH/Blk #1/Blk #1/Good Data/CkSum/------|
   |                                                |
   |---------------------\ACK\--------------------->|
   |                                                |
   |<------/SOH/Blk #2/Blk #2/Good Data/CkSum/------|
   |                                                |
   |---------------------\ACK\--------------------->|
   |                                                |
   |<------/SOH/Blk #3/Blk #3/Garbled Data/CkSum/---|
   |                                                |
   |---------------------\NAK\--------------------->|
   |                                                |
   |<------/SOH/Blk #3/Blk #3/Good Data/CkSum/------|
   |                                                |
   |---------------------\ACK\--------------------->|
   |                                                |
   |<--------------------/EOT/----------------------|
   |                                                |
   |---------------------\ACK\--------------------->|
   |                                                |
   V                                                V

  File                                             File
Receipt                                          Transmit
  Ends                                             Ends

                           Figure 1


-------------------------------------------------------------------


MODEM PROTOCOL OVERVIEW

1/1/82 by Ward Christensen.  I will maintain a master copy of
this.  Please pass on changes or suggestions via CBBS/Chicago
at (312) 545-8086, or by voice at (312) 849-6279.

NOTE this does not include things which I am not familiar with,
such as the CRC option implemented by John Mahr.

Last Rev: (none)

At the request of Rick Mallinak on behalf of the guys at
Standard Oil with IBM P.C.s, as well as several previous
requests, I finally decided to put my modem protocol into
writing.  It had been previously formally published only in the
AMRAD newsletter.

        Table of Contents
1. DEFINITIONS
2. TRANSMISSION MEDIUM LEVEL PROTOCOL
3. MESSAGE BLOCK LEVEL PROTOCOL
4. FILE LEVEL PROTOCOL
5. DATA FLOW EXAMPLE INCLUDING ERROR RECOVERY
6. PROGRAMMING TIPS.

-------- 1. DEFINITIONS.
<soh>   01H
<eot>   04H
<ack>   05H
<nak>   15H
<can>   18H

-------- 2. TRANSMISSION MEDIUM LEVEL PROTOCOL
Asynchronous, 8 data bits, no parity, one stop bit.

    The protocol imposes no restrictions on the contents of the
data being transmitted.  No control characters are looked for
in the 128-byte data messages.  Absolutely any kind of data may
be sent - binary, ASCII, etc.  The protocol has not formally
been adopted to a 7-bit environment for the transmission of
ASCII-only (or unpacked-hex) data , although it could be simply
by having both ends agree to AND the protocol-dependent data
with 7F hex before validating it.  I specifically am referring
to the checksum, and the block numbers and their ones-
complement.
    Those wishing to maintain compatibility of the CP/M file
structure, i.e. to allow modemming ASCII files to or from CP/M
systems should follow this data format:
  * ASCII tabs used (09H); tabs set every 8.
  * Lines terminated by CR/LF (0DH 0AH)
  * End-of-file indicated by ^Z, 1AH.  (one or more)
  * Data is variable length, i.e. should be considered a
    continuous stream of data bytes, broken into 128-byte
    chunks purely for the purpose of transmission.
  * A CP/M "peculiarity": If the data ends exactly on a
    128-byte boundary, i.e. CR in 127, and LF in 128, a
    subsequent sector containing the ^Z EOF character(s)
    is optional, but is preferred.  Some utilities or
    user programs still do not handle EOF without ^Zs.
  * The last block sent is no different from others, i.e.
    there is no "short block".

-------- 3. MESSAGE BLOCK LEVEL PROTOCOL
 Each block of the transfer looks like:
<SOH><blk #><255-blk #><--128 data bytes--><cksum>
    in which:
<SOH>       = 01 hex
<blk #>     = binary number, starts at 01 increments by 1, and
              wraps 0FFH to 00H (not to 01)
<255-blk #> = blk # after going thru 8080 "CMA" instr, i.e.
              each bit complemented in the 8-bit block number.
              Formally, this is the "ones complement".
<cksum>     = the sum of the data bytes only.  Toss any carry.

-------- 4. FILE LEVEL PROTOCOL

---- 4A. COMMON TO BOTH SENDER AND RECEIVER:

    All errors are retried 10 times.  For versions running with
an operator (i.e. NOT with XMODEM), a message is typed after 10
errors asking the operator whether to "retry or quit".
    Some versions of the protocol use <can>, ASCII ^X, to
cancel transmission.  This was never adopted as a standard, as
having a single "abort" character makes the transmission
susceptible to false termination due to an <ack> <nak> or <soh>
being corrupted into a <can> and canceling transmission.
    The protocol may be considered "receiver driven", that is,
the sender need not automatically re-transmit, although it does
in the current implementations.

---- 4B. RECEIVE PROGRAM CONSIDERATIONS:
    The receiver has a 10-second timeout.  It sends a <nak>
every time it times out.  The receiver's first timeout, which
sends a <nak>, signals the transmitter to start.  Optionally,
the receiver could send a <nak> immediately, in case the sender
was ready.  This would save the initial 10 second timeout.
However, the receiver MUST continue to timeout every 10 seconds
in case the sender wasn't ready.
    Once into a receiving a block, the receiver goes into a
one-second timeout for each character and the checksum.  If the
receiver wishes to <nak> a block for any reason (invalid
header, timeout receiving data), it must wait for the line to
clear.  See "programming tips" for ideas
    Synchronizing:  If a valid block number is received, it
will be: 1) the expected one, in which case everything is fine;
or 2) a repeat of the previously received block.  This should
be considered OK, and only indicates that the receivers <ack>
got glitched, and the sender re-transmitted; 3) any other block
number indicates a fatal loss of synchronization, such as the
rare case of the sender getting a line-glitch that looked like
an <ack>.  Abort the transmission, sending a <can>

---- 4C. SENDING PROGRAM CONSIDERATIONS.

    While waiting for transmission to begin, the sender has
only a single very long timeout, say one minute.  In the
current protocol, the sender has a 10 second timeout before
retrying.  I suggest NOT doing this, and letting the protocol
be completely receiver-driven.  This will be compatible with
existing programs.
    When the sender has no more data, it sends an <eot>, and
awaits an <ack>, resending the <eot> if it doesn't get one.
Again, the protocol could be receiver-driven, with the sender
only having the high-level 1-minute timeout to abort.


-------- 5. DATA FLOW EXAMPLE INCLUDING ERROR RECOVERY

Here is a sample of the data flow, sending a 3-block message.
It includes the two most common line hits - a garbaged block,
and an <ack> reply getting garbaged.  <xx> represents the
checksum byte.

SENDER                                  RECEIVER
                                times out after 10 seconds,
                        <---            <nak>
<soh> 01 FE -data- <xx> --->
                        <---            <ack>
<soh> 02 FD -data- xx   --->    (data gets line hit)
                        <---            <nak>
<soh> 02 FD -data- xx   --->
                        <---            <ack>
<soh> 03 FC -data- xx   --->
   (ack gets garbaged)  <---            <ack>
<soh> 03 FC -data- xx   --->            <ack>
<eot>                   --->
                        <---            <ack>

-------- 6. PROGRAMMING TIPS.

* The character-receive subroutine should be called with a
parameter specifying the number of seconds to wait.  The
receiver should first call it with a time of 10, then <nak> and
try again, 10 times.
  After receiving the <soh>, the receiver should call the
character receive subroutine with a 1-second timeout, for the
remainder of the message and the <cksum>.  Since they are sent
as a continuous stream, timing out of this implies a serious
like glitch that caused, say, 127 characters to be seen instead
of 128.

* When the receiver wishes to <nak>, it should call a "PURGE"
subroutine, to wait for the line to clear.  Recall the sender
tosses any characters in its UART buffer immediately upon
completing sending a block, to ensure no glitches were mis-
interpreted.
  The most common technique is for "PURGE" to call the
character receive subroutine, specifying a 1-second timeout,
and looping back to PURGE until a timeout occurs.  The <nak> is
then sent, ensuring the other end will see it.

* You may wish to add code recommended by Jonh Mahr to your
character receive routine - to set an error flag if the UART
shows framing error, or overrun.  This will help catch a few
more glitches - the most common of which is a hit in the high
bits of the byte in two consecutive bytes.  The <cksum> comes
out OK since counting in 1-byte produces the same result of
adding 80H + 80H as with adding 00H + 00H.

------------------------------


From: Kerro Panille <vch@rruxo.uucp>
Subject: Picking a Data Base Package & Computer System
Date: 20 Dec 85 22:28:33 GMT

>     I am looking for a multiuser or networked system which can:
>
>		  o Run very fast!!
>		  o Handle databases with over 5000 records
>		    with little to no change in acces time.
>                  o Able to communicate with AT&T 3B2 with
>		    little to no conversion.
>
>     One particular system I have been looking at is the IBM AT.  I also
>am looking at the Tandy 1200HD which is rumored to between the IBM XT and
...
>     Some software packages I have been looking at are:
...
>                  o PC/Focus - This by far is the most impressive software
>			       packages I've seen yet.  Purdue University had
>			       this demonstrated in their proto-typing class.
>			       Has anybody used this in the workplace?  If so
>			       how is it?

I have had more experience with PC/FOCUS than I care to admit. I found it
powerful, yet it didn't live up to the billing that Information Builders,Inc
give it. (IBI wrote PC/FOCUS as well as it's companion for IBM mainframes,
FOCUS) It is badly documented, technical questions are not answered by IBI
at all - they don't even know their own product, ie. you get conflicting
answers if you call more than once. Basically, they say it can do something
that sounds great, but when you try it, you find out that it can only 
perform under VERY specific conditions. Hardly useful. Also, it's incredibly
slow. At the price of $1500.00, it is NOT WORTH IT. At $200.00 it might be.

-- 
Vince Hatem          	               ----------------		           A
Bell Communications Research           | UZI          |----------|_ _ _\/  T
Raritan River Software Systems Center  |              |----------|     /\  &
444 Hoes Lane                          ----------------  ROGER GUTS 	   T 
4D-360                                   /     /\  DON'T NEED NO STINKIN' 
Piscataway, NJ 08854                    /     /           NECKTIES
(201) 699-4869                         /-----/
...ihnp4!rruxo!vch

   TRUE GRIT MYSTERIES - The detective series for those who NEVER eat quiche!
         (WARNING - MAY BE EMOTIONALLY DISTURBING TO HAMSTER LOVERS)

------------------------------


Date:  Sat, 21 Dec 85 11:04 EST
From:  Hess@MIT-MULTICS.ARPA
Subject:  EGA Vert. Retrace Query?


Anybody know what the secret is to getting vertical retrace interrupts
(and horizontal retrace interrupts if that's possible) from an IBM EGA
card running on an AT?

Any suggestions or code fragments greatly appreciated,

Brian (Hess@MIT-Multics)

------------------------------


From: "Kurt L. Reisler" <klr@hadron.uucp>
Subject: How to get PC-HACK
Date: 20 Dec 85 14:58:47 GMT

In addition, the latest version of PC-HACK can be downloaded from FIDO 109/483
(Wash-A-RUG) at 703-359-6549.  This is the latest version which supports
VT-100 line graphics.  Again, kudos to Don Kneller.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
                     _
The World's First   /  \		Whose dog is that?
   BBS Network     /|oo \		I don't know, but the disk is yours.
   * FidoNet *    (_|  /_)
                   _`@/_ \    _
                  |     | \   \\
                  | (*) |  \   ))
     ______       |__U__| /  \//
    / Fido \       _//|| _\   /
   (________)     (_/(_|(____/ (jm)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

------------------------------


Date: Sat, 21 Dec 85 15:59:08 EST
From: Dan_Bower%RPI-MTS.Mailnet@MIT-MULTICS.ARPA
Subject: Multi-user DBMS packages

>  There are many out there for the PC that sort of work.  Cornerstone is
>  single-user only, as is KMan.  The authors of KMan put out a more complete
>  multiuser dbms called MDBS, but while looking for a dbms I got a long
>  disgusted message from a guy who said that it was so buggy he gave up.
>  John Levine, ima!johnl
>
Not so.  There is a multi-user version of KnowledgeMan (actually 2;
ver 1.07 and a oft-promised, well-advertised but as-yet undistributed
ver 2.  Supposedly ver 2 has more functions and more overhead, as well
as a few bug fixes.)  Multi-user Kman is available for a number of
networks, as well as VAXen.  Also just released is a Lattice C library
of Kman database calls.

As for the PC version of MDBS III, I have no experience.  I have
written some large applications in Kman.  I find it more flexible
than dBase III, espcially for security and command manipulation.
However, to get decent speed for some functions, you either have
write it in C or run it from a RAM Disk.

------------------------------


Date: Sat, 21 Dec 1985  17:56 MST
From: "Frank J. Wancho" <WANCHO@SIMTEL20.ARPA>
Subject: Using "cd" (or "cwd") with FTP to SIMTEL20

In the past few days, we finally tracked down and fixed a problem that
caused some user FTP programs to appear to hang after doing a "cd" or
"cwd" to a directory on our PD: structure.  Sorry for the temporary
inconvenience.

--Frank

------------------------------


From: "cenkl@faron.research" <cenkl@faron.uucp>
Subject: Adding a Hard Disk to the AT...
Date: 20 Dec 85 15:13:35 GMT

The old IBM ATs (<= 20M hard disks) support 14 distinct hard disk drive 
types (1 - 14) with drive type 15 left open for user defined drives.
Assuming that I have a drive that is not among the first 14,
how do I enter the correct drive type entry (# of cylinders, # of heads, etc.)
given that I know all of the necessary data? The Fall BYTE describing such a
procedure is quite vague on this point. Where in ROM can the table of
drive type entries be found on both the old and new ATs?
Does anybody know which drives drive type 20 corresponds to under the new 
AT ROMs? Thanks in advance. 

Mike Cenkl 
(617)271-2364
faron!cenkl@mitre-bedford.arpa

------------------------------


From: Pierre Darmon <pier@ur-tut.uucp>
Subject: "fp" Utility Needed
Date: 21 Dec 85 23:38:47 GMT

In article <131300006@ima.UUCP> johnl@ima.UUCP writes:
>
>/* Written 11:54 pm  Dec 16, 1985 by mas@charm in ima:net.micro.pc */
>> I am looking for a utility program called " fp " or so.  It creates " 
>> shared" directories for data files, quite similar to " path" for 
>> executable files.  
>

There is a facility called search that does what you want. I am using it all
the time on my AT. It's great. There is another called DPATH. I obtained both
from a BBS in California. The # is (213) 459 6480.


Pierre Darmon
University of Rochester
{allegra|decvax|seismo}!rochester!ur-tut!pier

------------------------------


From: Gerald Collins <jlc@afinitc.uucp>
Subject: Xenix and News
Date: 20 Dec 85 04:50:49 GMT

We need a set of programs to run the news with.  Our current system is a
Plexus P/60 with Sys III and using readnews/postnews to handle our
news processing.  Does any one have any suggestions as to a news
processor for Xenix.  We currently use version 2.10.1 of readnews.
We have 2.10.2 but have never brought it up.  Is there a newer version
of readnews and is it available PD.  I wouldn't mind getting information
on news processors for the Plexus also.  Any news package would need to
be PD for us to be able to use it.  (News is very low priority as far as
the front office is concerned.)  Any help would be greatly appreciated.
Please mail all responses to this request as I do not get to read all
these groups on a regular basis.   Thanks.  
				Gerald L. Collins
				[ihnp4|seismo]!wucs!afinitc!jlc

------------------------------


From: Ross Greenberg <greenber@phri.uucp>
Subject: Cheap PC Clones...
Date: 21 Dec 85 18:17:54 GMT

For those that are interested, I have dealer prices on a decent PC clone:
the Fountain PC.

I'm willing to set up group buys for those that are interested.

An example of pricing:

PC/XT clone, 256K on the momma-board, AST-look-a-like with 384K,
Hercules Look-a-like, 20Meg Seagate or similar (70-85 msec access time),
2 1/2 height floppies, decent monochrome monitor.

Price:   $1,650 + tax (NY) + shipping (or you can pick it up, NYC)

Interested?  Contact me at:

ross m. greenberg
ihnp4!allegra!phri!sysdes!greenber

------------------------------


Date: Sun, 22-Dec-85 09:39:25 EDT
From: David Farber <farber%pcpond.pc.udel.edu@Louie.UDEL.EDU>
Subject: Anyone out There Using MS Windows

I would like to establish some cross talk on Windows and
how to make the bloodie thing work "correctly: -- that is
outside what the manual says .

Dave


------------------------------

Date:  Sun, 22 Dec 85 13:51 EST
From:  Schmandt@MIT-MULTICS.ARPA
Subject:  Tecmar Megafunction or Equivalent

I am looking to speed up my XT with a large Ram-disk.  In particular the
Megafunction card from Tecmar seems at first glance potentially quite
useful; 1 Meg plus memory with external power backup and software.

Has anyone used this board?  Is it what it appears to be?  Does the
ramdisk software allow any size of Ramdisk (as compared to the AST
Rampage, which comes with software for 360K max)?  Is there a better or
cheaper board from some other source?  Note:  I crash the machine a lot,
so the external power is essentia.

Thanks in advance Chris Schmandt


------------------------------


From: Jim Williams <jim@umcp-cs.uucp>
Subject: PCjr Questions
Date: 22 Dec 85 16:18:09 GMT


	I am helping some friends who have a PCjr and who want to
upgrade it some.  They have a jr with a disk drive, an extra 64K
RAM card (total 128K) and an outboard parallel port.  They want to
add a second drive, more memory, and connect the serial port to the
an external modem.  To help them with this I need to know a few
things that aren't in the documentation.  Here's my list:

1. What is the pin-out of the 16-pin header connector for the
   serial port?  I need to make a cable to go from that to a
   DB25 connector.

2. The internal drive has its drive select jumper on 1, not 0!
   If I add a second drive, how do I address it? As drive 2? 3?
   0?

3. What is the best route for memory expansion? Tecmar? Conroy-
   LaPointe is one of the few mail-order places I have found that
   still advertizes PCjr stuff.  Anybody dealt with these people?
   I advised my friends that the best thing to do would be to
   replace the existing 64K card with a larger one rather that go
   to an expansion chassis just to get the slots for extra
   memory, because the chassis are so expansive.

Much thanks to any and all who can help me!
Reply by mail to..

Jim \/\/illiams
jim@maryland.ARPA
seismo!umcp-cs!jim.UUCP

------------------------------


From: Kevin Hoskins <kev@voder.uucp>
Subject: Creating Commodore Files that can be read by MS or PC DOS
Date: 20 Dec 85 16:26:16 GMT

     This could be of wide interest to those that use MS or PC DOS
machines at work and have a C64 at home. The question is;

     Is there some way to program the Commodore 1541 disk drive to 
     format a disk that can be read by MS or PC DOS?

If so, then converting word processing files done on the C64 to Wordstar
compatible files could be done. This would make it easy to do writing 
both at home and at work. This is a less expensive alternative to buying 
a PC.

     Anyone have any suggestions?

     Kevin

     P.S. With regards to my previous posting, I am still considering 
buying a PC compatible. But I would still like to know if the above 
is possible. (I feel that it is.)

------------------------------


Date:         Sun, 22 Dec 1985 22:23 O
From:           Mosh  <NYSHARE%WEIZMANN.BITNET@WISCVM.WISC.EDU>
Subject: Software design tools


Greetings!
    I am desparatley seeking a good software engineering and design tool
for the IBM-PC. The only two I have heard of so far are Jackson (which
I assume uses the Jackson method) and the other is Delta which is used
in European mainframes but is also available on the PC. I would appreciate
any clues on the names and performances on other programs on the market.

------------------------------


From: Raymund Galvin <raymund@sci.uucp>
Subject: PCUNIX by WENDIN
Date: 20 Dec 85 19:09:33 GMT


   Does anybody know anything about PCUNIX by WENDIN?  The price is $49 and
   from the description in the ads (Nov and Dec Computer Language) it sounds
   "too good to be true".  I realize this is only a unix look-a-like, NOT 
   unix.  How does this "operating system" affect programs written to run
   under MSDOS?  Is it "true multitasking" and "multiuser" like their ads
   say?  Or are the ads just a bunch of hype about another useless program?

					  - Ray Galvin

------------------------------


From: Timothy D Margeson <timothym@tekigm.uucp>
Subject: ATT DOS 2.11 Backup/Restore /P option
Date: 21 Dec 85 10:12:41 GMT

Hi netlandians

Has anyone else out here had any experience or problems with the ATT PC-6300
computer when backing up files in subdirectories with ATT MS-DOS v. 2.11.

I have seen the /P option crash no fewer than 3 100+kbyte files that were
backed up across diskettes. Is this a bug in my version of MS-DOS? Has it been
fixed? A bug in the hardware? Or?

Please give me a call or reply before 12-22-85 via mail as my system will be
down from 9:00pm PST 22-DEC-85 until 6:00am PST 7-JAN-86.

In the meantime I am using Compaq MS-DOS v. 2.11 Backup and Restore utilities
since they appear to work properly and do not cause abortions to the files on
restoration.

Thank you in advance, I really do appreciate any light that you can shed :-) !

-- 
Tim Margeson (206)253-5240
tektronix!tekigm!timothym                   @@   'Who said that?'  
PO Box 3500  d/s C1-465
Vancouver, WA. 98665
------------------------------

End of Info-IBMPC Digest
************************

-------