kentkar@shambala.uucp (Kent Karrer) (04/21/91)
It is nice to see a unix vendor offering an upgrade to R4.0 at a reasonable cost. But does ESIX still not support RLL disk controllers? -- [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [ A GREAT DEAL OF CHAOS IN THE WORLD occurs because people don't appreciate ] [ themselves. -- Chogyam Trungpa ] [ "SHAMBHALA - The Sacred Path of the Warrior" ] [___________________uunet!seaeast.wa.com!shambala!kentkar___________________]
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) (04/23/91)
In article <1991Apr21.155642.1586@shambala.uucp> kentkar@shambala.uucp (Kent Karrer) writes: >It is nice to see a unix vendor offering an upgrade to R4.0 at a reasonable >cost. But does ESIX still not support RLL disk controllers? > The myth that ESIX doesn't support RLL controllers is a bit of marketing hype. ESIX documentation states unequivocally that ESIX does support RLL, and I can unequivocally state that both 5.3.2.C and 5.3.2.D both support RLL very nicely. -- Kaleb Keithley kaleb@thyme.jpl.nasa.gov Meep Meep Roadrunner Veep veep Quayle
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (04/23/91)
>The myth that ESIX doesn't support RLL controllers is a bit of marketing >hype. How can ESIX even know whether the controller uses RLL? How can anybody find this out without ripping the disk apart and analyzing the bit-patterns stored on the platter? -- Rahul Dhesi <dhesi@cirrus.COM> UUCP: oliveb!cirrusl!dhesi
david@kessner.denver.co.us (David Kessner) (04/23/91)
In article <3080@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes: >>The myth that ESIX doesn't support RLL controllers is a bit of marketing >>hype. > >How can ESIX even know whether the controller uses RLL? How can >anybody find this out without ripping the disk apart and analyzing the >bit-patterns stored on the platter? >-- >Rahul Dhesi <dhesi@cirrus.COM> >UUCP: oliveb!cirrusl!dhesi I am using an Adaptec RLL controler with ESIX 3.2.2d... ESIX _KNOWS_ that it is using an RLL drive-- and tells me that everytime it gives me: "NOTICE: Adapter RLL Disk Unit 1 (System disk 1): optimization changed from..." I dont know how it knows what type of drive it is-- or how/when to change the optimization-- but it does. Quite well in fact... BTW: Why does it change the optimization 'algorithm' anyway? It does it about once a day, and I'd like to know why... -- David Kessner - david@kessner.denver.co.us | do { 1135 Fairfax, Denver CO 80220 (303) 377-1801 (p.m.) | . . . If you cant flame MS-DOS, who can you flame? | } while( jones);
wjb@cogsci.cog.jhu.edu (04/23/91)
In article <3080@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes: >>The myth that ESIX doesn't support RLL controllers is a bit of marketing >>hype. > >How can ESIX even know whether the controller uses RLL? How can >anybody find this out without ripping the disk apart and analyzing the >bit-patterns stored on the platter? True enough, but in the PC world "RLL" usually means an AT bus disk controller which uses a Western Digital compatible register set and has 26 sectors per track. The first two are assumptions built into the kernel and device driver respectively. The third is obtained from the BIOS information about your hard drive. There are probably some IDE drives out there which mimic having 26 sectors per track which ESIX would call "RLL". Bill Bogstad
bill@pyrite.nj.pyramid.com (Bill Pechter) (04/23/91)
In article <1991Apr22.210543.27730@thyme.jpl.nasa.gov> kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) writes: >In article <1991Apr21.155642.1586@shambala.uucp> kentkar@shambala.uucp (Kent Karrer) writes: >>It is nice to see a unix vendor offering an upgrade to R4.0 at a reasonable >>cost. But does ESIX still not support RLL disk controllers? >> > >The myth that ESIX doesn't support RLL controllers is a bit of marketing >hype. ESIX documentation states unequivocally that ESIX does support >RLL, and I can unequivocally state that both 5.3.2.C and 5.3.2.D both >support RLL very nicely. > But when I call them and ask if it'll run with my Perstor controller they refuse to say it will. I can't see laying out the money for a copy of Unix that may not work on my machine. If they could tell me that it works the check would be in the mail today. Bill -- Bill Pechter | "The postmaster always pings twice." Pyramid Technology | bill@pyrite.nj.pyramid.com 10 Woodbridge Center Drive | rutgers!pyrnj!pyrite!bill Woodbridge, NJ 07095 (908)602-6308 | pyramid!pyrnj!pyrite!bill
bill@pyrite.nj.pyramid.com (Bill Pechter) (04/23/91)
In article <3080@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes: > >How can ESIX even know whether the controller uses RLL? How can >anybody find this out without ripping the disk apart and analyzing the >bit-patterns stored on the platter? If there's more than the standard number of MFM sectors per track -- you lose. RLL does 25, ERLL (Perstor) does 31... So if the driver expects 1-17 only... you may not see your full disk sizes (at best). Bill -- Bill Pechter | "The postmaster always pings twice." Pyramid Technology | bill@pyrite.nj.pyramid.com 10 Woodbridge Center Drive | rutgers!pyrnj!pyrite!bill Woodbridge, NJ 07095 (908)602-6308 | pyramid!pyrnj!pyrite!bill
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) (04/23/91)
In article bill@pyrite.UUCP (Bill Pechter) writes: >In article I wrote: >>In article kentkar@shambala.uucp (Kent Karrer) writes: >>>It is nice to see a unix vendor offering an upgrade to R4.0 at a reasonable >>>cost. But does ESIX still not support RLL disk controllers? >> >>The myth that ESIX doesn't support RLL controllers is a bit of marketing >>hype. ESIX documentation states unequivocally that ESIX does support >>RLL, and I can unequivocally state that both 5.3.2.C and 5.3.2.D both >>support RLL very nicely. > >But when I call them and ask if it'll run with my Perstor controller they >refuse to say it will. I can't see laying out the money for a copy of >Unix that may not work on my machine. If they could tell me that it works >the check would be in the mail today. I didn't say anything about ARLL, which is what the Perstore is. ESIX Rev C didn't work with the Perstore. I haven't tried Rev D yet. -- Kaleb Keithley kaleb@thyme.jpl.nasa.gov Meep Meep Roadrunner Veep veep Quayle
aland@informix.com (Colonel Panic) (04/24/91)
In article <512@pyrite.nj.pyramid.com> bill@pyrite.UUCP (Bill Pechter) writes: >In article <1991Apr22.210543.27730@thyme.jpl.nasa.gov> kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) writes: >>The myth that ESIX doesn't support RLL controllers is a bit of marketing >>hype. ESIX documentation states unequivocally that ESIX does support >>RLL, and I can unequivocally state that both 5.3.2.C and 5.3.2.D both >>support RLL very nicely. > >But when I call them and ask if it'll run with my Perstor controller they >refuse to say it will. I can't see laying out the money for a copy of >Unix that may not work on my machine. If they could tell me that it works >the check would be in the mail today. > >Bill Pechter This isn't a fair criticism. What ESIX is really saying by "refusing to say that (insert nonstandard controller name here) will" work is that they don't include that particular hardware as part of their test procedure, so they don't want to make any claim about the compatibility of any vendor whose hardware they have not tested for compatibility. I can't remember if Perstor is a caching controller or a compressing/reconfiguring one, but the similar principle applies regardless. If the *hardware* vendor claims that they are "100% compatible with X", that doesn't necessarily mean that the software vendor can take that at face value. (Boy, could I tell you some horror stories... BIG NAME companies don't even get this right always.) The way I'd look at it is this: if the *hardware* vendor is making compatibility claims, and they are willing to back such claims with a no-fault return policy, fine. But if you encounter problems with hardware that the o/s vendor doesn't claim to support (and lacks the means to test in-house), it's hardly fair to blame the o/s vendor. If the problem doesn't reproduce in a supported configuration, there's not a whole lot that they can do. For example: let's say somebody's using a DPT caching controller without a UPS and the power goes out. The resulting corruption is severe enough to thoroughly trash your database (on a raw partition) and a couple of file systems beyond easy repair. Now, in their ads, DPT claims "100% compatibility" with WD1003 interfaces, and the WD1003 is a supported controller. Is it ESIX's fault that your data is trashed? -- Alan Denney aland@informix.com {pyramid|uunet}!infmx!aland I says, "Earl, this hill can spill us you better slow down or you're gonna kill us just make one mistake, and it's the Pearly Gates for them 85 crates of U.S.D.A.-approved cluckers. You wanna hit second gear, please?" -- 'C. W. McCall', "Wolf Creek Pass"
brian@bjm.wimsey.bc.ca (brian) (04/24/91)
kaleb@thyme.jpl.nasa.gov (Kaleb Keithley) writes: >The myth that ESIX doesn't support RLL controllers is a bit of marketing >hype. ESIX documentation states unequivocally that ESIX does support >RLL, and I can unequivocally state that both 5.3.2.C and 5.3.2.D both >support RLL very nicely. I think the issue here is that too many yahoos (myself included) put "MFM" manufactured drives on an RLL controller. I really don't see any problem doing this as long as one realizes that they can't phone ESIX and whine when a drive gets lottsa bad sectors and loses info. BTW the drives I have on RLL are a real RLL and a 20 meg miniscribe MFM (getting me 30 meg on RLL) and the MFM drive is more reliable (in terms of constant sector remapping) than the RLL drive. Brian -- __________ ___ ____ _________________________________________________ / / / /| /| (604)520-3808 uunet!van-bc!bjm!brian /--: / / | / | New Westminster B.C. _______ /__/ /__/ / |/ | _________________________________________________
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (04/25/91)
I wrote:
How can ESIX even know whether the controller uses RLL? How can
anybody find this out without ripping the disk apart and analyzing
the bit-patterns stored on the platter?
Bill Pechter writes:
If there's more than the standard number of MFM sectors per track
-- you lose. RLL does 25, ERLL (Perstor) does 31... So if the
driver expects 1-17 only... you may not see your full disk sizes
(at best).
Which sort of answers the question, but not really. There is no such
thing as "the standard number of MFM sectors per track." Perhaps there
is such a thing as "many disk drives use 17 sectors per track, and many
more don't."
The following is directed not towards Bill, but towards many Usenet
users who assume that RLL is some sort of disk interface standard.
It's not! It's just a way of putting bit patterns on the disk
surface. And it wasn't invented by Adaptec either. RLL means "run
length limited" -- a way of recording bits such that you never have
more than m consecutive raw ones or n consecutive raw zeroes. Tape
drives have used it for years (but they call it GCR or group code
recording). In the microcomputer world, the Apple II used it on floppy
disks way back when.
I still don't see how ESIX (or any other operating system) can find out
whether the the controller uses RLL. I can see that an operating
system might not support a certain number of sectors per track, but
that has only a very nebulous relationship to the recording format
used, other than that formats denser than MFM yield more sectors per
track.
Perhaps Usenet posters ought to be saying "ESIX requires no more than
17 sectors per track" (if that is true, which it probably is not,
because the disk off which I run ESIX has more than 17 sectors per
track) instead of blaming it on the recording format.
Better, still, say something like "ESIX doesn't support my disk
controller, and it happens to use RLL recording, but the recording
format many or many not have something to do with it."
--
Rahul Dhesi <dhesi@cirrus.COM>
UUCP: oliveb!cirrusl!dhesidavid@kessner.denver.co.us (David Kessner) (04/25/91)
In article <3087@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes: >I still don't see how ESIX (or any other operating system) can find out >whether the the controller uses RLL. I can see that an operating >system might not support a certain number of sectors per track, but >that has only a very nebulous relationship to the recording format >used, other than that formats denser than MFM yield more sectors per >track. You might no be able to see if the drive is RLL, but it is obviously possible. Not only does my ESIX figure the thing out, but so do many other MS-DOS programs like Speed-Stor, Nortons, and several other things. >Perhaps Usenet posters ought to be saying "ESIX requires no more than >17 sectors per track" (if that is true, which it probably is not, >because the disk off which I run ESIX has more than 17 sectors per >track) instead of blaming it on the recording format. > >Better, still, say something like "ESIX doesn't support my disk >controller, and it happens to use RLL recording, but the recording >format many or many not have something to do with it." When I talked to ESIX tech support when I bought ESIX, they said something on the order of this, "It's not that we don't support RLL. But rather that we have only tested it with the Western Digital 1006-SR2 RLL controller and we don't guarentee that anything else will work. We've heard that the Adaptec controller works but we have not tried it ourselves." The Perstor controller is strange (even by RLL terms). I have tried to steer clear of them since I have heard that they have compatability problems even under anything but plain MS-DOS. I don't usderstand all this talk about ESIX not supporting RLL. It does. Works great. -- David Kessner - david@kessner.denver.co.us | do { 1135 Fairfax, Denver CO 80220 (303) 377-1801 (p.m.) | . . . If you cant flame MS-DOS, who can you flame? | } while( jones);
kentkar@shambala.uucp (Kent Karrer) (04/25/91)
In article <3087@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes: > >I wrote: > > How can ESIX even know whether the controller uses RLL? How can > anybody find this out without ripping the disk apart and analyzing > the bit-patterns stored on the platter? > >Bill Pechter writes: > > If there's more than the standard number of MFM sectors per track > -- you lose. RLL does 25, ERLL (Perstor) does 31... So if the > driver expects 1-17 only... you may not see your full disk sizes > (at best). > >Which sort of answers the question, but not really. There is no such >thing as "the standard number of MFM sectors per track." Perhaps there >is such a thing as "many disk drives use 17 sectors per track, and many >more don't." > >The following is directed not towards Bill, but towards many Usenet >users who assume that RLL is some sort of disk interface standard. >It's not! It's just a way of putting bit patterns on the disk >surface. And it wasn't invented by Adaptec either. RLL means "run >length limited" -- a way of recording bits such that you never have >more than m consecutive raw ones or n consecutive raw zeroes. Tape >drives have used it for years (but they call it GCR or group code >recording). In the microcomputer world, the Apple II used it on floppy > >I still don't see how ESIX (or any other operating system) can find out >whether the the controller uses RLL. I can see that an operating >system might not support a certain number of sectors per track, but >that has only a very nebulous relationship to the recording format >used, other than that formats denser than MFM yield more sectors per >track. > >Perhaps Usenet posters ought to be saying "ESIX requires no more than >17 sectors per track" (if that is true, which it probably is not, >because the disk off which I run ESIX has more than 17 sectors per >track) instead of blaming it on the recording format. > >Better, still, say something like "ESIX doesn't support my disk >controller, and it happens to use RLL recording, but the recording >format many or many not have something to do with it." >-- Well, maybe. But about 18 months ago, I asked the people at ESIX to send me some product brochures. Within the body of their brocures they specifically mentioned that they DO NOT support RLL disk controllers. I also have product brochures from other vendors of unix. They specifcally point out that they do support RLL. Perhaps it is technically incorrect to refer to RLL as a standard of some type however, experience with software seems to indicate to me that someone somewhere within the microcomputer community has accepted it as a "defacto" standard and therefore I must give it serious consideration when choosing what software I purchase. -- [~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~] [ A GREAT DEAL OF CHAOS IN THE WORLD occurs because people don't appreciate ] [ themselves. -- Chogyam Trungpa ] [ "SHAMBHALA - The Sacred Path of the Warrior" ] [___________________uunet!seaeast.wa.com!shambala!kentkar___________________]
bill@pyrite.nj.pyramid.com (Bill Pechter) (04/25/91)
In article <3087@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes: > >I wrote: > > How can ESIX even know whether the controller uses RLL? How can > anybody find this out without ripping the disk apart and analyzing > the bit-patterns stored on the platter? Once again, (no flame intended) all the MFM controllers I've seen use no more than 17 sectors per track. All the RLL, ARLL, and other types use more than 17. So Esix has no way of knowing how you encode the data on the disk... it does expect up to 17 sectors/track on standard PC controllers for ST412/506 controllers. The method of writing bit patterns is totally hidden from the OS. That IS a controller function. You're correct. However, they're very careful to say that they don't support anything other than MFM type ST412/506 controllers. They are just saying buyer beware to all of us with non WD1002/3 type controllers for ST412 drives. I'm checking with Perstor about my controller revs and it's suitability with ESIX. Bill -- Bill Pechter | "The postmaster always pings twice." Pyramid Technology | bill@pyrite.nj.pyramid.com 10 Woodbridge Center Drive | rutgers!pyrnj!pyrite!bill Woodbridge, NJ 07095 (908)602-6308 | pyramid!pyrnj!pyrite!bill
pjh@mccc.edu (Pete Holsberg) (04/26/91)
In article <3087@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes:
=The following is directed not towards Bill, but towards many Usenet
=users who assume that RLL is some sort of disk interface standard.
=It's not! It's just a way of putting bit patterns on the disk
=surface. And it wasn't invented by Adaptec either. RLL means "run
=length limited" -- a way of recording bits such that you never have
=more than m consecutive raw ones or n consecutive raw zeroes. Tape
In fact, what we call RLL here is actually only one of many possible RLL
schemes. I believe that the "proper" name is "RLL 2,7." And if I
haven't lost too many brain cells, I think I recall that MFM is RLL 1,3.
Pete
--
Prof. Peter J. Holsberg Mercer County Community College
Voice: 609-586-4800 Engineering Technology, Computers and Math
UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690
Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91jon@turing.acs.virginia.edu (Jon Gefaell) (04/27/91)
In article <3087@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes: > >The following is directed not towards Bill, but towards many Usenet >users who assume that RLL is some sort of disk interface standard. >It's not! It's just a way of putting bit patterns on the disk >surface. And it wasn't invented by Adaptec either. RLL means "run >length limited" -- a way of recording bits such that you never have >more than m consecutive raw ones or n consecutive raw zeroes. Tape >drives have used it for years (but they call it GCR or group code >recording). In the microcomputer world, the Apple II used it on floppy >disks way back when. for that matter, ST412/506 interface, MFM drives utilize RLL encoding. The diferences are in the 'types'(number of zeros allowed?) of RLL encoding used. Is this correct? -- ____ \ / \/ The pleasure of satisfying a savage instinct, undomesticated by the ego, is uncomparably much more intense than one of satisfying a tamed instinct. The reason is becoming the enemy that prevents us from a lot of possibilities of pleasure. S. Freud
jon@turing.acs.virginia.edu (Jon Gefaell) (04/27/91)
In article <1991Apr25.200115.12310@mccc.edu> pjh@mccc.edu (Pete Holsberg) writes: >In article <3087@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes: >=The following is directed not towards Bill, but towards many Usenet >=users who assume that RLL is some sort of disk interface standard. >=It's not! It's just a way of putting bit patterns on the disk >=surface. And it wasn't invented by Adaptec either. RLL means "run >=length limited" -- a way of recording bits such that you never have >=more than m consecutive raw ones or n consecutive raw zeroes. Tape > >In fact, what we call RLL here is actually only one of many possible RLL >schemes. I believe that the "proper" name is "RLL 2,7." And if I >haven't lost too many brain cells, I think I recall that MFM is RLL 1,3. > >Pete >-- >Prof. Peter J. Holsberg Mercer County Community College >Voice: 609-586-4800 Engineering Technology, Computers and Math >UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 >Internet: pjh@mccc.edu Trenton Computer Festival -- 4/20-21/91 Exactly! and 34 sectors is yielded by 3,9 RLL encoding. -- ____ \ / \/ The pleasure of satisfying a savage instinct, undomesticated by the ego, is uncomparably much more intense than one of satisfying a tamed instinct. The reason is becoming the enemy that prevents us from a lot of possibilities of pleasure. S. Freud
emanuele@overlf.UUCP (Mark A. Emanuele) (04/27/91)
In article <513@pyrite.nj.pyramid.com>, bill@pyrite.nj.pyramid.com (Bill Pechter) writes: > In article <3080@cirrusl.UUCP> Rahul Dhesi <dhesi@cirrus.COM> writes: > > > >How can ESIX even know whether the controller uses RLL? How can > >anybody find this out without ripping the disk apart and analyzing the > >bit-patterns stored on the platter? > > If there's more than the standard number of MFM sectors per track -- you lose. > RLL does 25, ERLL (Perstor) does 31... So if the driver expects 1-17 only... > you may not see your full disk sizes (at best). > For all it's bad points, SCO DOES support all kinds of ODD Hard disks. That's one of the reasons I still use it. - -- Mark A. Emanuele V.P. Engineering Overleaf, Inc. 218 Summit Ave Fords, NJ 08863 (908) 738-8486 emanuele@overlf.UUCP
jamesd@techbook.com (James Deibele) (04/28/91)
In article <1991Apr21.155642.1586@shambala.uucp> kentkar@shambala.uucp (Kent Karrer) writes: >It is nice to see a unix vendor offering an upgrade to R4.0 at a reasonable >cost. But does ESIX still not support RLL disk controllers? From the back of the R4 brochure: "supports different kinds of hard drives including SCSI, ESDI, IDE, RLL, and MFM interface" I haven't seen a "Certified Hardware Compatibility" brochure since the one they released for R3.2 in October, 1990, but I would assume the popular (Seagate, Miniscribe, etc.) manufacturers would be certified. -- Voice: +1 503 646-8257 FAX: +1 503 248-6320 jamesd@techbook.com - or - Public Access UNIX site: +1 503 644-8135 ...!uunet!techbook!jamesd Authorized SCO and ESIX resellers.
nlane@well.sf.ca.us (Nathan D. Lane) (04/29/91)
I use Esix 3.2 and have two 68 MB Toshiba RLL drives - Esix DOES support RLL drives - it says so right in their documentation and I am living proof that they do support RLL. If you're asking about Perstor RLL, that's a different story (Perstor is ARLL). The standard 7,1 RLL with 26 sectors per track works just fine in Esix 3.2... -Nathan Lane Digital Technology Service, Santa Barbara Authorized Esix Reseller nlane@well.sf.ca.us
wes@harem.clydeunix.com (Wes Peters) (05/02/91)
In article <3087@cirrusl.UUCP>, dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > Perhaps Usenet posters ought to be saying "ESIX requires no more than > 17 sectors per track" (if that is true, which it probably is not, > because the disk off which I run ESIX has more than 17 sectors per > track) instead of blaming it on the recording format. > > Better, still, say something like "ESIX doesn't support my disk > controller, and it happens to use RLL recording, but the recording > format many or many not have something to do with it." In reality, the question has nothing to do with RLL or MFM encoding, it has to do with whether or not the OS supports a particular type of controller. The OS needs to know a lot of information about a disk controller, including where it's registers are located in the memory map, what interrupt it is using, formats of the Command/Status Register, what DMA channel if applicable, etc. Esix publishes a list of hardware they are compatible with; get a copy of the list. If your disk controller isn't on there, find out if any that ARE on the list work with your drives and buy a new disk controller, or find out if another V/386 supports your disk controller and buy it instead (this will probably be more expensive than replacing the disk controller). Wes Peters -- #include <std/disclaimer.h> The worst day sailing My opinions, your screen. is much better than Raxco had nothing to do with this! the best day at work. Wes Peters: wes@harem.clydeunix.com ...!sun!unislc!harem!wes