Path: utzoo!attcan!uunet!sam!douglass
From: douglass@davidsys.com
Newsgroups: comp.sys.ibm.pc.hardware
Subject: Re: Dual monitors
Message-ID: <8345@davidsys.com>
Date: 14 Feb 91 14:59:10 GMT
References: <166@cf_su20.cf_su10.Sbi.COM> <26810@uflorida.cis.ufl.EDU> <8130@davidsys.com> <1991Feb12.010248.7563@cs.mcgill.ca>
Organization: DAVID Systems Inc, Sunnyvale CA
Lines: 53

In article <1991Feb12.010248.7563@cs.mcgill.ca>, phil@cs.mcgill.ca (Philip LOCONG) writes:
> In article <8130@davidsys.com> douglass@davidsys.com writes:
>>
>>Also, I have done some testing of some systems I have available and
>>found no difference in performance to my 16-bit VgaWonder with an
>>IBM monochrome adapter in or out.
>>Testing indicates (on *my* systems, YMMV):
>>16-bit VGA fastest (only text mode tested, of course)
>>8-bit M[DG]A (or CGA) takes twice as long to write to as 16-bit VGA
>>IBM EGA (8-bit) three times as long as 16-bit VGA 
>>
>>These results gathered on 6 and 8 MHz 80286 AT clones, 16 MHz Compaq 386,
>>16 and 33 MHz 80386 clones.
>>Sorry to run on so long, but I just can't understand why an 8-bit
>>card should slow down a 16-bit card!?!   At least it doesn't in my case.
>
>As earlier posts suggested it, the ISA bus specifications force the bus
>to run each 128k section of RAM entirely in 8-bit mode or entirely in
>16-bit mode, that means the A-B section has to be either 8 or 16-bit.
 
Excuse me, but you're *WRONG*.
I've already run a test that indicates otherwise.
I know of projects where this 'limitation' was 'overcome'.
The 'problem' lies in the timing of the address lines coming from the
16-bit slot.
To put it simply, if the card responds quickly enough, there is NO PROBLEM.
(If the motherboard and/or card is not designed well enough, the card can
never respond 'quickly enough'.)
In other words:  Numbers talk (see above tests).
I would be interested to know of other cards that support fast access.
(or the converse).
 
>[ stuff proving that VGA and monochrome live within 128K deleted ]
>run at 8-bit. Then there's also the BIOS in the C-D section...
 
Now, with all of that out of the way, we all realize that the Video ROM
for the [EV]GA (at C000) is 8-bit.  Right?
By your argument, that would mean that all of C000-DFFF must be 8-bit?
Including your 16-bit ExPANded memory board (EMS)?
Including your 16-bit (memory_mapped) Network board (WD, 3COM, etc)?
Including your 16-bit nifty fast (memory_mapped) SCSI board?
Including your 16-bit (memory_mapped) tape backup board?
 
Try doing benchmarks, people.  It's really not that diffucult.
 
>
>Philippe Locong
>phil@bart.cs.mcgill.ca
-- 
-{JD}-  Jeff (douglass@davidsys.com)  David Systems, Sunnyvale CA,(408)720-8000
/*   My opinions are my own.  Who else would want them?   */
    "Never count on the inevitable until it happens. . ."
    "So therefore a pointer to dev/nul (the nul device) is a NULL pointer?"