scotty@l5comp.UUCP (Scott Turner) (10/01/88)
Well, it seems I am no alone in my feelings that the W.G.E. and Microport's System V/386 make a great combo (the E-Mail runneth over.) Microport's unix may be for the whimps who demand support from their unix vendor, but with the trouble I've had with Bell Tech on software issues I'll gladly be classified as a whimp at this point. :) First step to happiness with the W.G.E. under Microport: Sanity check, can you even USE the W.G.E. card? That isn't as silly as it sounds. The driver supplied for the card maps the 82786's registers into memory so they can be accessed rapidly and easily. But if your system has a SRAM cache you may be in for a VERY nasty surprise! And remember, Bell only sells it's software to people with the "Right Stuff". The fact you are trying to use their card with Microport labels you a "whimp". So you won't be getting any SOFTWARE support from them. (You should get excellent HARDWARE support though, the hardware people at Bell don't seem to care if you're a "whimp" or not. :) So if your system has a cache you'd best think long and hard before laying out the long green for this card, once you've seen that 19" tube it may be a tad painful to give it up for Bell's cheerful refund. If you are using the Mylex 386 motherboard there is a solution for it at least. Call Mylex at (800) 446-9539 and ask for sales. Be prepared to call back several times as their sales people can be hard to get hold of (ie they may or may not call back depending on how snowed under they are that day.) What you want is the Computone PAL. It costs $15. What this little gem does is turn off the SRAM cache for the top 2 meg of memory. This allows the Bell Tech driver to work properly. (If you can't get one from Mylex drop a E-Mail to mylexpal@l5comp and we'll see if we have one hanging around, but no promises.) [While you have 'em on the line you may want to ask them what other PALs they have, for example they have an Adaptec ACB2322 "tune up" PAL...] If you aren't using the Mylex motherboard then you'd best consult with the manufacturer of your motherboard and see if their cache caches accesses above 14meg. If it does you're screwed unless they have some way of turning caching off up there (unless you just want to turn caching off for ALL of memory...) And once again remember, this is a SOFTWARE issue for Bell Tech because to fix it will call for a patch to the driver not the hardware. Thus their "Right Stuff Customer" policy is in full effect, so don't expect help from them if you can't turn the cache off and you can't afford to buy another motherboard. Also, memory usage goes up quite a bit with all the software you are going to be installing into the kernel. The /unix here is 696,438 bytes long! (and size /unix returns a total memory usage of 893,284!) You WILL need more memory if you don't already have 4 meg. If you have 4 meg you may want more unless you are willing to patch Nbuf to something like 500 in order to free up ram for running programs. The system here had only 1,852,000 bytes left of it's 4 meg until I patched Nbuf. The problem is that at 1660x1200 an 8 bit per pixel image takes 1,992,000 bytes and system performance gets a bit sluggish if you don't have enough core. And no, the card can't display 8 bits per pixel at 1660x1200 but the outbitmap program can dither that size image and display it, and BOY do they look neat! (We've been scaling GIF pictures to 1660x1200, but more on that at a later date) Still looking OK? Well the X10R4 driver needs a mouse. It is hardwired to use the asy driver. Even if you have a big fancy smart serial card with 16 ports on it you will have to plug a Logitech serial mouse into tty00. You CAN modify the driver to use tty01, but that's it. mknod'ing /dev/tty00 to be something else won't do anything, the driver uses kernel (or is it carnal) knowledge to get right at the asy driver. It doesn't give a hoot for /dev/tty00. If you have other plans for either serial port you're screwed. The supplied driver doesn't use anything except a Logitech serial mouse, with three buttons mind you, plugged into either serial port. Buss mice need not apply. And don't forget to order that mouse! It doesn't come with the card and X windows is damn near useless without it. (X doesn't seem to have a "No pointing device/use keyboard" setup option) You'll need the C7 version of the Logitech serial mouse, costs around $86. Don't get that new 2 button, MUCH cheaper, mouse by mistake (or design, you'll want all three buttons.) Don't forget a mouse pad, they extend the life of the little teflon pads on the bottom of the mouse quite nicely. Second step: Call Bell Tech and DEMAND the same set of disks that were shipped to L5 Computing. The serial number off the disks here is: 1.2-042588. There are 10 disks that count and the DOS demo "frisbee" disk (for a total of 11 disks.) Why not get the latest? Well, I've gotten several interesting mail messages that seem to indicate Bell has been fooling around with the disks. Lord only knows what they've done to them, the above disks contain software that I know works with the Microport System V/386 2.2 and System V/386 3.0e and DOSMerge 386 1.1. If I can confirm that later versions of their software work I'll post a message with all the details. (So far trying to get updates out of Bell has been like trying to seperate them from their children) Third step: Get the X10R4 tape. The disks sent here by Bell Tech were not complete. Fonts like vtsingle and timrom12 are missing (among a PILE of other fonts.) Tools are missing as well, like the bitmap editor they show in their huge glossy advertizing sheet. (They did send the stunning Nagel bitmap along though :) Life with X10R4 got much easier since we now have ALL the dox as well, Bell supplies tools with no dox on how they work with the above set of disks. If you absolutely can't come up with X10R4 send an E-Mail to x10r4@l5comp and perhaps we can work something out. If demand is great enough maybe we can setup a disk/tape service to provide the bits at cost. Fourth step: Install all the '386 unix software that Microport sells. :) Actually you can skip their Text Preparation package if you wish to use something more useful like the ELAN stuff. But you WILL want an equ, tbl, and nroff/troff so you can make human readable versions of the X documentation. What little Bell supplies comes only in the unprocessed form. If you plan to use DOSMerge make sure it is installed at this time as well. And the NSE package is NOT optional. It MUST be installed before proceeding. You must also install the link kit. And if you plan on providing yourself with the missing X tools you will need the software development system. And don't forget the order of installation: Runtime Software Development Text preparation Link Kit NSE DOSMerge 386 And don't forget to call Microport customer service and request the crypt disk, but only if you're a site located in the good ol' U.S. of A. Dirty aliens will have to write their own. :) I've found a useful X tool that needs crypt access and you'll need this disk if you want to compile it as well. Once all of the above software is installed I'd suggest doing a sanity check. Especially if your system is at all "Bleeding edge". I've found that if the system is going to have a blow out and eat the hard drive it will do it sometime within the first 4 days after installation. I strongly urge you to make sure your unix is running fine for at least 4 days before proceeding if you have ESDI and/or DOSMerge 386. And don't just let it sit there, use it. I suggest compiling GNU Emacs, this seems to bring out any beasties faster than anything else we've tried. And has the side advantage of installing a great editor. (Which has nice X support unlike vi) Fifth step: NOTE: Do not skip step three, without the fonts vtsingle and timrom12 the X10R4 will NOT work as advertized in the Intro to X manual. If you're REAL impatient to get underway send a mail message to xfonts@l5comp and someone here will send you the missing font files via return E-Mail free of charge. If you have the disks we got then you can follow the instructions on the label and use the sysadm program, NOT pkginstall(!), to install the X window software. WARNING: If you DO NOT have the exact disks we received you may DAMAGE your link kit! If you aren't sure then make a quick backup of your link kit as follows: (as super user do the following:) mkdir /etc/saveconf cd /etc/atconf find . -print | cpio -pdmau /etc/saveconf Next edit the file /etc/atconf/systems/system.std and make the following changes to it: Change the line cpyrt * Copyright notice "drive"r to cpyrt, * Copyright notice "drive"r and add the following right after that line: * * Manticore, Inc. X5 drivers xptc, * Control side of X5 pseudo tty driver xpts, * Slave side of X5 pseudo tty driver btb, * Bell Tech Blit Express driver btbs, * Bell Tech Blit Express streams driver conx * X5 console driver At the very end of the file add the following: * * Manticore, Inc. X5 driver defines NBLK4 = 100 NBLK16 = 100 NBLK64 = 100 NQUEUE = 196 NSTREAM = 64 Then type mkunix and sit back for awhile. Once the new unix is built SAVE YOUR OLD /unix! (My personal favorite method is ln /unix /unixnox and I also keep a /unixx around so I can take my pick at bootup) Then install the new unix as /unix. If you don't like those nasty messages during shutdown then install the new unix as /unixx, shutdown -g1, and enter /unixx during boot up, once booted ln /unixx /unix. Now, unpack that X10R4 and copy the fonts vtsingle and all the timrom fonts into /usr/new/lib/X/font. Next cd /usr/new/bestofimages and issue sh ./unpack.sh. Next edit the script file that sets your PATH environment variable. (For sh users this will be .profile for csh .cshrc) Add /usr/new into your path right after /usr/bin. Now would be a GREAT time to pop a DC600A into yer Everex and make a backup. I only say that because it's the right thing to say, not because I did. ;) Sixth step: Drink something you like, 2 liter bottle of classic Coke for example. We're about to enter the "Dave, don't you think we should talk about this" zone. An error in this next step and you can screw yourself and but good. Shutdown your system (cd /;shutdown -g1) and break out the screwdriver. If you have a Mylex 386 now is the time to put the Computone PAL in. Locate the BIOS EPROMs, then scan right, in between the rightmost slot and the next to the rightmost slot you will find the PAL to be replaced. You may need to remove cards to do this, if so do it! Don't try and do it without removing the cards, if you screw that PAL up you're going to be kicking yourself because that 19" monitor is going to be sittin' there lookin' at you and you'll be thinkin' "Gee, just how BIG will the pictures be?!!?" We've had two W.G.E. cards through here so far. Both of them generate heat like a hot plate. It's all those fast PALs and ECL chips. I suggest you carefully consider which slot you put this card into. Putting it into a slot that has a half card to the right (like maybe a half slot Hercules clone monitor card :) is a win. Putting an auxillary fan in the case in front of the card isn't a bad idea either. :) If you think I'm kidding, just remember that the video clock rate on this sucker in 160MHz! And the cooler you keep chips the longer they last. And just so you know HOW hot this thing gets, the ones here have been capable of heating up boards two slots away when the fan isn't running... I heartily suggest you check the board after it's been running for a day to see that it isn't getting too hot. Once installed put everything back together and plug in that huge monitor. Power sequencing isn't important if you selected the onboard -5v option (factory default), otherwise you will need to turn the monitor on first. Turn the system on. If you have a later model W.G.E. with the onboard EPROMs you should see the monitor turn on and start displaying stuff shortly. Most BIOS' write directly to the screen so don't panic if some text shows up on the little screen and not on the big one. In any case you pretty much ignore the big monitor for now. Boot up the new unix (/unix or /unixx depending on what you did) and login. Gather everyone around and type xinit. Almost instantly you should see the screen be covered with a large grey box. It should be roughly 1" in from the edges of the monitor on all 4 sides. Depending on how powerful you system is it may take a few seconds for the mouse cursor to appear and a window to pop up. If on the other hand xinit dies after a few seconds and complains that the card wasn't ready then you need to recheck whatever it was you did to turn the cache off. If xinit runs without stopping, but all you see on the monitor is a single line, with every other pixel turned on, running down the righthand side of the screen. Your card is dead, call Bell for hardware support. They'll connect you with a person that will ask you for your customer number, card serial number, and will take down the symptoms. She will then schedule a tech to call you back, or she may call you back later to just plain ol' issue you an RMA number if the tech is confident the card is screwed without needing to talk to you. The one time we've had to return the card we shipped it down UPS Red and they shipped another card back out the same day they got it in via Federal Express Standard Delivery (2 day service.) They were quick, pleasant, and no-nonsense. Dealing with the hardware arm of Bell Tech has been MUCH more fun than the software arm. If you managed to get vtsingle and timrom12 you should now be able to type uwm& and get a beep rather than an error message. Next, go have fun with the demos! Be warned that some of the demos listed in the Intro to X manual are NOT supplied. For example the parrot, whatever it is, isn't supplied and I haven't run across it in the X10R4 tape either. (So don't drop an E-Mail to parrot@l5comp asking for it ;) Seventh step: At this point pat yourself on the back and have fun with X10R4 until X11 is released by Bell Tech. Pray that getting the X11 update is easier than trying to get an X10R4 update (I've been trying for over a MONTH now and still haven't gotten their latest X10 hence why I can't say yes/no about their latest code working under Microport.) You will find that the stock X10R4 makefiles need updating to work under Bell's X10R4. Whenever you link you will need to add -lnsl_s to get the streams library added in. Currently they don't have an x_s which is a shame since just about anything needing to use X will thus be over 100K long in final size due to the size of the X library. A project for the use of that X10R4 source code you say? I'd agree but with X11 promised any day now it seems silly to make a shared X10 library at this point. Let's just hope they supply a shared X11 lib. Well that's it for now. If the above steps give you the W.G.E. running under Microport then great! I think you'll grow to love this card. If things still aren't humming then you haven't followed my directions EXACTLY enough. I do have the W.G.E. running X10R4 under Microport so it can be done. I think the trickest step is in getting Bell Tech to part with the same set of disks as they sent here. If you get link errors while building the unix, and you followed the instructions on making a system.std, then this is your most likely problem. Can we send you copies of the disks here? You'll have to bug Bell about that not us. If Bell calls me and says it's OK to send a copy of the disks to someone then we'll be happy to do so. But I run a tight shop here and there will be NO Bell Tech code leaving here without Bell's say-so. One note to DOSMerge 386 users, the DOSMerge here doesn't seem to like running in xterm windows with more than 25 lines. Be careful because it gets so tangled up you have to kill the xterm in order to recover, <esc> ctrl-K hasn't worked here as a recovery (which I find HIGHLY interesting.) Also, there is NO support for Herc, CGA, or EGA emulation (another reason to keep the "Twin Head" configuration.) Also, we are NOT a retail outlet for Bell Tech. If you want to buy the card call Bell Tech. Currently I can't get a straight answer out of them about dealer pricing, and even if I could we're into chasing vertical markets not retail customers. Scott Turner scotty@l5comp -or- uunet!l5comp!scotty "We need more machine guns, we can't run the mines without them." -Anonymous american mine owner, 1918
terry@eecea.eece.ksu.edu (Terry Hull) (10/04/88)
In article <438@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: > >Sanity check, can you even USE the W.G.E. card? > >That isn't as silly as it sounds. The driver supplied for the card maps >the 82786's registers into memory so they can be accessed rapidly and >easily. But if your system has a SRAM cache you may be in for a VERY >nasty surprise! I have a Xenix system and now that streams is available for it I was going to get the WGE card. I have an Intel Inboard/386 with a cache. Since it has a mixture of 16 and 32 bit memory, it would be very slow without the cache. Does this mean that I am doomed to no cache if I want to use the WGE? Bell Tech, do you have anything to say on this point? Also when are we going to see X11 for this board? -- Terry Hull Department of Electrical and Computer Engineering Kansas State University INTERNET: terry@eecea.eece.ksu.edu Manhattan, KS 66502 UUCP: {pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!eecea!terry
dave@micropen (David F. Carlson) (10/05/88)
In article <428@eecea.eece.ksu.edu>, terry@eecea.eece.ksu (Terry Hull) writes: > In article <438@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: > >Sanity check, can you even USE the W.G.E. card? > > > >That isn't as silly as it sounds. The driver supplied for the card maps > >the 82786's registers into memory so they can be accessed rapidly and > >easily. But if your system has a SRAM cache you may be in for a VERY > >nasty surprise! I have used machines with several caching schemes (Intel chips and Everex proprietary) and they always cache only memory they known about: main mother board memory. If a device has a memory map in the AT bus structure *it* must provide the dual port as there is no bus sharing per se in the AT bus. Therefore, the WGE has dedicated space in the device memory range, 0xc0000-> 0xdffff nearby the other major device memory: your graphics memory space. No caching is done of these areas or no polling IO would ever succeed. (I'm pretty sure it does. :-) DOS is no different from UNIX in this regard.) -- David F. Carlson, Micropen, Inc. micropen!dave@ee.rochester.edu "The faster I go, the behinder I get." --Lewis Carroll
ipc@drexel.UUCP (Image Processing Center) (10/09/88)
In article <428@eecea.eece.ksu.edu>, terry@eecea.eece.ksu.edu (Terry Hull) writes: > In article <438@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: > > > >Sanity check, can you even USE the W.G.E. card? > > > >That isn't as silly as it sounds. The driver supplied for the card maps > >the 82786's registers into memory so they can be accessed rapidly and > >easily. But if your system has a SRAM cache you may be in for a VERY > >nasty surprise! Terry Hull writes > I have a Xenix system and now that streams is available for it I was > going to get the WGE card. I have an Intel Inboard/386 with a cache. > Since it has a mixture of 16 and 32 bit memory, it would be very slow > without the cache. Does this mean that I am doomed to no cache if I > want to use the WGE? > -- There should be absolutely no problem with the INBOARD, since the INBOARD the ideal arrangement: The ending address for caching is set by switches on the card. Typically, one sets them for the end of physical memory, while dual ported and memory mapped registers are addressed above this. I have checked this point out with INTEL technical support: the INBOARD is completely compatible with cards like the W.G.E. because the cache does not function above the end address. Please post your results Terry - I'd realy like to know if you get X up on XENIX. Are they offering V11 yet?
scotty@l5comp.UUCP (Scott Turner) (10/09/88)
In article <554@micropen> dave@micropen (David F. Carlson) writes: >In article <428@eecea.eece.ksu.edu>, terry@eecea.eece.ksu (Terry Hull) writes: >> In article <438@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: >> >easily. But if your system has a SRAM cache you may be in for a VERY ^^^ Please note! >> >nasty surprise! > >I have used machines with several caching schemes (Intel chips and Everex >proprietary) and they always cache only memory they known about: main mother >board memory. If a device has a memory map in the AT bus structure *it* must Well I'm glad at least a few companies are on the ball. It did cross my mind that it would have been smarter for Mylex to only cache ram that the BIOS POST found during startup, but alas the cacheable memory size in the Mylex design is cast into a PAL. If Mylex designed their cache in this fashion so can others. And then again others can get it right. Hence the phrase "may be in" in my warning. Rather than something more concrete like "We're all screwed, run for the hills!" ;) I will also note that Bell gave me no such warning about caches. I am trying to save others from a nasty surprise. >No caching is done of these areas or no polling IO would ever succeed. >(I'm pretty sure it does. :-) DOS is no different from UNIX in this regard.) Are you confirming that the Everex boards, and those based on the Intel cache controller, do work with the WGE right out of the box? (Your posting was a little hard for me to understand.) Scott Turner scotty@l5comp -or- uunet!l5comp!scotty
scotty@l5comp.UUCP (Scott Turner) (10/09/88)
My posting has generated a small wave of E-mail, a couple phone calls, and
a diskette mailer.
First for the non-Bell generated E-Mail and all the phone calls (Bell hasn't
called to my knowledge.)
There are alot of people out there that are a bit frustrated with Bell over
Bell's support of the W.G.E. Two people related how Bell tech support people
would hang up on them at the mention of the M-word. (I'll say it again guys
and gals, don't tell 'em you're "whimps" when you call!) My favorite tech
support person, Jennifer "Our driver gets confused by onboard EPROMs", seems
to NOT be the person to talk to if you are a card toting "whimp" and need help.
But there may be a pile of WGE users out there that like Bell's support and
send Jennifer roses. If so I've heard from none of them. I can only report
on what I am told, and insert this disclaimer in the hopes that there are
happy users or singers of praise for Jennifer.
As it stands I have yet to talk to a totally happy Bell WGE customer. I have
great hopes of talking to one someday though. :)
On to more pleasant items...
While Jennifer has done nothing to make me send her roses (unless they're
the gag stem-only variety with a note reading "Rose petals sometimes confuse
flower delivery personel" ;), there is at least one Bell person who seems to
know his/her stuff.
I'd love to heap praise on this person in public, but s/he is net-shy and
requested I not use their name in public postings. (This person is however
most assuredly *NOT* Jennifer)
I'll thus call this person Deep-X in all my net postings.
Pearls of wisdom from Deep-X:
1. X10R4 driver source IS available from Bell. Call your sales person and
have a cashier's check for $10,000 ready.
My thoughts on the $10,000 price tag:
Seeing how simple X10R4 ddx is, and how cheap programmers are ("Send more
machine guns, we can't manage the programmers without them"), it would seem
less expensive to just write your own X10R4 ddx. (In all seriousness, it
looks like a 1 or 2 man month project at most for X10R4. $5K tops, and you
get "free" training of a person to support/upgrade it)
2. X11R? ddx source will probably NOT be generally available.
3. The mouse is dedicated to being on either tty00 or tty01 because the
mouse drive takes over driving the 16450 serial chip!
I guess Bell couldn't get the stock asy driver to work reliably either. ;)
4. The mouse pointer flickers during scrolling because the X10R4 driver
doesn't use the built in hardware bitmap cursor. The 82786 only supports
16x16 bitmaps for the cursor.
It must have been too much trouble to make the driver use the hardware method
for 16x16 bitmaps and bitblt for larger ones, sigh. (One more reason to write
yer own ddx if you care about flickering mouse pointers)
As for the diskettes in the mail...
As I reported on the net, Bell promised to send me a SysVr3.1 upgrade since
it would fix 1. 62 defect limit problem and 2. Include a complete X10R4. But
alas the update came with only the base SysVr3.1, no X.
Well, in Friday's mail they took another stab at it.
Now we have the promised SysVr3.1 X disks, but only two of them! And to
add to the humor of it, this time we only get fonts. Well not quite, a few
other files slipped out the door on these two disks as well. Several programs
we didn't receive before and some more online dox. None of the new pix
Dimitri was hinting at made it either. (Deep-X claims there have been no
updates to the X10R4, but these two disks seem to prove this otherwise 100%
accurate source of information wrong on this topic...)
I'll give them an 'A+' for effort, but I'm afraid a somewhat lower score
for the missing disks. Or maybe the updates are done on a "Double Randomly
Selected Update Disks of the Week Club" basis. In which case I'll give them
an A+ across the board at this point. ;)
The new programs were QUITE useful and we were happy to get them, now if we
can just get the rest of the goods...
When will Bell do something I can be totally happy about? I'm really so damn
close at this point, just something like 8 X10R4 X disks and I'll be happy.
Or maybe they'll meet their promised ship date for X11 and I won't give a
hoot about 8 missing X10R4 disks. (All my other problems have an easy
answer, just get a custom X10R4 ddx...)
On the online System V 386 manual pages that Dimitri announced...
I haven't heard a peep. My offers of money have gone unanswered, mayhaps
they don't have these precious rarities in stock after all? If any vendor
out there has them, and is willing to part with them for under $200, please
drop me an E-Mail. I'll have a cashier's check out to you so fast the ink
won't be dry when you get it. (so be careful when you get it :)
Back to the WGE for the closing.
My words of wisdom for this week for all those unhappy WGE customers out there:
Keep the faith, X11 is supposed to be released next week. Of course that's
based on information from Bell Sales, not Deep-X, but it's a cheery thought
anyway. Hopefully all the confusion of the X10R4 release will be cured by X11.
Scott Turner
scotty@l5comp -or- uunet!l5comp!scottyterry@eecea.eece.ksu.edu (Terry Hull) (10/10/88)
In article <771@drexel.UUCP> you write: >Terry Hull writes > > >> [Stuff about my system deleted] >> -- >There should be absolutely no problem with the INBOARD, since the INBOARD >the ideal arrangement: The ending address for caching is set by switches >on the card. Typically, one sets them for the end of physical memory, >while dual ported and memory mapped registers are addressed above this. >I have checked this point out with INTEL technical support: the INBOARD >is completely compatible with cards like the W.G.E. because the cache >does not function above the end address. > >Please post your results Terry - I'd realy like to know if you get >X up on XENIX. Are they offering V11 yet? Now I am really confused. I talked to Christine Burr at Bell Tech last Thursday and she told me that the WGE would absolutely NOT work with the Inboard. Is there some other problem with the Inboard that causes it not to work with the WGE? Did Christine just hear the word "cache" and say "Oops, this will not work?" Unfortunately, I am doing this on my personal computer budget, and purchasing a $995 card from Bell Tech along with a $500 monitor and having the thing not work would not be acceptable. While I think I could get my money back from Bell Tech, I'm sure the company that I bought the monitor from would not feel the same way. I will be more than happy to post my results to the net when (if) I get X running on XENIX. Unfortunately, it may be a while. The upgrades to 2.3.0 are still not shipping from SCO, and that will be required before I can try. -- Terry Hull Department of Electrical and Computer Engineering Kansas State University INTERNET: terry@eecea.eece.ksu.edu Manhattan, KS 66502 UUCP: {pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!eecea!terry
wes@obie.UUCP (Barnacle Wes) (10/11/88)
In article <283@belltec.UUCP>, dar@belltec.UUCP (Dimitri Rotow) writes: | The cache problem is common to almost all intelligent boards (multiport, etc) | in use on AT bus machines. It's a special problem with display adaptors | with large display memory spaces because performance requirements force you | to map the card's memory somewhere into the AT map. Traditionally, one | chooses the upper part of AT memory under the (fair) assumption that it is | not populated with a full 16MB of RAM. | | The problem is that most cache equipped '386 boxes are designed by DOS houses | and have caches that are only turned off in the 640 to 1024K area used by | common DOS boards. The sensible thing to do (in a box designed for UNIX use | as well as DOS) is to have some means of disabling the cache for accesses | within a given range or above a given address. Many of the higher performance | '386 cache boxes now have that capability. Other companies (for example Dell) | will send you a special PAL that enables cache for a range less than the full | 16 MB address space. A couple of questions about the WGE/Blit card: Do you know if the cache on the Everex Step models or the ALR FlexCache models can be disabled above 14 Meg to work with the WGE? Users with an eye on performance will want to know this. How much real memory is needed (when using the current X10R4 code) to keep the system from paging like mad. I.e., the system should be able to run a couple of csh's or vi's without paging during program execution. -- {hpda, uwmcsd1}!sp7040!obie!wes "How do you make the boat go when there's no wind?" -- Me --
rjg@ruby.TEK.COM (Richard J. Greco) (10/12/88)
In article <446@l5comp.UUCP>, scotty@l5comp.UUCP (Scott Turner) writes: >Pearls of wisdom from Deep-X: > >1. X10R4 driver source IS available from Bell. Call your sales person and >have a cashier's check for $10,000 ready. Actually Bell Technologies did not do the port to the WGE card, this was done by Manticore Inc who owns the source code and as liscenced it to Bell Technologies. The $10,000 price tag is probably Manticore's and not Bell's since this is the pricing I recieved from Manticore. >My thoughts on the $10,000 price tag: >Seeing how simple X10R4 ddx is, and how cheap programmers are ("Send more >machine guns, we can't manage the programmers without them"), it would seem >less expensive to just write your own X10R4 ddx. (In all seriousness, it >looks like a 1 or 2 man month project at most for X10R4. $5K tops, and you >get "free" training of a person to support/upgrade it) I think you are underestimating the difficulty of duplicating Manticore's driver. If you do not do the client to server communication in exactly the same way, you loose all of the clients. The second difficulty here is what you need to duplicate are the routines in the kernel. The user side X process is device independent. It would be extremely difficult to decode the data stream between the kernel and user sides of the kernel without knowing how it is being done. [stuff deleted] >4. The mouse pointer flickers during scrolling because the X10R4 driver >doesn't use the built in hardware bitmap cursor. The 82786 only supports >16x16 bitmaps for the cursor. The real reason for not using the native 82786 cursor is that it is XOR only. Have you ever seen an XOR cursor move across a dither pattern (such as the one X uses for the background of the root window)? It is very easy to loose the cursor in a dither pattern. I can live with the flicker on a cursor I can see. I find playing hunt for the cursor very aggrivating. Just an aside, I am not a completely happy Bell Tech Customer either. We have managed to solve most of our problems ourselves out of necessity. All that happens with their technical support is they record my phone number and promise that someone will call me back. I have yet to receive a return call from technical support. My salesperson has been the only person at Bell who has actually given me after the sale service. -- Richard J. Greco rjg@ruby.TEK.COM {hplabs|uw-beaver|decvax}!tektronix!ruby!rjg "Nonsense! You're only saying that because no one ever has."
james@bigtex.uucp (James Van Artsdalen) (10/12/88)
In article <283@belltec.UUCP>, dar@belltec.UUCP (Dimitri Rotow) wrote: > The sensible thing to do (in a box designed for UNIX use as well as > DOS) is to have some means of disabling the cache for accesses within > a given range or above a given address. Many of the higher > performance '386 cache boxes now have that capability. Other > companies (for example Dell) will send you a special PAL that enables > cache for a range less than the full 16 MB address space. On the System 310 and the System 325 (announced in Canada a week or two ago), one may prevent caching by accessing the address space with the high order bit set in the address. In other words, instead of accessing 0x123456, access 0x80123456. You get the same mapping onto the peripheral bus but no caching. -- James R. Van Artsdalen ...!uunet!utastro!bigtex!james "Live Free or Die" Home: 512-346-2444 Work: 338-8789 9505 Arboretum Blvd Austin TX 78759
scotty@l5comp.UUCP (Scott Turner) (10/12/88)
In article <432@eecea.eece.ksu.edu> terry@eecea..eece.ksu.edu (Terry Hull) writes: >Now I am really confused. I talked to Christine Burr at Bell Tech >last Thursday and she told me that the WGE would absolutely NOT work >with the Inboard. Is there some other problem with the Inboard that >causes it not to work with the WGE? Did Christine just hear the word >"cache" and say "Oops, this will not work?" I know this may seem like a silly point to raise, but the WGE will not work with the Inboard PC since the WGE is a 16 bit card... I'm sure you're using the AT version but I thought I'd bring this point up just to make sure no one in netland gets confused. (You'll note your posting says "Inboard" only, no indication of PC or AT model) Scott Turner scotty@l5comp -or- uunet!l5comp!scotty
fr@icdi10.uucp (Fred Rump from home) (10/12/88)
In article <445@l5comp.UUCP>, scotty@l5comp.UUCP (Scott Turner) writes: < In article <554@micropen< dave@micropen (David F. Carlson) writes: < >In article <428@eecea.eece.ksu.edu>, terry@eecea.eece.ksu (Terry Hull) writes: < >< In article <438@l5comp.UUCP< scotty@l5comp.UUCP (Scott Turner) writes: < >< >easily. But if your system has a SRAM cache you may be in for a VERY < ^^^ Please note! < < If Mylex designed their cache in this fashion so can others. And then again Just to correct a minor point. Mylex manufactures a board based upon a design licensed from AMI (American Megatrends International). AMI started doing BIOS design and graduated to board design. The have now added their own MARK II board that is not licensed by anybody else. It's a 25MhZ 0 wait hummer with up to 8MB on the mother. We use it and like it. PS The Mylex board (AMI) appears in numerous clones. Look for the AMI bios chip. -- {allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!cdis-1!cdin-1!icdi10!fr 26 Warren St. or ...{bellcore,rutgers,cbmvax}!bpa!cdin-1!icdi10!fr Beverly, NJ 08010 or...!bikini.cis.ufl.edu!ki4pv!cdis-1!cdin-1!icdi10!fr 609-386-6846 "Freude... Alle Menschen werden Brueder..." - Schiller
terry@eecea.eece.ksu.edu (Terry Hull) (10/13/88)
In article <224@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: > > [Question deleted] > >How much real memory is needed (when using the current X10R4 code) to >keep the system from paging like mad. I.e., the system should be able >to run a couple of csh's or vi's without paging during program >execution. > I have been told by a Bell Tech sales person that the system will run with 3 Mb of memory. They also said that the system would be paging quite a bit during "normal" operations. 4 Mb was recomended as being much more satisfactory. Several months ago, I spoke with an AT&T employee who was working on their X11 port, and he said 4 MB was te minimum amount of memory he conidered usable. Disclaimer: I am not currently a Bell Tech 10.4 user. I have XENIX and am waiting for my copy of 2.3 and Streams. -- Terry Hull Department of Electrical and Computer Engineering Kansas State University INTERNET: terry@eecea.eece.ksu.edu Manhattan, KS 66502 UUCP: {pyramid,ucsd}!ncr-sd!ncrwic!ksuvax1!eecea!terry
scotty@l5comp.UUCP (Scott Turner) (10/14/88)
Latest news from Bell... Brace yerselves... Nope, it isn't here yet. X11 is yet another "60 days" away, at least for the AT&T port. ISC is said to have a version for the WGE but no word from Bell about when it might be available. An alpha test of the X11 should show at UnixExpo, perhaps with other vaporous creatures such as the Color WGE (capable of 1280x1024x8, 1024x1024x8, 1024x720x8 one card fits all monitor budgets. :) But here again there were no promises, and absolutely NO promises about ship dates for the Color WGE. Bell's version of NFS is yet another 30 days away now. (Microport has been a tad wishy washy on their NFS dates as well.) The only "firm" words were about Sys5r3.2. My sales person seemed pretty convinced it would be out by Halloween. However, he claimed that AT&T expects everyone to "buy it again" if they wish to upgrade from Sys5r3.0... No upgrade deals. Other WGE issues straight from the mailbag... How the hell do you spawn a login xterm from init? I thought this question had an easy answer when it first showed in my E-Mail box. I mean I've seen Sun's do this no problem, you just reached into /etc/ttys and ooopss! Yeah, no damn /etc/ttys! So now what do we do? Well, it looked like xterm had the answer after all, there's this -L command line switch which tells it both that it's a login xterm and which pty to use. So off to /etc/inittab to insert: x0:23:respawn:/usr/new/xterm =80x25 unix:0 -L ttyvf Probings so far seem to indicate that the Bell supplied xterm doesn't grok the -L option. You get a usage report when you attempt to fire up xterm directly and feed it -L. Without support for -L there is nothing we can come up with for spawning a login xterm. Anyone out there got any ideas? Bell's Tech support doesn't have any answers, even for their own unix. There was a question in the mail bag asking what an "Adaptec tune-up PAL" was for the Mylex motherboard. Well youse pay $15 and youse get another 20Kb per second throughput with the ACB2322 ESDI controller. At least that's what happened here, your mileage may vary. But we get 492Kb per second here (out of the promised 1Mb per second, and yes, it's formatted 1:1) and we got 472Kb per second before the upgrade. A note to all my self appointed fire extinguishers out there: Go read the postings before sending me any more mail. I'm tired of people wanting me to do their research for them on the topic of the "Sandy Wars". To summarize my position on this whole mess in one sentence: I'm not anti-bbs or anti-download restrictions, I just think the man should have stated things a little more clearly in his public announcement of TeX being available on his system. The flame war was wasn't entirely negative as some have suggested. As a result of the battle uunet may get one more customer, Sandy may get two more BBS users, and I got the E-Mail address to send requests to if I find something missing on uunet that I want. And that's just what has hit my mail box, who knows what has hit Sandy's. Scott Turner scotty@l5comp -or- uunet!l5comp!scotty Unix vendor "fan" quotes from my mailbag: "If God had meant for man to buy Bell Tech unix we would have all been born Unix gurus." -Name withheld by request "Congratulations on getting something out of Microport at all." -John Willis
dar@belltec.UUCP (Dimitri Rotow) (10/14/88)
> A couple of questions about the WGE/Blit card: > Do you know if the cache on the Everex Step models or the ALR FlexCache > models can be disabled above 14 Meg to work with the WGE? Users with an > eye on performance will want to know this. I don't know, but Everex or ALR should be able to answer the question. > > How much real memory is needed (when using the current X10R4 code) to > keep the system from paging like mad. I.e., the system should be able > to run a couple of csh's or vi's without paging during program > execution. I run my machine with 4 MB and no problems. The machine has a Blit on it for me and four terminals for other users on one of our ACE cards plus an HP Laserjet. We routinely run 2 or 3 users running Elan eroff, Tigera Word:Era, X and lots of other stuff simultaneously with no problems. Of course, things slow down when the 'roff engine cranks. You really need more than 2 MB for most uses, and that means with most machines that you get to go to 4 MB as the next step. - Dimitri Rotow
neighorn@qiclab.UUCP (Steve Neighorn) (10/15/88)
In article <224@obie.UUCP> wes@obie.UUCP (Barnacle Wes) writes: > >A couple of questions about the WGE/Blit card: > >Do you know if the cache on the Everex Step models or the ALR FlexCache >models can be disabled above 14 Meg to work with the WGE? Users with an >eye on performance will want to know this. > >How much real memory is needed (when using the current X10R4 code) to >keep the system from paging like mad. I.e., the system should be able >to run a couple of csh's or vi's without paging during program >execution. A good base system should consist of at least 4 megabytes of memory for a single user. This should allow for at least 2 windows running in xterm. One note that should be mentioned about running X10R4 under V/386. Someone, somewhere in an incredible display for planning for the future managed to write the bootstrap loader so it starts out in real mode, rather than protected mode. This means the kernel size (I am talking the binary size, not the text+bss+data) can't be greater than around 690k. For example, a system with the 2K file system, Network Support Utilities package, Remote File Sharing package, X Windows Release 10.4, and the kernel debugger active will have a /unix size of 642063. The size command shows the actual section values: 376980+117140+865744 = 1359864. If you wanted to add a networking packing such as Wollongong, Lachman, or Streamlined Networks, you would be out of luck, at least until Release 3.2 hits the streets. R3.2 fixes the real-mode boot problem. I also know of some individual companies that have made their own changes to the 3.0/3.1 kernel, but it is not a trivial job. But don't let all this downer stuff keep you from looking at the Blit+X combination - it is a real knockout. The 1600x1200 screen and X interface knocks the socks of the Sun 3/150 sitting beside my desk at work. And the faster the base machine the better - there is a slowdown when running two bouncing ball (xdemo) programs in different windows on a 16MHz 1WS '386 machine. Something like an Everex Step machine or a Flexcache would probably take care of the bouncing balls. -- Steven C. Neighorn !tektronix!{psu-cs,reed,ogcvax}!qiclab!neighorn Intel Corporation "Where we BUILD the Star Fighters that defend the Development Tools Operation frontier against Xur and the Ko-dan Armada" 80960 Language Group work: (503) 696-7264 / home: (503) 645-7015
mike@aleytys.UU.NET (Michael Kent) (10/15/88)
In article <448@l5comp.UUCP>, scotty@l5comp.UUCP (Scott Turner) writes: > Latest news from Bell... Brace yerselves... > > Nope, it isn't here yet. X11 is yet another "60 days" away, at least for the > AT&T port. ISC is said to have a version for the WGE but no word from Bell > about when it might be available. I just saw a notice from Bell Tech yesterday. They were advertising for an X guru with the expertise to port X11. Oh, My God! You mean they haven't even BEGUN to PORT X11 yet!! "60 days" my *ss. Time to call ISC. -- Michael Kent INTERNET: mike@aleytys.UU.NET Center for M.C.E. UUCP: ...!{uflorida, uunet}!aleytys!mike 2521 NW 57th Pl. VOICE: +1-904-335-1573 Gainesville, Fl 32606 "These are MY opinions, get your own!"
scotty@l5comp.UUCP (Scott Turner) (10/19/88)
In article <303@aleytys.UU.NET> mike@aleytys.UU.NET (Michael Kent) writes: >I just saw a notice from Bell Tech yesterday. They were advertising for >an X guru with the expertise to port X11. Oh, My God! You mean they haven't >even BEGUN to PORT X11 yet!! "60 days" my *ss. Time to call ISC. Actually, I was told they were going to bring the finishing phases in-house. Or perhaps they need someone for the fabled Color WGE card? Or to make their internal deadline they decided they needed one more programmer? I suspect there may be a few WGE users doing their own X11 ports as well... Scott Turner scotty@l5comp -or- uunet!l5comp!scotty