networking under SimulTask

George H. Martin georgemartin at hodgenet.UUCP
Tue Jan 9 18:01:20 AEST 1990

In article <4420 at cuuxb.ATT.COM> fmcgee at cuuxb.UUCP (Frank W. McGee) writes:
>>But the starlan dos server will print when you close the printer port.
>>For example "copy file lpt1:"  works just fine under dos server, but
>>doesn't come out under VP/ix.  Likewise WP 5.0 printouts.
>>Am I doing something wrong?  I really can't imagine anyone getting
>>useful work done when they have to pop up the VP/ix menu or exit
>>their application for every printout.
>Oops, spoke too soon.  I tried what you said and you're correct.  From
>the MSDOS prompt, it looks like you have to a printer buffer flush to
>get anything to print (by pressing ALT-SYSREQ M P).  I'll look into
>it, and see what I can find out. ...

This is correct, per the "as delivered" Simultask arrangement. An alternative
MAY BE to define a new LPT 0,1 or 2 device, which would require a parallel port
that is not also being used by the UNIX lp demon (at least not at the same
time). You would do this using the Simultask DDA facility.

Now, that isn't directly doable by way of the "ddainstall" command, because
the parallel ports are "fixed", by way of their entries in the DDA "control"
file (my terminology), "/usr/vpix/etc/vpixdevs". If you view this file, you see
the entries "PLEL0", "PLEL1" and "PLEL2". You'll also notice the interrupt 
vectors (only for PLEL0, which is the "MDA-display-card-resident printer port),
and the start and end address, in addition to the "fixed" designation, and
other fields for buffer addresses, etc.

Enough background? What you would need to do to try this is:

	1. Edit the vpixdevs file, to remove the existing parallel port entry
	   for the port you want to use (port of the same address - conflicts
	   between entries will not be permitted by "ddainstall" if the 
	   existing entry is for a "fixed" device).

	2. Make a new DDA entry, using a new device name for the printer port,
	   as you want to identify it (for the moment, let's call it "DOSLP").
	   Do this using the "ddainstall" command, not manually, because
	   "ddainstall" also creates a virtual device in the "/dev" directory,
	   using your chosen name (e.g., "/dev/doslp").

	3. Modify the vpix.cnf file for your Simultask session, to change the
	   typical "LPT1  /usr/bin/lp 2>/dev/null" entry to be:

		"LPT1	/dev/(your dda name)"	(e.g., "LPT1  /dev/doslp" )

NOTE: "LPT1" assumes that is what your software looks for. Use whatever name
is expected by your apps (DOS). 

Your apps (and DOS, etc.) should be able to directly address the parallel port
without any support from UNIX, which is what DDA is all about.	

Caveat: This is based on my memory of my own twiddlings of 3 months ago, and I
wasn't actually replacing printer devices, but I was redefining one of my
parallel ports for a COVOX voice synthesizer. The output of that device under
Simultask was chopped up, when compared to its smoothness (voice quality) on my
DOS Tandy 3000HD. So I undid my mods to vpixdevs, etc. and moved it back to
the Tandy. This is not a reflection on ANY of the hardware. Rather, in some
respects, the Simultask environment (specifically, the virtual 8086 mode)
may not offer the same "real-time" responsiveness as the dedicated "real" mode
(as under DOS on my Tandy). I SPECULATE that its due to either the fact that in
the Simultask environment, interrupts are emulated, or that the virtual 8086 
mode (386/25) is not as fast in "realtime" as my 286/8.(?) If any of this 
seems to be critical of Simultask or the virtual 8086 mode, you mistake my
intent; I use this mode often for several DOS apps, and I'm well satisified.

I would appreciate knowing whether this works for you (I didn't want to get
into it on my machine right now). Also, if anyone can enlighten my as to the
correct answer to the less-satisfactory performance of the COVOX stuff under
Simultask, or can confirm either of my suspicions as to the reason, email>me).

George H. Martin
Homer Dodge Network Systems, Inc.
+1 201 454 3333

More information about the Comp.unix.i386 mailing list