PCI-Express over Cat6

[KR Williams]

KR Williams wrote:

[SNIP]

Backwards compatibility? AGP was compatible with exactly what?

Compatibility with pre-AGP software.

Come on. That's trivial for any port. Map the addresses in the
same range and go for it.

If you consider putting shitloads of RAM onto the graphics card
a solution I don't think it slowed that down at all. What it did
enable was low-cost solutions *at the time it came out*, the kind
of solutions that would suit kiddies who would break their piggy
bank to play a game.

That's *precisely* what I advocated at the time. Memory sizes
grew (and costs fell) to where this was not only possible, but
mandatory at the same time AGP became available. Indeed the only
things that used AGP (system memory resident) textures were Intel
demos. Impressive, but hardly useful. Graphics cars have
outstripped AGP usage ever since.

[SNIP]

I may have a tough spot in my soul for Intel, dreaming for what
might have been (and technically possible), but you're a lackey

OK, I'll bite. What might have been when AGP was first mooted ?

The first day it was shipped in a product. Graphics cards were
even then shipping with more (texture) memory than the games of
the day were using. It was a *bad* idea, much like UMA. Memory
is and was cheap. 32MB cards were normal then, and 128MB cheap
now. There would be even more memory on graphics cards if there
were a reason. Like I said earlier, even my 2D card has 32MB.

In the context of this discussion your assertion of being a "lackey
for what is" is wrong anyway. It flatly ignores my preference which
is render into main memory and DMA the framebuffer to the RAMDAC.

Oh, my! NO wonder we disagree so much. I have *NO* interest in
bottling up main memory with such trivia. I'm sure you liked UMA
too. Let me ask you; Do you have an integrated UMA graphics
controller on your system?

Nice and simple, lots of control for the programmer. However I do
recognise this is not a good solution right now because of the way
the hardware is structured and the design trade-offs.

It is a *horrible* idea. It puts too much stress on the exact
wrong area of the system. UMA not only affects memory bandwidth,
but latency. I'd rather not give up either and throw it all at
the processor. Perhaps it's because I know what's possible in
hardware and you're simply dreaming of a perfect world (again).

I never have liked MS stuff to be honest. Never liked x86s either,
but on the other hand Intel contributed heavily to PCI and on
balance I think that has been a valuable contribution to the
industry as a whole.

I'm not a PCI fan either, but it is what is. I've gotten over my
anger at stupid marketing and have learned to accept the
inevitable (and have even designed to it, though it's
unnecessarily ugly).

I've never had an issue with x86. I even liked segmentation,
unless I had to do huge data structures. :-( ...which was rare
as a hardware type.

Amazing the difference in perspective between hardware wonks and
software weenies. ;-)

 

[Rupert Pigott]

removing-this.darkboong.demon.co.uk says...
[SNIP]

If you consider putting shitloads of RAM onto the graphics card
a solution I don't think it slowed that down at all. What it did
enable was low-cost solutions *at the time it came out*, the kind
of solutions that would suit kiddies who would break their piggy
bank to play a game.

That's *precisely* what I advocated at the time. Memory sizes
grew (and costs fell) to where this was not only possible, but
mandatory at the same time AGP became available. Indeed the only
things that used AGP (system memory resident) textures were Intel
demos. Impressive, but hardly useful. Graphics cars have
outstripped AGP usage ever since.

[SNIP]

I may have a tough spot in my soul for Intel, dreaming for what
might have been (and technically possible), but you're a lackey

OK, I'll bite. What might have been when AGP was first mooted ?

The first day it was shipped in a product. Graphics cards were
even then shipping with more (texture) memory than the games of
the day were using. It was a *bad* idea, much like UMA. Memory
is and was cheap. 32MB cards were normal then, and 128MB cheap
now. There would be even more memory on graphics cards if there
were a reason. Like I said earlier, even my 2D card has 32MB.

So your suggestion that "Indeed, perhaps AGP put off better
solutions many years" does not in fact apply to the better solution
that you personally advocated. OK, I let's say I accept that the
card fetching textures itself while leaving the CPU to get on and
do other work is a waste of time because your advocated solution
was applied.

How about the bandwidth aspect of AGP ? What else was out there
to provide that at the time ?

Oh, my! NO wonder we disagree so much. I have *NO* interest in
bottling up main memory with such trivia. I'm sure you liked UMA
too. Let me ask you; Do you have an integrated UMA graphics
controller on your system?




It is a *horrible* idea. It puts too much stress on the exact
wrong area of the system. UMA not only affects memory bandwidth,
but latency. I'd rather not give up either and throw it all at

It can do, depending on how you design your memory subsystem. If
you go the dumb route and just introduce wait states - it'll hurt,
if you go the smart route and have seperate banks of RAM it'll
hurt less (Amiga Low mem/Fast mem). If you can find some VRAM it
will hurt even less, fun stuff to work with.

the processor. Perhaps it's because I know what's possible in
hardware and you're simply dreaming of a perfect world (again).
[SNIP]

Amazing the difference in perspective between hardware wonks and
software weenies. ;-)

Or people who lived breathed and worked next to folks who produced
the first 32 bit uP to integrate FPU and static RAM. Someone who
also happened to spend a large amount of time working with the
graphics stuff they did there too. They *did* do UMA, but they
used VRAM, which made everything very easy (although costly).

I have to say that I did enjoy figuring out to get a ~300MFLOP
crate of T800s munging fractals and piping the data into a dinky
little 1280x1024x24 framebuffer via four 20mbit pipes. Would love
to have another crack at that crate with what I know now.

That was a long time ago and the wheel of incarnation has made a
half-turn since then.

Cheers,
Rupert

 

[Tim McCaffrey]

[SNIP]
My issue is simply AGP's founding principle; use of processor
storage to store textures. An *incredibly* dumb idea, rather
like it's younger sibling UMA (for 2D).

For the newest games, with zillions of textures, it seems likely they may not
even be in processor memory, but on disk, you have to get them to the card
somehow, and AGP's high bandwidth pipe is useful for this.

[SNIP]

The third issue was about latency. No one has shown me where
latency matters to the graphics pipe. (see the paragraph above).

Latency matters because there is a deadline (the next video refresh) to get
the frame rendered. If the GPU has to fetch a texture from main memory (just
because it has never used that texture before), or even to get the GPU
commands for rendering a frame, it better have the lowest latency, highest
bandwidth pipe available. You miss the frame refresh by 1 microsecond, you
might as well have missed it by 99% of the frame. This affects frame rates,
and this is perceptible by humans.

It's obvious to anyone with a functioning brain cell that AGP
(note 'P' == "PORT") is faster than the more general and poorly
optimized (cheap-ass 32/33) general purpose PCI (*BUS*) with
random crappy devices attached to it.

My argument is that AGP was a bad idea from day one. Because it
is what is and the best we've got, doesn't change my opinion.

Given the busses that are available now, do you think any of them are better
for this application than AGP:
1) PCI-Express
2) PCI-X
3) HyperTransport
4) RapidIO
5) Infiniband :0

I'm also not quite sure what your exact objections are to AGP at this point.
How would you make it better for what you preceive as how it is used?

In general, the biggest performance problem with most of these I/O busses is
that they do not pull data very well (PCI-E & PCI-X partially fix that with
split reads, I do not know about AGP), but pushing data is not too bad. The
trick seems to be to keep down data pulls, but that is somewhat difficult
without a DMA engine in the Northbridge.

- Tim

 

[KR Williams]

[SNIP]
My issue is simply AGP's founding principle; use of processor
storage to store textures. An *incredibly* dumb idea, rather
like it's younger sibling UMA (for 2D).

For the newest games, with zillions of textures, it seems likely they may not
even be in processor memory, but on disk, you have to get them to the card
somehow, and AGP's high bandwidth pipe is useful for this.

Come on! Graphics cars have space for "zillions of textures".
They're served from disk just like anything else in the system.
Queueong "zillions of textures" in RAM is silly. Put 'em as
close to where they're useful as possible! This isn't rocket-
surgery!

[SNIP]

The third issue was about latency. No one has shown me where
latency matters to the graphics pipe. (see the paragraph above).

Latency matters because there is a deadline (the next video refresh) to get
the frame rendered.

Bullshit! The nest frame to be rendered doesn't depend on a new
texture that a modern card doesn't already have. Sure, it may
have to come from disk, but changes of scene are well known ahead
of when the textures are needed. Keeping un-needed textures in
main memory is *DUMB*, when modern cards have 128MB of their own.

If the GPU has to fetch a texture from main memory (just
because it has never used that texture before), or even to get the GPU
commands for rendering a frame,

If the GPU is that surprised that it needs that texture, it's
going to suck anyway. It is *not* going to be in system memory
either.

it better have the lowest latency, highest
bandwidth pipe available.

You confuse latency and bandwidth.

You miss the frame refresh by 1 microsecond, you
might as well have missed it by 99% of the frame. This affects frame rates,
and this is perceptible by humans.

Hogwash! If the texture isn't ready on the card, there is no
hope. Hint: it's not in the processors memory. If the program
knew it was needed it would already be on the graphics card.

Given the busses that are available now, do you think any of them are better
for this application than AGP:

In your love for AGP, you've totally missed my point.

1) PCI-Express
2) PCI-X
3) HyperTransport
4) RapidIO
5) Infiniband :0

A: All of the above. HT would be my choice today, but that
wasn't part of the discussion. Perhaps you want to go back and
read what I've said?

I'm also not quite sure what your exact objections are to AGP at this point.
How would you make it better for what you preceive as how it is used?

Today? HT. Though "today" is irrelevant to my point.

In general, the biggest performance problem with most of these I/O busses is
that they do not pull data very well (PCI-E & PCI-X partially fix that with
split reads, I do not know about AGP), but pushing data is not too bad. The
trick seems to be to keep down data pulls, but that is somewhat difficult
without a DMA engine in the Northbridge.

Please read what I've written, not what you wish to infer from
same.

 

[Rupert Pigott]

(e-mail address removed) says...
[SNIP]

Given the busses that are available now, do you think any of them are better
for this application than AGP:

In your love for AGP, you've totally missed my point.

1) PCI-Express
2) PCI-X
3) HyperTransport
4) RapidIO
5) Infiniband :0

A: All of the above. HT would be my choice today, but that
wasn't part of the discussion. Perhaps you want to go back and
read what I've said?

I'm also not quite sure what your exact objections are to AGP at this point.
How would you make it better for what you preceive as how it is used?

Today? HT. Though "today" is irrelevant to my point.

Last I heard HT is strictly a chip-to-chip interconnect at present
(I don't have direct access to the specs though, so I could be out
of date on this). If that is the case, it does not have an "expansion
card" type form factor *yet* so it is not suitable for how the PC
market actually works in the *real* world.

Snipped c.a. because no one else is much interested in this thread
in there.

Cheers,
Rupert

 

[KR Williams]

(e-mail address removed) says...
[SNIP]

Given the busses that are available now, do you think any of them are better
for this application than AGP:

In your love for AGP, you've totally missed my point.

1) PCI-Express
2) PCI-X
3) HyperTransport
4) RapidIO
5) Infiniband :0

A: All of the above. HT would be my choice today, but that
wasn't part of the discussion. Perhaps you want to go back and
read what I've said?

I'm also not quite sure what your exact objections are to AGP at this point.
How would you make it better for what you preceive as how it is used?

Today? HT. Though "today" is irrelevant to my point.

Last I heard HT is strictly a chip-to-chip interconnect at present
(I don't have direct access to the specs though, so I could be out
of date on this). If that is the case, it does not have an "expansion
card" type form factor *yet* so it is not suitable for how the PC
market actually works in the *real* world.

Hint: AGP is point-to-point too (the only reason it's faster than
dirt-cheap PCI 32/33). The card interface is a small thing
compared to the multi-drop penalty of a bus (which neither are).

Snipped c.a. because no one else is much interested in this thread
in there.

Good idea. I kept it there because I thought that's where you
were coming from.

 

[Rupert Pigott]

(e-mail address removed) says...
[SNIP]


Given the busses that are available now, do you think any of them are better
for this application than AGP:


In your love for AGP, you've totally missed my point.



1) PCI-Express
2) PCI-X
3) HyperTransport
4) RapidIO
5) Infiniband :0


A: All of the above. HT would be my choice today, but that
wasn't part of the discussion. Perhaps you want to go back and
read what I've said?



I'm also not quite sure what your exact objections are to AGP at this point.
How would you make it better for what you preceive as how it is used?


Today? HT. Though "today" is irrelevant to my point.

Last I heard HT is strictly a chip-to-chip interconnect at present
(I don't have direct access to the specs though, so I could be out
of date on this). If that is the case, it does not have an "expansion
card" type form factor *yet* so it is not suitable for how the PC
market actually works in the *real* world.

Hint: AGP is point-to-point too (the only reason it's faster than
dirt-cheap PCI 32/33). The card interface is a small thing

Well --ing Duh. This was one of the things that didn't pass me by
in comp.arch over the last decade.

That is *not* the only reason why AGP is faster than PCI. Sure AGP
uses a different signalling scheme, but it also introduced some
extra protocol such as pipelined transactions (dunno if PCI caught
up with that).

compared to the multi-drop penalty of a bus (which neither are).

It doesn't change the fact that HT was designed for short-traces
on PCBs, not long traces and tripping over a connector. This has
been thrashed to death in comp.arch. For those reasons alone it
would be an inadequate substitute for AGP in the PC market.

Cheers,
Rupert

 

[Tim McCaffrey]

You confuse latency and bandwidth.

No, I don't. What makes you think I'm confused?

In your love for AGP, you've totally missed my point.

I think you have me confused with somebody else,
I don't love or hate AGP.

A: All of the above. HT would be my choice today, but that
wasn't part of the discussion. Perhaps you want to go back and
read what I've said?

No thanks, once was more than enough. HT, interesting, it seems
like nVidia is drifting in the direction of building an HT GPU...

Today? HT. Though "today" is irrelevant to my point.

Please read what I've written, not what you wish to infer from
same.

To summerize what I think your arguement is:
1) AGP doesn't need a fast pipe to memory, because the textures are on
the card.
2) AGP doesn't need to write things back to memory, because
programmer's don't do that. (chicken-and-egg warning, if GPUs don't do this
well now, then programmers will not use it...)

I think it is pretty easy to test #1, just put a modern,
lots-of-memory card in a fast PC, and (if the BIOS lets you) limit the AGP
slot to x1 speed and see if it affects performance. I recall lots of
benchmarks showing that going from x1 to x2 AGP was a significant performance
boost, but cards didn't have so much memory back then. If there is a
performance difference, then you apparently don't know as much as you think
you do.

- Tim

 

[David Schwartz]

1) AGP doesn't need a fast pipe to memory, because the textures are on
the card.

I think it is pretty easy to test #1, just put a modern,
lots-of-memory card in a fast PC, and (if the BIOS lets you) limit the AGP
slot to x1 speed and see if it affects performance. I recall lots of
benchmarks showing that going from x1 to x2 AGP was a significant
performance
boost, but cards didn't have so much memory back then. If there is a
performance difference, then you apparently don't know as much as you
think
you do.

Doesn't AGPx1 versus AGPx2 also affect the bandwidth between the AGP
card and the CPU? He never said video cards don't need a fast pipe to the
CPU.

DS

 

[David Schwartz]

1) AGP doesn't need a fast pipe to memory, because the textures are on
the card.

I think it is pretty easy to test #1, just put a modern,
lots-of-memory card in a fast PC, and (if the BIOS lets you) limit the AGP
slot to x1 speed and see if it affects performance. I recall lots of
benchmarks showing that going from x1 to x2 AGP was a significant
performance
boost, but cards didn't have so much memory back then. If there is a
performance difference, then you apparently don't know as much as you
think
you do.

Doesn't AGPx1 versus AGPx2 also affect the bandwidth between the AGP
card and the CPU? He never said video cards don't need a fast pipe to the
CPU.

DS

 

[George Macdonald]

No, I don't. What makes you think I'm confused?


I think you have me confused with somebody else,
I don't love or hate AGP.

No thanks, once was more than enough. HT, interesting, it seems
like nVidia is drifting in the direction of building an HT GPU...

To summerize what I think your arguement is:
1) AGP doesn't need a fast pipe to memory, because the textures are on
the card.

From what I've seen, no - I think Keith is essentially saying AGP DIME
(Direct Execute Mode, i.e. textures not on the card) was a dumb idea and
the mechanisms included in the specs to support it were a bit of a red
herring. Note that multiplexed pipelining and long transfers have been
dropped from the AGP 3.0 specs in favor of SBA.

2) AGP doesn't need to write things back to memory, because
programmer's don't do that. (chicken-and-egg warning, if GPUs don't do this
well now, then programmers will not use it...)

Again, if you don't have DIME......

I think it is pretty easy to test #1, just put a modern,
lots-of-memory card in a fast PC, and (if the BIOS lets you) limit the AGP
slot to x1 speed and see if it affects performance. I recall lots of
benchmarks showing that going from x1 to x2 AGP was a significant performance
boost, but cards didn't have so much memory back then. If there is a
performance difference, then you apparently don't know as much as you think
you do.

It's kind hazy but were there *any* cards which did only 1x AGP? The AGP
1.0 spec included 2x clocking. Certainly 4x and 8x did not seem to bring
much further improvements.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

 

[George Macdonald]

KR Williams wrote:

[SNIP]


Given the busses that are available now, do you think any of them are better
for this application than AGP:


In your love for AGP, you've totally missed my point.



1) PCI-Express
2) PCI-X
3) HyperTransport
4) RapidIO
5) Infiniband :0


A: All of the above. HT would be my choice today, but that
wasn't part of the discussion. Perhaps you want to go back and
read what I've said?



I'm also not quite sure what your exact objections are to AGP at this point.
How would you make it better for what you preceive as how it is used?


Today? HT. Though "today" is irrelevant to my point.

Last I heard HT is strictly a chip-to-chip interconnect at present
(I don't have direct access to the specs though, so I could be out
of date on this). If that is the case, it does not have an "expansion
card" type form factor *yet* so it is not suitable for how the PC
market actually works in the *real* world.

Hint: AGP is point-to-point too (the only reason it's faster than
dirt-cheap PCI 32/33). The card interface is a small thing

Well --ing Duh. This was one of the things that didn't pass me by
in comp.arch over the last decade.

That is *not* the only reason why AGP is faster than PCI. Sure AGP
uses a different signalling scheme, but it also introduced some
extra protocol such as pipelined transactions (dunno if PCI caught
up with that).

Multiplexed pipelining has been dropped in AGP 3.0, along with long and
high priority transactions.

It doesn't change the fact that HT was designed for short-traces
on PCBs, not long traces and tripping over a connector. This has
been thrashed to death in comp.arch. For those reasons alone it
would be an inadequate substitute for AGP in the PC market.

Huh? He just said, and you agreed, that AGP is *also* a point-to-point
connect. Besides, HT specs include such things as tunnels and switches and
the protocol arrangements for routing.

I must say you seem to be somewhat talking past each other. It seems to me
that Keith's main point is that DIME was a stupid idea, as well as the
arrangments put into AGP to accomodate it, e.g. long, high priority,
pipelined writes to main memory.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

 

[Rupert Pigott]

KR Williams wrote:


[SNIP]



Given the busses that are available now, do you think any of them are better
for this application than AGP:


In your love for AGP, you've totally missed my point.




1) PCI-Express
2) PCI-X
3) HyperTransport
4) RapidIO
5) Infiniband :0


A: All of the above. HT would be my choice today, but that
wasn't part of the discussion. Perhaps you want to go back and
read what I've said?




I'm also not quite sure what your exact objections are to AGP at this point.
How would you make it better for what you preceive as how it is used?


Today? HT. Though "today" is irrelevant to my point.

Last I heard HT is strictly a chip-to-chip interconnect at present
(I don't have direct access to the specs though, so I could be out
of date on this). If that is the case, it does not have an "expansion
card" type form factor *yet* so it is not suitable for how the PC
market actually works in the *real* world.

Hint: AGP is point-to-point too (the only reason it's faster than
dirt-cheap PCI 32/33). The card interface is a small thing

Well --ing Duh. This was one of the things that didn't pass me by
in comp.arch over the last decade.

That is *not* the only reason why AGP is faster than PCI. Sure AGP
uses a different signalling scheme, but it also introduced some
extra protocol such as pipelined transactions (dunno if PCI caught
up with that).

Multiplexed pipelining has been dropped in AGP 3.0, along with long and
high priority transactions.

Bah.

Huh? He just said, and you agreed, that AGP is *also* a point-to-point
connect. Besides, HT specs include such things as tunnels and switches and
the protocol arrangements for routing.

I repeatedly asked Keith what alternatives there were to AGP when it
came out. He blustered a bit about AGP's texture fetching from main
memory being a waste of time when all they had to do was stick more
RAM on the cards (which happened anyway - regardless of AGP). Then
he was asked what other I/F would he use instead of AGP and he said
HT. I pointed out HT is not an appropriate solution for the graphics
card market. I should have added a qualifier to that because I wouldn't
be entirely surprised if *some* GPUs designed to be mounted on the
motherboard went HT.

To be honest I think Keith must have been bitten by a rabid AGP
slot when he was a child or something. It's not a great solution but
it basically works and it supplied the bandwidth if nothing else at
a time when it was needed. PCI-X wasn't there, PCI-Express wasn't
there and HT wasn't there...

I must say you seem to be somewhat talking past each other. It seems to me

Don't Keith's assertions that various contributors "love AGP" ring
alarm bells ? That said I can understand where Keith is coming from,
but he's not being very realistic, and to be fair, I think I could
probably be at least as angry about VLB, I really detested VLB. :/

Cheers,
Rupert

 

[Rupert Pigott]

George Macdonald wrote:

[SNIP]

It's kind hazy but were there *any* cards which did only 1x AGP? The AGP
1.0 spec included 2x clocking. Certainly 4x and 8x did not seem to bring
much further improvements.

Dunno about 8x. I find that going from 4x -> 1x with my BIOS does hurt
3D performance. Usually takes a ~20% hit in the fps, depending on the
app/game. The problem of course is that you're not necessarily comparing
apples to apples, there's a lot of software in the way, much of which
you can't get the source for. :/

[Snipped comp.arch, this ramble seems to be largely ignored there]

Cheers,
Rupert

 

[George Macdonald]

Don't Keith's assertions that various contributors "love AGP" ring
alarm bells ? That said I can understand where Keith is coming from,
but he's not being very realistic, and to be fair, I think I could
probably be at least as angry about VLB, I really detested VLB. :/

I think there were lots of alarm bells back then: AGP/DIME, DRDRAM... such
a lovely umm pair. As for VLB, well yeah but in reality it was a stop gap
to fend off a slew of proprietary "solutions" which were starting to
fester.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

 

[Rupert Pigott]

I think there were lots of alarm bells back then: AGP/DIME, DRDRAM... such
a lovely umm pair. As for VLB, well yeah but in reality it was a stop gap
to fend off a slew of proprietary "solutions" which were starting to
fester.

You mean EISA and PCI ? Realistically VLB had about a 3 month window
on the shelves before PCI blew it away. EISA was just expensive and
quite frankly it sucked anyway.

Cheers,
Rupert

 

[George Macdonald]

You mean EISA and PCI ? Realistically VLB had about a 3 month window
on the shelves before PCI blew it away. EISA was just expensive and
quite frankly it sucked anyway.

No, I meant *proprietary* 32-bit buses including connection schemes.
Gigabyte had one which used something which resembled two ISA-16 connectors
and a propietary video card to go with it... about 6months before VLB was
available. I still have the mbrd in the buried in the attic... which
reminds me I need to go up there one of those days. There were signs
that other mbrd mfrs were thinking along similar lines.

EISA was a umm, camel??

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

 

[Rupert Pigott]

On Sun, 23 May 2004 13:41:58 +0100, Rupert Pigott
[SNIP]

You mean EISA and PCI ? Realistically VLB had about a 3 month window
on the shelves before PCI blew it away. EISA was just expensive and
quite frankly it sucked anyway.

No, I meant *proprietary* 32-bit buses including connection schemes.

Odd. I think I've started blanking that word because it's been so
abused. Recent(ish) history : Intel's FUD that SPARC is "Proprietry",
the implication being that Itanic is not ? I'd need at least the 4
fingers left over from one hand counting the Itanic sources compared
to the SPARC ones.

That's a whole rant in itself I guess.

Gigabyte had one which used something which resembled two ISA-16 connectors
and a propietary video card to go with it... about 6months before VLB was

Never came across those one-off kinda things, but the UK was very
backward until relatively recently in terms of 'cutting edge' stuff. The
one I *should* have mentioned was MCA, but you could still license that
(and some folks did). However that did not suck nearly as much as EISA
in my experience.

available. I still have the mbrd in the buried in the attic... which
reminds me I need to go up there one of those days. There were signs
that other mbrd mfrs were thinking along similar lines.

EISA was a umm, camel??

AFAICT it delivered little for big bucks and very little room for
growth. Lots of slots just don't cut it when you want bandwidth.

Cheers,
Rupert

 

[George Macdonald]

On Sun, 23 May 2004 13:41:58 +0100, Rupert Pigott
[SNIP]
Gigabyte had one which used something which resembled two ISA-16 connectors
and a propietary video card to go with it... about 6months before VLB was

Never came across those one-off kinda things, but the UK was very
backward until relatively recently in terms of 'cutting edge' stuff. The
one I *should* have mentioned was MCA, but you could still license that
(and some folks did). However that did not suck nearly as much as EISA
in my experience.

I agree with Keith here - MCA was what we should have had as the main
system bus... if only IBM had not tried to hold everybody up for ransom. I
hated the card slot mounting mechanism -- though I never actually cut
myself on those slot plates they seemed sharp enough for the job -- but
otherwise it was a real computer bus.

AFAICT it delivered little for big bucks and very little room for
growth. Lots of slots just don't cut it when you want bandwidth.

Just the ECU was a nightmare. Then the whole idea of a robust new, wider
bus which was backwards compatible with ISA was a catastrophic blunder.

Rgds, George Macdonald

"Just because they're paranoid doesn't mean you're not psychotic" - Who, me??

 

[Nate Edel]

You mean EISA and PCI ? Realistically VLB had about a 3 month window on
the shelves before PCI blew it away. EISA was just expensive and quite
frankly it sucked anyway.

Longer than that; PCI 486 systems/motherboards were pretty unusual in my
experience, so VLB hung on for quite a while until the cost of Pentiums
started falling. I'm not sure if anyone made a VLB Pentium motherboard; I
don't recall ever seeing one.