a reply to ISC on 'clarifications'

[Paul Vixie Esq]

[ Note: this article is being sent both to the info-386ix mailing list and
  to the comp.unix.xenix group, since the article I'm answering appeared in
  both places.				--vix ]

In an article sent at 9:56am on 27Jan88, mikeb at ism780b.isc.com writes:

# As a matter of policy, ISC will participate sparingly in usenet groups
# to avoid suspicions of commercialism.

I think that the info-386ix mailing list is entirely outside the domain of
this problem.  The list consists only of people interested in 386/ix, and
thus, any article that ISC posts will be hungrily accepted by all members
of the list.  I understand your concerns about articles on the USENET group
comp.unix.xenix, however.  I'd hope that if/when a moderated newsgroup comes
online to phase out the info-386ix mailing list, you will continue to post
freely there.  In a moderated group, you can be sure that any rah-rah-rah
material will be rejected, etc, etc.

# [...] Actual technical support must come from your supplier of 386/ix.

"In the beginning, there was chaos..."  These are Rough Times, Michael.  My
386/ix supplier has referred clients to ME for help, because CTG could not
get proper answers from ISC.  This is okay with me, by the way.  However,
until things settle out, I suggest that ISC should spend as much time as they
can afford answering problems in this or any other forum -- the support you
speak of just is not in place yet.  I like to hope that by collecting and
organizing the questions and your answers in this forum, I can help see that
your time is used as efficiently as possible.  However, I need your 
participation.

# VP/ix on Terminals
# 
#    VP/ix is not limited to the console.  It runs on dumb ASCII
#    terminals (e.g. vt100s) or PC-compatible terminals (e.g. Wyse 60s)
#    connected to PC asynchronous ports or selected third-party multiport
#    serial adapters.

Note that there is a huge Gotcha here.  Wyse 60 terminals have a way to
remap XON and XOFF so that the terminal can throttle the CPU back without
sending IBM-PC keyboard scan codes (XON and XOFF are identical binary codes
to some scan codes, and when a PC-compatible terminal is in PC-terminal mode,
it sends (and VP/ix expects) scan codes.  The Wyse 60 has a mode wherein it
sends other bytes instead of XON and XOFF, and VP/ix has a way to expect 
these.  However, no other PC-compatible terminal I've examined has this
feature -- they expect to be able to use hardware flow-control to avoid
the problem.  However, 386/ix and VP/ix lose big here:

THE asy(7) DRIVER DOES NOT SUPPORT HARDWARE FLOW CONTROL.  THIS IS NOT A
TOLERABLE THING.

If you want to use VP/ix on an ASCII, PC-compatible terminal on version
1.0.4 of 386/ix, you had better examine things very, very carefully.

If the Bell Technologies ICC serial port driver that ISC plans to release
in 1.0.5 does not have hardware flow-control (RTS/CTS handshaking, including
the much-needed 'ctsmode' command), then in order to use an ICC as your
serial port adaptor with VP/ix, you must have WYSE-60 terminals or some
other terminal that has the ability to re-map its XON and XOFF codes when
in PC-term mode.

I'm spending a lot of time on this one point because it is Extremely Urgent
that ISC be aware of what people actually have to do to make this stuff work.

# Distributors
# 
#    There have been requests for a list of distributors.  We have
#    decided not to include it in this widely distributed response,
#    because it may well be thought inappropriate.  Instead, we'll ask
#    permission of each distributor to be included in a restricted
#    listing.  This is expected to include roughly a dozen names and to
#    be posted next week to the info-386ix mailing list.

This list was received and sent out on the info-386ix mailing list.  If
there is anyone reading this on USENET who does not get the mailing list,
you can send mail to me if you'd like a copy of this distributor list.  It
is fairly short.  If demand warrants, I will post it to USENET - barring
possible complaints from ISC, which are not yet in evidence.

# ESDI
# 
#    ISC is working with several customers with ESDI disk controllers who
#    report difficulties.  This includes 386/ix users who have posted
#    ESDI-related news items.  Each of these customers has a unique
#    situation, however, and installation and configuration errors have
#    not yet been ruled out.  In release 1.0.4, the following are supported:
# 
#       - Compaq 130 with a Compaq-modified WD1007 controller
#       - WD1005-WAH used with 34 sector/track BIOS drive table entries
#       - Adaptec 2320/2322 BIOS-independent controllers

Some notes are appropriate here.  First, no BIOS drive-type table I've ever
seen, nor any that my motherboard vendors and manufacturers have ever seen
or heard of, has even one single entry in it for a 34-sector device.  Perhaps
Compaq's machines are the exception, but in general, 17-sector entries are
the only thing you'll get in your average 386 BIOS.

The WD-1005-WAH has a way to help get around this, however.  If you do not
put a jumper on W2 (i.e., the way they ship it from the factory), the 
controller fools the rest of the system into believing that the drive has
half as many sectors as it really does (17 instead of 34), but twice as many
heads as it really does (in the case of the CDC Wren III-182-ESDI, that's
18 heads instead of 9 heads).  As with 34-sector drive-type entries, however,
you will Almost Never See Or Hear Of 18-head BIOS support.  There just aren't
any drives with 18 heads, and there probably never will be.  I solved this
by using a 15-head drive-type, which only wastes 25 megabytes of the 150 the
drive formats down to ordinarily.  Note that the 1005-WAH has no support for
floppy drives, so you'll need a WD-1002-FOX, which fits in a short slot.
Note also that WD Tech Support told me specifically on the phone that the
controller was only useful at 3:1 interleave.

I have an Adaptec 2322 on order now.  According to their Tech Support people,
this controller (1) has floppy support (the 2320 is the same except for this),
(2) has 8KB of buffering and works fine at 1:1 interleave, and (3) queries
the drive at powerup as to geometry (cylinders, heads, sectors) and somehow
makes the BIOS think that there is a drive-type entry for whatever geometry
the drive has.  This means that you don't need to find a matching drive-type
in your BIOS, an arduous and irritating task.  I'll let you all know how it
works in a few days (the controller was order today, UPS Blue).  So far,
though, I say: stay away from the 1005-WAH, look into the Adaptec 2320/2322.

# ICC
# 
#    The Bell Hub 6 is supported in current releases.  The Bell ICC
#    intelligent 6 port serial board (and others) will be supported in
#    release 1.0.5, scheduled to ship in February.  As with most drivers
#    we receive from third party vendors, modifications are necessary to
#    avoid system conflicts and to provide services for VP/ix compatibility.

As I've suggested in previous notes to the info-386ix list, I well understand
the need for ISC to add VP/ix capabilities to individual serial port drivers
(although the Microport/386 DOSMerge seems to use a standard driver, I'll just
assume that there are a few ioctl()'s and whatnot that ISC decided to put into
tty port driver instead of the tty class driver.  No complaints from me here.

However, note that the Bell Hub 6 board does not support hardware handshaking
and VP/ix demands a kind of software handshaking that most PC-compatible CRTs
don't have.  Thus, getting a Hub 6 will not help you unless you have Wyse 60
terminals, or very compatibles.

A last point on this.  Let me quote a second time:

# [...] release 1.0.5, scheduled to ship in February.  [...]

February is a very long month by my standards.  I started putting this
system together in early December in hopes of having something I could
install in mid-January.  My client prepares Income Tax returns, and they
need to use the system heavily beginning on about 5-February.  If I don't
have the system installed by then, I'm in big big big trouble.

If 1.0.5 is going to be in my mailbox by 5-February, I believe I can
arrange through sleepless nights to have the system ready for it by
then (read: all installed and waiting for Software That Works), and
I think I can just barely make it.  I'd like to go to Uniforum, in fact.
If, however, the software is not going to be around until 10-February,
or 20-February, I had better reserve a seat on the next plane to Bolivia.

What's it going to be?  As I said, February is a VERY LONG MONTH.  I need
to have more specific information about 1.0.5's delivery than "in February".
Since I can't deliver the system in its present state, you may feel free
to ship (either direct or through Tom at CTG) any Alpha-Beta software you
have that seems like it may have been in the same building with someone who
was thinking about examining the ICC drivers when the phone rang.  You may
ship me drivers, kernels, source code, object code.  You may ship the
software on paper tape, mag tape, floppy disks, or stone tablets.  However,
I ask that you do one of three things:

	(1) ship 1.0.5 so that it arrives in San Francisco before 5-February;
	(2) ship random floppy disks with absolutely no warrantee  ''  ''   ;
	(3) tell me that you can't do either and TELL ME WHEN YOU CAN.

This is easily the Most Important single issue I'll discuss in this article.

# Michael T. Bessey
# INTEACTIVE [sic] Technical Support Representative
# INTERACTIVE Systems Corporation, 2401 Colorado Ave, Santa Monica CA 90404

-- 
Paul A Vixie Esq
paul%vixie at uunet.uu.net
{uunet,ptsfa,hoptoad}!vixie!paul
San Francisco, (415) 647-7023