cliffhanger@cup.portal.com (Cliff C Heyer) (09/08/89)
(The HARDWARE Q's are intermixed below.) I'm planning to buy a 80386 PC for use with UNIX, MSDOS, OS/2, and WINDOWS/386. After studying the trade papers and marketing literature, I've made the following conclusions: (feel free to comment) 1. Price: 33MHz hardware about same ballpark as 25MHz hardware. 2. 33MHz hardware not yet reviewed in key areas of: bus speed, paged/interleaved memory, shadow (BIOS/video) RAM, disk cache(memory or controller), extended memory speed, wait states. 3. 100% of 33MHz hardware gives 10-20% better MIPS than 25MHz. 4. 33MHz hardware disk I/O only 0-5% better than 25MHz. In other words, it might as well be the same. 5. 80386 portables are about the same price as 33MHz desk hardware but are 50% slower in CPU and 70% slower in I/O. QUESTIONS about 33MHz 80386 PCs... (This is where I need the help!) 1. UNIX (or any multitasking OS) and the effects of the on-board cache: While multitasking, does flushing the cash waste a measurable amount of run time or is it insignificant compared to swapping, paging, and/or other overhead? In other words, is the cache still beneficial even though it is being flushed? (I assume "yes" since minicomputers such as all VAX models have them.) 2. Is memory technology (cost/speed ) lagging behind microprocessor technology? All the newest 33MHz 80386 PCs are using 70+ ns DRAMs when the 386 is running at 30 ns and the on-board caches are rated at 25 ns. You can't get 0 wait states 100% of the time with this approach. 3. Is it impractical (cost and/or size) to put 40 256KB 25ns SRAMs (no refresh overhead and cycle time=access time) up for main memory? In other words, is it cheaper to implement paged (PMRAM, SCRAM) or interleaved schemes to reduce wait states rather than use 40 SRAMs? It seems like alot of trouble to go to...but how much do SRAMs cost? 4. Are any board makers making (or have made) motherboards with ESDI and/or SCSI interfaces ON BOARD to bypass the 8MHz AT bus? Also hopefully this mfg. would include shadow RAM (BIOS & video) and extended/expanded memory that is as fast as main memory. (eg. add on memory boards have same cycle time as the first 2MB.) 5. I assume the ONLY thing that makes the 33MHz PCs faster is the 25 ns cache. Otherwise, with 70 ns DRAM the BEST you could do would be run as fast as a 16MHz 80386 PC (62 ns) but with lots of wait states. In other words, memory cycle time limits non-cache CPU performance to that of a 16MHz 80386. 6. If you whipped out your trusty soldering gun and anti-static gear and changed all your memory chips to 25 ns SRAMS(on a 33MHz machine w/no cache) would the wait states go away? OR is the timing part of the hardware architecture? (Pardon me for this seemingly naive question, but I've been doing software for 8 years.) 7. The PC manufacturers never talk about parity error checked memory, ECC memory, Harvard A.(separate data/instruction cache), data write-thru cache, write buffers (CPU can go on after issuing write instruction only), and multi-word memory transfers. Are PC mfgs behind the times? Or is this because of all the canned stuff from the east. 8. Is there ANY manufacturer who has fully exploited the power of the 80386 chip? That is, at 33MHz is there any hardware that... >can support sustained disk I/O >1MB/sec by bypassing the AT bus via on-board controllers, or using VME, etc., >has "real" 100% zero wait state memory (probably SRAM), AND expanded/extended memory boards (no wait states 100% of the time), >(for PCs) has shadow RAM (BIOS & video), >gives you several "real" 32-bit "backplane" slots and controllers for them (Intel or Zeos?), >operates FCC class B. Please POST your comments.
plocher%sally@Sun.COM (John Plocher) (09/09/89)
In article <21969@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes: >2. 33MHz hardware not yet reviewed in key areas of: >bus speed, paged/interleaved memory, shadow >(BIOS/video) RAM, disk cache(memory or controller), >extended memory speed, wait states. The issues here can be grouped like this: paged/interleaved memory and/or cache Cache is best (32k is absolute minimum, >64k doesn't show much improvement) Static column (page mode) is almost as good, Interleaved is better than "normal" but not worth it if you are spending the $ on a 25/33 MHZ system... (Go with cache or page mode) memory speed and wait states Without cache you need faster than 60ns for 33MHz no wait state, 80ns for 25MHz no wait state With a cache you can get by with 80-100ns for the 33MHZ box and 100ns for the 25MHZ box. Same for Page Mode. bus speed If it isn't 8MHZ (i.e., if it is 10 or 12) don't touch it! Many cards won't run faster than 8MHZ on the bus. shadow RAM Not meaningful for Unix since Unix doesn't use the BIOS >4. 33MHz hardware disk I/O only 0-5% better than 25MHz. In >other words, it might as well be the same. As stated in this group, the DPT caching controller with 2.5MB+ of ram is FAST. So is a good ESDI or smart SCSI >1. UNIX (or any multitasking OS) and the effects of >the on-board cache: > > While multitasking, does flushing the cash waste a Flushing the cache means that the next 32,000 unique instructions/data references will run at the slower memory speed (3-8 wait states each) See the notes in this group about interactions between dual ported memory on I/O cards (serial/ethernet) and the cache. If you can't disable the cache for these cards, you can't use the cards. > >2. Is memory technology (cost/speed ) lagging behind >microprocessor technology? All the newest 33MHz >80386 PCs are using 70+ ns DRAMs when the 386 is >running at 30 ns and the on-board caches are rated >at 25 ns. You can't get 0 wait states 100% of the >time with this approach. If you could get affordable 50ns dynamic RAM you could ignore all the cache questions for a 33MHz box. Since you can't, you use fast (25ns) cache RAM and slower dynamic RAM. (The cache has to be accessed every time memory is, so it must be quite a bit faster than main memory) >3. Is it impractical (cost and/or size) to put 40 256KB >25ns SRAMs >alot of trouble to go to...but how much do SRAMs cost? LOTS. At that speed they would be at least an order of magnitude more expensive than the 70ns DRAMS per megabyte. Also SRAM uses *POWER* which means big power supplies and lots of heat. Back in '84 I bought a complete PCAT clone (kbd, mono, 1MB RAM, 30MB hard disk...) for LESS than a 1MB 8MHz Static Ram board for my S100 system cost. >4. Are any board makers making (or have made) >motherboards with ESDI and/or SCSI interfaces ON >BOARD to bypass the 8MHz AT bus? Also hopefully Mylex has a 32bit Disk controller (I think it is SCSI) and it is very fast! >this mfg. would include shadow RAM (BIOS & video) Why? Unix can't use it. >and extended/expanded memory that is as fast as >main memory. (eg. add on memory boards have same >cycle time as the first 2MB.) If the Motherboard has a 32 bit connector card then the expansion board should run at full speed as main memory. I will leave the rest of the comments/questions for others ... -John
cliffhanger@cup.portal.com (Cliff C Heyer) (09/09/89)
You folks from PC Week, Infoworld & MIS week who asked me to send you any information I get on this timely issue... Is this for publication? If so, do you intend to put our names on your byline or in your article? I *read* every page of every trade magazine every week! If I see something quoted from this (or any) collection *without* due credit I'll be mighty angry!! (Unlike many engineers who *might* only read ACM Transactions, etc.) Big brother is watching! I hope you've read news.announce.newusers where it talks about copyrights and plagiarism.... IMHO :-) Cliff Heyer
sl@van-bc.UUCP (Stuart Lynne) (09/09/89)
In article <124379@sun.Eng.Sun.COM> plocher@sun.UUCP (John Plocher) writes: >In article <21969@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes: >bus speed > If it isn't 8MHZ (i.e., if it is 10 or 12) don't touch it! Many cards > won't run faster than 8MHZ on the bus. Argh!!!! That's right folks, spend $5000 on a brand new 386 box and then put a governor on it so you can run that old $200 card you bought at the swap meet last week. Get the fastest bus you can, and buy peripherals to match. My bus run's at 12Mhz. If a card won't run in it, I will throw it out and get one that will. Suprisingly there's quite a few that work just fine. I've run without *any* problems: WD8003E ethernet WD1006SR2 hard disk IBM Monochrom (circa 1983, one of the originals) Quadram JTFax 9600 ADT Smartfax 9600 Bell Tech / Everex cartridge Clone parallel, 2 serial, game port Clone parallel, 2 serial One thing that you can do if you have a specific card that you absolutely need to run is to ensure that you get a system that you can tailor the wait states on. For a while I had a fax card that wouldn't run at 12Mhz at first try. But by adding a wait state to 8bit I/O cycles it did. But 16 bit was still full speed. (You want to have 16 bit full speed to optimize your disk throughput.) -- Stuart.Lynne@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
terry@tah386.manhattan.ks.us (Terry Hull) (09/10/89)
In article <276@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: >Argh!!!! That's right folks, spend $5000 on a brand new 386 box and then put >a governor on it so you can run that old $200 card you bought at the swap >meet last week. > >Get the fastest bus you can, and buy peripherals to match. My bus run's at >12Mhz. If a card won't run in it, I will throw it out and get one that will. > Who on the net has information about how much speed advantage following this advice will provide? Me, I have an AMI 25Mhz motherboard with an 8Mhz bus speed, and it SCREAMS, especially when I run a DPT RLL disk controller with 2.5 MB of cache. What am I giving up by having a 8Mhz bus running to my disk controller, tape controller VRAM VGA card and serial ports? I'm really not interested in a theoretical answer. I want to know what operations are noticably faster when using a higher bus speed. After all, if you do not notice the speed difference, who cares? -- Terry Hull Department of Electrical and Computer Engineering, Kansas State University Work: terry@eecea.eece.ksu.edu, rutgers!ksuvax1!eecea!terry Play: terry@tah386.manhattan.ks.us, rutgers!ksuvax1!eecea!tah386!terry
keithe@tekgvs.LABS.TEK.COM (Keith Ericson) (09/12/89)
In article <570@tah386.manhattan.ks.us> terry@tah386.manhattan.ks.us (Terry Hull) writes: >In article <276@van-bc.UUCP> sl@van-bc.UUCP (Stuart Lynne) writes: > >Who on the net has information about how much speed advantage >following this advice will provide? >... >I'm really not interested in a theoretical answer. I want to know >what operations are noticably faster when using a higher bus speed. >After all, if you do not notice the speed difference, who cares? We spent quite a bit of time investigating video diplay performance of various machines, bus speeds and display cards (VGA and EGA). As important as bus speed was 8-bit versus (proper) 16-bit operation. Also important was the quality of the display card's BIOS routines. We found some cases where others reported a particular card to be very fast, yet our (non-BIOS-implemented, i.e., direct write to display memory) tests showed them to be slower than others. When the object of the game is to move large blocks of pixels around in a hurry you _will_ notice the difference in bus speeds, word size, and good software. But if you're doing a lunch-break tape backup, the performace of the disk controller card will be more important than the bus speed. ST-506 only puts out 5 Mbits/sec = 0.675 MBytes per second anyway. Even when your disk controller can keep up with this rate (a 1:1 interleave) the bus will not be the limiting factor. Even the fastest ESDI drives at 15 Mbits/sec=1.875 Mbytes/sec shouldn't be choked by the bus speed. kEITHe My employer doesn't care about my opinions. (Or at least now I'll find out if it does or not!)
jiii@visdc.UUCP (John E Van Deusen III) (09/13/89)
In article <5914@tekgvs.LABS.TEK.COM> keithe@tekgvs.LABS.TEK.COM (Keith Ericson) writes: > > We spent quite a bit of time investigating video diplay performance > of various machines, bus speeds and display cards (VGA and EGA). > As important as bus speed was 8-bit versus (proper) 16-bit operation. > > kEITHe In the June 1989 issue of BYTE Magazine, Bradley Dyck Kliewer wrote an article entitled "Debunking 16-bit VGA. In that article he tested six 16-bit VGA adaptors for the AT bus. He states that of all the boards tested, none had 16-bit latch registers. His benchmark tests for copying a block of pixels to the entire screen byte by byte gave results in the 10 to 20 second range (for video mode 16, which I assume is 1024x768x16 colors?). I am not convinced that level of performance would cut it for an X-terminal application. Mr. Kliewer suggests using graphics coprocessor boards; are cheaper ones coming? -- John E Van Deusen III, PO Box 9283, Boise, ID 83707, (208) 343-1865 uunet!visdc!jiii
scottw@ico.ISC.COM (Scott Wiesner) (09/14/89)
From article <641@visdc.UUCP>, by jiii@visdc.UUCP (John E Van Deusen III): > In the June 1989 issue of BYTE Magazine, Bradley Dyck Kliewer wrote an > article entitled "Debunking 16-bit VGA. In that article he tested six > 16-bit VGA adaptors for the AT bus. He states that of all the boards > tested, none had 16-bit latch registers. His benchmark tests for > copying a block of pixels to the entire screen byte by byte gave results > in the 10 to 20 second range (for video mode 16, which I assume is > 1024x768x16 colors?). I am not convinced that level of performance > would cut it for an X-terminal application. Mr. Kliewer suggests using > graphics coprocessor boards; are cheaper ones coming? 8 bit vs. 16 bit really nets you nothing for most graphics operations on a VGA board. This is mostly marketing hype. They're getting faster text mode operation (where you write an attribute and data byte pair), but the EGA and VGA are 8 bit devices internally. Everything you do to one of these adapters goes through an 8 bit data path internal to the card, and for most operations, you must do 8 bit memory access to the card for things to work right. The only advantage to some 16 bit boards is that they're often from a newer generation of VGA chips, which makes them faster. The companies could just as easily make an 8 bit card from these newer chips, but the market demands 16 bit cards these days. In my work, I see a fairly wide range of performance in different VGA cards. It's a situation where you get what you pay for. The TSENG Labs based cards (Orchid, Genoa, STB, etc.) are a very good value. 1024x768 with 16 colors is nice. The performance isn't as good as more expensive cards such as those made by Video 7, but for most things, it's still acceptable. There are new boards just around the corner coming from many vendors that will have better performance for lower cost. It's an ever- evolving market. On the subject of graphics coprocessor boards, the IBM 8514/A looks very good, and when the AT clones of this board become available later in the year, there will be a lot of happy people. Scott Wiesner Interactive Systems
jiii@visdc.UUCP (John E Van Deusen III) (09/15/89)
In article <16081@vail.ICO.ISC.COM> scottw@ico.ISC.COM (Scott Wiesner) writes: >> In article <641@visdc.UUCP> I wrote: >> I am not convinced ... [VGA]... performance would cut it for an >> X-terminal application. Mr. Kliewer suggests using >> graphics coprocessor boards; are cheaper ones coming? > > On the subject of graphics coprocessor boards, the IBM 8514/A looks > very good, and when the AT clones of this board become available later > in the year, there will be a lot of happy people. > > Scott Wiesner > Interactive Systems In his Hardware Review in the Jan 1989 BYTE Magazine entitled "Pixels on the March", Bradley Dyck Kliewer reviewed the 8514/A coprocessor board. In its highest resolution mode (1024x780 pixels x 16 colors) the 8514 sends an interlaced signal to the display. It has been stated several time in this newsgroup that 1024x768 interlaced is almost indistinguishable from 800x600 pixel SVGA. This is, of course, just the sort of technical problem that the clone makers delight in rectifying, so I guess maybe I'll be happy when this board becomes a universal standard. What I really want to do is put together a 1024x 768x16 color noninterlaced X-terminal, based on a PC, that can update the entire screen in less than 2 seconds. I think that a SVGA adapter with real 16-bit latch registers should be capable of something in the range of 5 to 10 seconds. -- John E Van Deusen III, PO Box 9283, Boise, ID 83707, (208) 343-1865 uunet!visdc!jiii
scottw@ico.ISC.COM (Scott Wiesner) (09/16/89)
Subject: Re: How to choose a new 386 UNIX PC... Newsgroups: comp.unix.i386 References: <645@visdc.UUCP> From article <645@visdc.UUCP>, by jiii@visdc.UUCP (John E Van Deusen III): > In article <16081@vail.ICO.ISC.COM> scottw@ico.ISC.COM (Scott Wiesner) > writes: >> >> On the subject of graphics coprocessor boards, the IBM 8514/A looks >> very good, and when the AT clones of this board become available later >> in the year, there will be a lot of happy people. >> > > In his Hardware Review in the Jan 1989 BYTE Magazine entitled "Pixels on > the March", Bradley Dyck Kliewer reviewed the 8514/A coprocessor board. > In its highest resolution mode (1024x780 pixels x 16 colors) the 8514 > sends an interlaced signal to the display. It has been stated several > time in this newsgroup that 1024x768 interlaced is almost > indistinguishable from 800x600 pixel SVGA. The 8514/A has 256 colors in its highest resolution mode. IBM's board does indeed produce an interlace display, but I'd have to disagree with the claim that this is indistinguisable from 800x600 SVGA. I certainly feel that non-interlaced is far preferable to interlaced, but I think many people will agree that even an interlaced 1024x768 with 256 colors is better than 800x600 with 16 colors. This is mainly a personal preference call. > This is, of course, just > the sort of technical problem that the clone makers delight in > rectifying, so I guess maybe I'll be happy when this board becomes a > universal standard. As I mentioned, the boards are coming, and I believe many if not all will support a non-interlaced display. Several will also provide a resolution of 1280x1024. > What I really want to do is put together a 1024x > 768x16 color noninterlaced X-terminal, based on a PC, that can update > the entire screen in less than 2 seconds. Could you explain what you mean by "update the screen in less than 2 seconds"? If all you've got on your screen is a color background and no windows, you can certainly update in less than 2 seconds. If you've got something very complex displayed, not even a SPARC or MIPS based machine with a very high performance display would be likely to update it in 2 seconds. When you say "based on a PC", do you mean an XT-class PC, or a 386-class PC? > I think that a SVGA adapter > with real 16-bit latch registers should be capable of something in the > range of 5 to 10 seconds. This is an interesting comment. I'm not aware of any VGA boards with 16 bit latches, or any plans to produce such a board. There's certainly no existing software that could deal with such a board. This is kind of like saying a PC based on a SPARC processor will be faster than one based on a 386. It is a true statement, but probably doesn't get you what you wanted. How do you arrive at your update time of 5 to 10 seconds for such a board? Scott Wiesner Interactive Systems
bds@lzaz.ATT.COM (B.SZABLAK) (09/19/89)
In article <16097@vail.ICO.ISC.COM>, scottw@ico.ISC.COM (Scott Wiesner) writes: > This is an interesting comment. I'm not aware of any VGA boards with > 16 bit latches, or any plans to produce such a board... The idea of 16 bit latches apparently is in reference to speeding up the interface to the board. My question is: if the VGA is an integral part of the motherboard shouldn't it in principle run much faster than a bus card limited to the ATs 8MHz bus (assumming the motherboard is running faster than 8MHz)? Or is there some other factors involved?
keithe@tekgvs.LABS.TEK.COM (Keith Ericson) (09/20/89)
In article <16081@vail.ICO.ISC.COM> scottw@ico.ISC.COM (Scott Wiesner) writes: > >8 bit vs. 16 bit really nets you nothing for most graphics operations >on a VGA board. This is mostly marketing hype. They're getting faster >text mode operation (where you write an attribute and data byte pair), >but the EGA and VGA are 8 bit devices internally. Except that a (properly done) 16 bit card can yank on the 0WS (meaning "don't add any additional wait states") which an 8-bit card cannot. An 8-bit card gets a minimum (as I recall) of 3 wait states (and it might be 5 or 7, I can't recall and the local expert isn't in right now for me to ask) whereas the 16-bit cards can eliminate most (not all) of the I/O bus wait states. The display system may not be a whole lot faster, but maybe the machine can get on to something else a bit sooner. By the way, we're currently using a Tatung VGA as standard equipment around here. It's the one that has (1) the Video7 IC's and (2) only to 256k (maximum) display RAM. (It turns out the 256k limit isn't important for our purposes.) Tatung makes another 16-bit VGA that uses the Paradise chipset which is an inferior-performing card, so be sure you get the Video7 clone if you're evaluating or buying. kEITHe
psm@cbnewse.ATT.COM (p.steve.murphy) (09/20/89)
It seems that this discussion has digressed a bit, could the author of this topic post a summary or email me one. -- =============================================================================== Steve Murphy | "Ternary operators are clever programming. phone: 1(312)510-4678 | I don't like clever programming." ...!nwgpa!toolserv!psm | - An anonymous programmer
jiii@visdc.UUCP (John E Van Deusen III) (09/21/89)
In article <16097@vail.ICO.ISC.COM> scottw@ico.ISC.COM (Scott Wiesner) writes: > From article <645@visdc.UUCP>, I wrote: >> ... It has been stated several times in this newsgroup that 1024x768 >> interlaced is almost indistinguishable from 800x600 pixel SVGA. > > ... I think many people will agree that even an interlaced 1024x768 > with 256 colors is better than 800x600 with 16 colors. Judging from the currently-available X terminal products, many people are willing to forsake ALL color for honest 1024x768 resolution. >> What I really want to do is put together a 1024x768x16 color >> noninterlaced X-terminal, based on a PC, that can update the entire >> screen in less than 2 seconds. > > Could you explain what you mean by "update the screen in less than 2 > seconds"? If all you've got on your screen is a color background and > no windows, you can certainly update in less than 2 seconds. If > you've got something very complex displayed, not even a SPARC or MIPS > based machine with a very high performance display would be likely to > update it in 2 seconds. The operation is often called BITBLT. It means that a block of pixels, residing in memory, is to be transferred to the screen. It is the responsibility of the X terminal software to keep track of which areas of the screen need to be updated, and presumably it can keep track of several levels of overlapping windows if sufficient memory is available. In the worst case, an entire screen full of pixels would have to be transferred. It is NOT the responsibility of the X terminal software to convert a complex representation into pixels; that is the function of the client software. The client software may indeed be executing on one or more SPARC or RISC-based computers. > When you say "based on a PC", do you mean an XT-class PC, or a 386- > class PC? By PC I mean that I would like to run the application on an AT bus. Thus a member of the 80x86 processor family would be used to feed the VGA adaptor a byte at a time over an 8 MH bus. This clearly doesn't require a 33 MH 386. The problem is with the OS. If the software is MSDOS-based then it is hard to access the megabytes of memory needed to store the "underlying" areas of the screen. If the X terminal software is UNIX-based then a 386 is required, if only for ready access to the latest software. In the latter case, costs really get out of hand because of all the licensed software that is required and not really used. I would like to suggest that you people at Interactive (or SCO or Bell/Intel) put together a stand-alone X terminal software package to run on low-end 386s. You have all the software, including drivers, sitting there; it's simply a matter of bundling it and putting it on the price list. The package could easily sell for $500 a pop; since it would solve the problem of poor X server performance on 386 machines running UNIX, and there is nothing like it yet on the market. >> I think that a SVGA adapter with real 16-bit latch registers should >> be capable of something in the range of 5 to 10 seconds. > > ... I'm not aware of any VGA boards with 16 bit latches, or any plans > to produce such a board. There's certainly no existing software that > could deal with such a board. ... How do you arrive at your update > time of 5 to 10 seconds for such a board? I simply took the two fastest times from Bradley Dyck Kliewer's BITBLT test (see BYTE, June 1989, "Debunking 16-Bit VGA"), where the blocks were written as 16-bit words. The colors in this case were incorrect, because the latch registers (and others) are only 8 bits wide. It does give an indication of the time required, however. > Scott Wiesner > Interactive Systems -- John E Van Deusen III, PO Box 9283, Boise, ID 83707, (208) 343-1865 uunet!visdc!jiii
dyer@spdcc.COM (Steve Dyer) (09/21/89)
In article <648@visdc.UUCP> jiii@visdc.UUCP (John E Van Deusen III) writes: >I would like to >suggest that you people at Interactive (or SCO or Bell/Intel) put >together a stand-alone X terminal software package to run on low-end >386s. You have all the software, including drivers, sitting there; it's >simply a matter of bundling it and putting it on the price list. The >package could easily sell for $500 a pop; since it would solve the >problem of poor X server performance on 386 machines running UNIX, and >there is nothing like it yet on the market. First, X runs fine under AIX PS/2 using an 8514 display adapter and screen, whether in monochrome (using the 19" mono screen whose model # I forget) or in full color (the 8514 16" screen.) It's quite snappy; I've never had to stop and kvetch about poor performance on a 20mhz 386 PS/2 with 6 meg of memory. I suspect that the problem is trying to use X on VGA displays on machines which don't have enough memory to begin with. IBM sells "X Windows for DOS" and Locus sells what I believe to be the same product, PC/Xsight. I have no experience with either of these products. I believe you are limited to what you can do in 640K, but I could be wrong. -- Steve Dyer dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer dyer@arktouros.mit.edu, dyer@hstbme.mit.edu
scottw@ico.ISC.COM (Scott Wiesner) (09/21/89)
From article <648@visdc.UUCP>, by jiii@visdc.UUCP (John E Van Deusen III): > If the software is > MSDOS-based then it is hard to access the megabytes of memory needed to > store the "underlying" areas of the screen. I'm going to go out on a limb here and say you don't really want backing-store/saveunder on a VGA based X system. Actually, it's reasonable to some extent, but you're limited by how much off screen video memory you've got, which isn't much on Super-VGA. Going back to system memory for these things is very very slow. You can do simple stuff (text, lines, polygons) much much faster than you can do memory to screen and screen to memory BITBLT. The main problem is for BITBLT, you have to access each pixel 4 times to read or write it, while for something like text, you can take advantage of some of the special capabilities of EGA/VGA and go much faster. > In the latter case, costs really get out of hand because of all the > licensed software that is required and not really used. I would like to > suggest that you people at Interactive (or SCO or Bell/Intel) put > together a stand-alone X terminal software package to run on low-end > 386s. You have all the software, including drivers, sitting there; it's > simply a matter of bundling it and putting it on the price list. The > package could easily sell for $500 a pop; since it would solve the > problem of poor X server performance on 386 machines running UNIX, and > there is nothing like it yet on the market. While we do basically have all the software "sitting there", it's not quite as simple as bundling it, unless you mean we should supply a Unix environment with only the X server and no other commands such as the development system, VP/ix, "ls", "cp", etc. That's an interesting idea, but is something I'll leave to our marketing people. What you really want is fast VGA, which is difficult. There are certainly some boards on the market that are faster than others, and there are new ones in the works at many companies that are faster still. > poor X server performance on 386 machines running UNIX, I'd be interested in which companies' X servers you've seen, and in what ways you think the performance is poor. Certainly BITBLT is slow, and it always will be on something like the VGA. Other areas, especially text performance, are fairly good. It all depends on what you're doing. If EGA/VGA were great at everything, we wouldn't need things like 8514, 34010, etc. I don't believe that we're suffering too much by running Unix here as opposed to running standalone. Scott Wiesner Interactive Systems
jackv@turnkey.gryphon.COM (Jack F. Vogel) (09/22/89)
In article <4635@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes: >IBM sells "X Windows for DOS" and Locus sells what I believe to be the >same product, PC/Xsight. I have no experience with either of these products. >I believe you are limited to what you can do in 640K, but I could be wrong. The IBM product is the Locus product licensed to IBM. I believe there are a couple of differences between the IBM labeled product and ours, however they are essentially the same. And you are right, the original PC Xsight was stuck with that old DOS memory limit, however the new release, version 2.0 I believe, will now work with extended memory. With a good video subsystem installed this will make a very usable X server. Interested parties should contact Locus. Disclaimer: This is not an official statement, my opinion only. -- Jack F. Vogel jackv@seas.ucla.edu AIX Technical Support - or - Locus Computing Corp. jackv@ifs.umich.edu
jiii@visdc.UUCP (John E Van Deusen III) (09/23/89)
In article <4635@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes: > In article <648@visdc.UUCP> I wrote: >> I would like to suggest that you people at Interactive (or SCO or >> Bell/Intel) put together a stand-alone X terminal software package >> to run on low-end 386s. [It solves the] problem of poor X server >> performance on 386 machines running UNIX ... > > First, X runs fine under AIX PS/2 using an 8514 display adapter and > ... the 8514 16" screen. It's quite snappy ... I suspect that the > problem is trying to use X on VGA displays ... The only thing I have against the 8514A is the lack of NON-INTERLACED 1024x768 resolution and the lack of such boards for the AT bus. I think that the concept of the graphics processor is right on the beam, because trying to force pixels one-byte-at-a-time across an 8MH AT bus may very well be at the heart of the problem. The drawback to the particular configuration that you cite is that it is a PC solution, not a multiuser one. It is not cost effective to give each user a PS/2 capable of running AIX, if the application is running on another set of machines. The configuration is FAR too expensive to be used only as a terminal. That goes for any PC hopped up with enough hardware and UNIX-based software to be able to function as an X-terminal. A 20MH 386 board with 4MB, a display, and a ethernet adaptor is NOT too expensive to be used as a terminal. The problem comes when you need to add a big disk and expensive software consisting of the UNIX OS, TCP/IP, X windows, and Merge (Note 1): all this for each user. By then so much is invested that it is natural to try to run some application as well. This requires a bigger disk, at least another 4 MB of memory, hassling with cache memory, and a processor upgrade to 25 or 33 MH (double the price of the mother board for each). If you need to run multiuser, then you are back at square one. This is why I suggested that ISC, SCO, etc. create of version of all this UNIX software that ONLY functions as an X terminal. > IBM sells "X Windows for DOS" and Locus sells what I believe to be the > same product, PC/Xsight. ... I believe you are limited to what you > can do in 640K, but I could be wrong. I know that Locus is working on an extended-memory version of PC/Xsight. The problem is that such extensions are non-standard. > -- > Steve Dyer > dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer > dyer@arktouros.mit.edu, dyer@hstbme.mit.edu ___ Note 1: In case it isn't obvious, the reason for basing an X terminal on a PC is to have access to peripherals and cards that currently only work with MSDOS. PC/Xsight, for instance, allows the I/O from MSDOS peripherals to be piped to UNIX applications. -- John E Van Deusen III, PO Box 9283, Boise, ID 83707, (208) 343-1865 uunet!visdc!jiii
palowoda@fiver.UUCP (Bob Palowoda) (09/23/89)
From article <4635@ursa-major.SPDCC.COM>, by dyer@spdcc.COM (Steve Dyer): > In article <648@visdc.UUCP> jiii@visdc.UUCP (John E Van Deusen III) writes: >>I would like to > IBM sells "X Windows for DOS" and Locus sells what I believe to be the > same product, PC/Xsight. I have no experience with either of these products. > I believe you are limited to what you can do in 640K, but I could be wrong. I was reading that Locus just released version 2.0 of Xsight that is compiled with Rational Tech. compilier which will all you to run up to 16meg extended memory. They also went to 11.3. It looks to be a good low end type X Terminal under dos. Couple things I wonder about. What eithernet cards it supports. And what they are going to do about a file server. I would perfer NFS (even with it's flaws) something like FTP's Interdrive. I read somewhere they where going to support TCF. Can NFS and TCF reside on the same system with out any conflicts? Has anyone tried a NFS client/server in conjunction with Locus Xwindows talking on a eithernet to a 386ix X-windows server? ---Bob -- Bob Palowoda packbell!indetech!palowoda *Home of Fiver BBS* login: bbs Home {sun|dasiy}!ys2!fiver!palowoda (415)-623-8809 1200/2400 Work {sun|pyramid|decwrl}!megatest!palowoda (415)-623-8806 2400/9600/19200 TB Voice: (415)-623-7495 Public access UNIX XBBS
jackv@turnkey.gryphon.COM (Jack F. Vogel) (09/23/89)
In article <654@fiver.UUCP> palowoda@fiver.UUCP (Bob Palowoda) writes: >From article <4635@ursa-major.SPDCC.COM>, by dyer@spdcc.COM (Steve Dyer): >> In article <648@visdc.UUCP> jiii@visdc.UUCP (John E Van Deusen III) writes: >> IBM sells "X Windows for DOS" and Locus sells what I believe to be the >> same product, PC/Xsight. I have no experience with either of these products. >> I believe you are limited to what you can do in 640K, but I could be wrong. > I was reading that Locus just released version 2.0 of Xsight ... > ....Couple things I wonder about. What >eithernet cards it supports. And what they are going to do about a >file server. I would perfer NFS (even with it's flaws) something like >FTP's Interdrive. I read somewhere they where going to support TCF. >Can NFS and TCF reside on the same system with out any conflicts? >Has anyone tried a NFS client/server in conjunction with Locus >Xwindows talking on a eithernet to a 386ix X-windows server? I don't know what ethernet cards Xsight supports but if there is sufficient interest it would only take me a few minutes to find out. Otherwise just give Locus a call (213 670-6500) and check with the sales types. I don't understand what you mean when asking what we are going to do about a file server, the whole purpose of an "X Terminal" is that it is an independent entity leaving it to the user to supply whatever server they desire. I am also not sure what you mean about supporting TCF. Since TCF is a feature in the AIX370 and second generation AIXPS/2 kernel developed by Locus for IBM it is clearly not something that runs on a PC. However, if you mean will the Xsight user be able to use that software to access a TCF AIX cluster of systems, the answer is definitely. In fact IBM is marketing a licensed version of Xsight which they call "X on DOS" for just this purpose. Finally, you ask if NFS and TCF can reside on the same system. Again, the answer is yes, all AIX370 kernels also have NFS in them, the PS/2 systems on the cluster can either be configured with or without NFS. Both the client side and server are there. Disclaimer: This is not an official statement, my opinions only. -- Jack F. Vogel jackv@seas.ucla.edu AIX Technical Support - or - Locus Computing Corp. jackv@ifs.umich.edu
jiii@visdc.UUCP (John E Van Deusen III) (09/25/89)
In article <6365@turnkey.gryphon.COM> jackv@turnkey.gryphon.COM writes: > > [Regarding PC/Xsight] The IBM product is the Locus product licensed > to IBM. ... With a good video subsystem installed this will make a > very usable X server. > -- > Jack F. Vogel jackv@seas.ucla.edu > AIX Technical Support - or - > Locus Computing Corp. jackv@ifs.umich.edu It turns out, according to UNIX REVIEW, that the version of X11.3 provided by SCO for UNIX 3.2 is also the Xsight product licensed from Locus. -- John E Van Deusen III, PO Box 9283, Boise, ID 83707, (208) 343-1865 uunet!visdc!jiii
madd@bu-cs.BU.EDU (Jim Frost) (09/26/89)
In article <649@visdc.UUCP> jiii@visdc.UUCP (John E Van Deusen III) writes: |In article <4635@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM |(Steve Dyer) writes: |> IBM sells "X Windows for DOS" and Locus sells what I believe to be the |> same product, PC/Xsight. ... I believe you are limited to what you |> can do in 640K, but I could be wrong. Doesn't matter. The product is too slow to use unless you have a 386 or very fast 286. The demo that IBM had at Usenix ran so slow that I couldn't handle it (and I've used the Sun 386i 8 bit-plane for heavy-duty X). Not recommended. jim frost software tool & die madd@std.com
jackv@turnkey.gryphon.COM (Jack F. Vogel) (09/26/89)
In article <650@visdc.UUCP> jiii@visdc.UUCP (John E Van Deusen III) writes: >In article <6365@turnkey.gryphon.COM> jackv@turnkey.gryphon.COM writes: > [ my earlier comments deleted...] >It turns out, according to UNIX REVIEW, that the version of X11.3 >provided by SCO for UNIX 3.2 is also the Xsight product licensed from >Locus. Yes this is correct John in fact we did the actual port of the Xsight code for the SCO kernel in 2.3.x and 3.2. SCO is great at not making very visible third party logos and such in their advertisement (Oh, they're there if you get out the magnifying glass :-}!), witness their advertise- ment of OpenDesktop, you'd think it was all SCO's work where it is really a merged effort of SCO, DEC, Ingres, Locus, and perhaps one other company which slips my mind at the moment. We provide both the X and Merge parts of the package. On the subject of X, there are only really three X server ports of any consequence for the i386 families of Unix, Locus' which is licensed by both SCO and Bell, Interactive's, and IBM's AIX server. The AIX port was actually done by IBM's own internal development in a couple of locations. (Yes I am aware of Enix or whatever it is called these days, but it is so pathetic that I don't include it :-} ). Disclaimer: these are my opinions, not necessarily Locus'. -- Jack F. Vogel jackv@seas.ucla.edu AIX Technical Support - or - Locus Computing Corp. jackv@ifs.umich.edu
davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) (09/27/89)
If someone wanted to write their own device driver, etc, for a super VGA there are some around which will do 1024x768 without breaking you. I have a Hedaka which went about $175, and which needs another batch of memory to get to 1024x768. Figure the total at $250 more or less. That would be a nice way to go X. Of course the cost of the monitor is so high that the board is not the major consideration. Note that CPU and memory (and even disk) are going down, but good graphics is still very painful. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "The world is filled with fools. They blindly follow their so-called 'reason' in the face of the church and common sense. Any fool can see that the world is flat!" - anon
paula@bcsaic.UUCP (Paul Allen) (09/29/89)
In article <535@crdos1.crd.ge.COM> davidsen@crdos1.UUCP (bill davidsen) writes: >[about low-cost ways to get 1024x768 VGA] > [...] Of course the cost of the monitor is so >high that the board is not the major consideration. Bill's right about high-res color VGA monitors. However, if you don't have to have color the price drops dramatically. I just picked up a Princeton Max-15 multisync greyscale VGA monitor for $180. (This was a one-time deal. The typical mail-order price for this monitor is ~$250.) Princeton says it will do 1024x768. I saw it running Windows in 1024x768 mode, but a barely noticeable flicker suggested the display was interlaced. The spec sheet says the max horizontal rate is 39KHz, which I don't think is good enough for 1024x768 non-interlaced. I need to add RAM to my card in order to test it out for myself. One of the PC magazines recently reviewed a bunch of monochrome VGA monitors. Of the bunch, only two were capable of 1024x768: the Max-15 and one other. The Max-15 has more features, but the reviewer liked the look of the raster better on the other monitor. Both monitors had list prices of ~$350. Paul Allen -- ------------------------------------------------------------------------ Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen