paul@vixie.UUCP (Paul Vixie Esq) (01/28/88)
[ 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@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@uunet.uu.net
{uunet,ptsfa,hoptoad}!vixie!paul
San Francisco, (415) 647-7023davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr) (02/02/88)
Although there is now a 386ix newgroup (on some systems), the 80386
mailing list continues. This list covers *all* 386 related topics,
regardless of hardware or software being used.
send requests to 386users-request@udel.edu to join the list. It comes
out about twice a week.
I find it interesting that I was unable to start a 386 newsgroup because
there were not enough people interested in 386 topics, but there are
enough people interested in one 386 operating system to justify a group.
Isn't politics wonderful!
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -mejames@bigtex.uu.net (James Van Artsdalen) (02/04/88)
In article <795@vixie.UUCP>, paul@vixie.UUCP (Paul Vixie Esq) writes: > [...] 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. PC's Ltd supports 34 sector tracks in BIOS in several variants (I can't get to the ROM-based setup program from unix to see exactly how many). But this shouldn't be necessary. I am told that with the Western Digital boards you set the drive type to #1, and the board makes adjustments from there. The person I talked to who's done it doesn't know how the controller does this. The OMTI 8620 is apparently set to drive type #0 (??? so I am told - the controller looks to see what's out there, if anything). > [ general discussion of WD1005 and lack of BIOS 18 head support ... ] > 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. Careful when ordering the WD1002/FOX: lots of places will ship you an XT hard disk controller: apparently there is another WD1002/??? that isn't the same as the /FOX card. Since the WD1005 has no track buffering, I would not expect it to be capable of 1:1 interleave. Perhaps if the peripheral runs at 12MHz you might be able to do 2:1 interleave: I don't know where the cutoff point is. Another argument for the WD1007. One warning about the WD1007: it does not work well with more than 35 sectors per track, and even at 35 sectors per track you can't use 'em all. At 35 sectors per track the hard disk will use the 35th to replace any bad sectors in the first 34, giving you a full 34 per track, but you can't use all 35 per track directly. I know of at least one Micropolis and one CDC drive (ESDI) that support as many as 37 sectors per track via jumpers. I don't really know what to make of this: perhaps someone else can explain. I am wary of trying to use 37 though if the manufacturer only ships the drive set at 34... > [ discussion of a neat Adaptec 2322 board ... ] > So far, > though, I say: stay away from the 1005-WAH, look into the Adaptec 2320/2322. The WD1007 is a better board than the WD1005 anyway. But neither can handle ST506 drives and neither have floppy drive support. There is an OMTI 8620 controller which handles any combination of ESDI and ST506 drives (both of either type or a mixture), and handles 1.2meg and 360K all in one. Like the Adaptec above, this one is also 1:1 interleave with buffering and automatic configuration at power-up. This card cost me $175, and is also currently on order. I will be setting it up with a CDC Wren III-182, an ST-4096 and a 1.2meg floppy on a PC's Ltd 386/16 (running uPort SV/386 L2.2). Send mail if you'd like to know how it turns out. There is another OMTI, the 8627, that drops ST506 in favor of RLL, but is otherwise the same. Use RLL at your own risk. One caveat: I've heard rumors that the buffering hard disk controllers don't do much for Xenix. I've heard this from a couple of places, but not from anyone with firsthand experience. Has anyone actually tried both a buffering and nonbuffering controller on the same hardware/software Xenix machine to see if there is a major difference? One of the 386 machine manufacturers has had several reports that the WD1007 is no better than a WD1005 with Xenix, and there is a comment along this line also in the 386 mailing list. Does Xenix do track-buffering in the kernel? -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Work: 512-328-0282 Home: 346-2444; 110 Wild Basin Rd. Ste #230, Austin TX 78746
sl@van-bc.UUCP (Stuart Lynne) (02/08/88)
In article <783@bigtex.uu.net> james@bigtex.uu.net (James Van Artsdalen) writes: >In article <795@vixie.UUCP>, paul@vixie.UUCP (Paul Vixie Esq) writes: >> [...] First, no BIOS drive-type table I've ever > >Since the WD1005 has no track buffering, I would not expect it to be capable >of 1:1 interleave. Perhaps if the peripheral runs at 12MHz you might be able The recently announced WD1006 does have track bufferring and reputedly can give you 1:1 interleave. >One caveat: I've heard rumors that the buffering hard disk controllers don't >do much for Xenix. I've heard this from a couple of places, but not from >anyone with firsthand experience. Has anyone actually tried both a buffering >and nonbuffering controller on the same hardware/software Xenix machine to see >if there is a major difference? One of the 386 machine manufacturers has had >several reports that the WD1007 is no better than a WD1005 with Xenix, and >there is a comment along this line also in the 386 mailing list. Does Xenix do >track-buffering in the kernel? I'd be *very* suprised if the WD1006 doesn't speed up my 386 system. Right now I'm running with a WD1003 at 2:1 interleave. Going to the WD1006 will allow me to use RLL with 1:1 interleave. The maximum theoretical possible disk transfer rate goes from about 240KBS to somewhere around 800KBS. Now I have no idea how well the 386 and System V will be able to get that data from the controller. It could very well be that we're running at top speed already. I won't be trying it for a few months yet though. All that's currently available is the versions without the floppy controller. I don't mind turfing out my old controller for a more expensive one but I don't want to waste a slot on a floppy disk controller :-) If anyone else has tried the WD1006 let's hear about it! PS Has anyone tried Unix on the Dyna Computer Systems 386 board? It looks really nice, and apparently is available at 20MHz at not too unreasonable a price. -- {ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532
james@bigtex.uu.net (James Van Artsdalen) (02/14/88)
In article <1667@van-bc.UUCP>, sl@van-bc.UUCP (Stuart Lynne) writes: > The recently announced WD1006 does have track bufferring and reputedly can > give you 1:1 interleave. This is correct: I purchased a couple of WD1006's several weeks ago. I still have a free controller, but haven't been able to free up a hard disk to do any testing with unix. Note that you *cannot* simply use a disk formatted by a WD1003 with the WD1006: you must low-format the disk first.. The WD1006 also requires a separate floppy controller, such as the WD1002/FOX. > [...] I'm running with a WD1003 at 2:1 interleave. Going to the WD1006 will > allow me to use RLL with 1:1 interleave. I don't *think* the WD1006 is an RLL controller. I believe it is ST-506 only. > If anyone else has tried the WD1006 let's hear about it! I have been using one under DOS for a couple of weeks: it does fly. As soon as the logistics of a free hard disk work out, I'll try it with uPort unix (which I own): if there is sufficient interest I'm sure I could work something out with a local Xenix user to arrange a test. -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Work: 512-328-0282 Home: 346-2444; 110 Wild Basin Rd. Ste #230, Austin TX 78746
sl@van-bc.UUCP (Stuart Lynne) (02/15/88)
In article <824@bigtex.uu.net> james@bigtex.uu.net (James Van Artsdalen) writes: >> [...] I'm running with a WD1003 at 2:1 interleave. Going to the WD1006 will >> allow me to use RLL with 1:1 interleave. > >I don't *think* the WD1006 is an RLL controller. I believe it is ST-506 only. There are two versions. With and without RLL support. There will be two more versions in another month of two (supposedly) which will floppy support (again, with and without RLL). Remember RLL is just another way of using an ST-506 drive. Same physical configuration and connections. Just a different way to put the bits on the drive. ESDI on the other hand does involve a different way to interface to a hard disk drive. For these there is (I believe) a WD1007 which is ESDI with track bufferring. Don't quote me I could be wrong. -- {ihnp4!alberta!ubc-vision,uunet}!van-bc!Stuart.Lynne Vancouver,BC,604-937-7532
keithe@tekgvs.TEK.COM (Keith Ericson) (02/19/88)
In article <824@bigtex.uu.net> james@bigtex.uu.net (James Van Artsdalen) writes: > > >> If anyone else has tried the WD1006 let's hear about it! > >I have been using one under DOS for a couple of weeks: it does fly. As soon as >the logistics of a free hard disk work out, I'll try it with uPort unix (which >I own): if there is sufficient interest I'm sure I could work something out >with a local Xenix user to arrange a test. THe WD1006 does look-ahead buffering, I believe, and this will probably be a pain in the neck for UNIX which tends to scatter files all over the disk. I, too, have a WD1006 to try with UNIX (Interactive Systems VP/ix) and have received an alternate "non-look-ahead" controller IC to use whenever I get around to it... keith
kirk@braille.UWO.CDN (kirk reiser) (02/20/88)
In article <1674@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >In article <824@bigtex.uu.net> james@bigtex.uu.net (James Van Artsdalen) writes: >>> [...] I'm running with a WD1003 at 2:1 interleave. Going to the WD1006 will >>> allow me to use RLL with 1:1 interleave. >>I don't *think* the WD1006 is an RLL controller. I believe it is ST-506 only. >There are two versions. With and without RLL support. There will be two more >versions in another month of two (supposedly) which will floppy support >(again, with and without RLL). >Remember RLL is just another way of using an ST-506 drive. Same physical >configuration and connections. Just a different way to put the bits on the >drive. St-506, rll, and mfm are all terms used when talking about or working with hard drives. There doesn't seem to be a lot of information abailable about the differences between these systems of disk formatting. It would be nice to see a discussion about the various types of systems like this or some references to where information can be obtained. It is hard to decide which system to use when bying or building a computer if you don't have access to info that will help make the decision. I know rll is used in a lot of new and less expensive computers to boost the disk storage but it seems this could lead to compatibility problems with some software. Kirk -- Kirk Reiser The Computer Braille Facility phone: 519-661-3061 University of Western Ontario email: kirk@braille.uwo.cdn rm-H045 Health Sciences Addition bitnet: kirk@braille.uwocc1.bitnet London, Ont. N6A 5C1
farren@gethen.UUCP (Michael J. Farren) (02/22/88)
In article <231@braille.UWO.CDN> kirk@braille.uwo.cdn (kirk reiser) writes: > >St-506, rll, and mfm are all terms used when talking about or working with >hard drives. There doesn't seem to be a lot of information abailable about >the differences between these systems of disk formatting. There is a lot of information available. All you have to do is to read the appropriate journals, technical magazines, or any good reference on disk systems. There's nothing secret about any of this, you just have to do your homework. >It would be nice >to see a discussion about the various types of systems like this or some >references to where information can be obtained. There has been a lot of discussion of this over time. To reiterate, ST-506 is the hardware interface to the disk drive, and specifies among other things, how data is sent to the drive, how the drive is controlled, and what sort of connectors are used. Other interfaces include SCSI, ESDI, and SMD. Each is different, but the "standard" IBM-PC interface is ST-506. MFM and RLL are two different ways of encoding the data which is sent to the disk. RLL allows 50% more data to be put on the same amount of disk space, but requires more sensitive electronics and a somewhat higher-quality drive. MFM is the "standard" scheme, used on almost all 10 and 20 Megabyte drives. RLL is used mostly in the 30 Megabyte drive packages commonly available. -- Michael J. Farren | "INVESTIGATE your point of view, don't just {ucbvax, uunet, hoptoad}! | dogmatize it! Reflect on it and re-evaluate unisoft!gethen!farren | it. You may want to change your mind someday." gethen!farren@lll-winken.llnl.gov ----- Tom Reingold, from alt.flame