How about an Abit TH7 Raid (yeah that's right, High point ATA100 raid controller on board, and sound from... I forget who) with a 1.4ghz P4 Willamette. The CPU is from about 6-8 months after release (so I say it's still a release model), but the board has maybe 200 hours on it as the Asus I had died in a freak shorting accident. 2x256MB PC800 RIMMS and another 2x128MB RIMMS which are somewhere around here (not with the board).

It's not in use though. All sitting in an anti static bag in a drawer. My Tualatin PIII build will be more in line with what I want if I can ever get it working.

Willamette performs ok on an i850 setup. The SDRAM i845 boxes were horrible though.

I remember reading that Willamette should have launched with 512K L2 but they chopped it down to bring up the profit margin more. Northwood sure proved that 512K was much more appropriate for P4 than 256K. If Willamette had arrived with 512K, I think P4's rep would be different. First impressions.....

Wilamettes are not as bad as they're made out to be. What's the performance drop using SDRAM instead or rambus/ DDR? Maybe 5% to 10% max. I've got a s478 Willie 1.8ghz and an SiS645 board with SDRAM. Performed OK, and was definitely better than any P3 system I've ever used, incl my Tualeron setup. I oc'ed it to 2.1ghz and it felt the same more or less with a 2ghz Northwood system.

sgt76 wrote:

Wilamettes are not as bad as they're made out to be. What's the performance drop using SDRAM instead or rambus/ DDR? Maybe 5% to 10% max. I've got a s478 Willie 1.8ghz and an SiS645 board with SDRAM. Performed OK, and was definitely better than any P3 system I've ever used, incl my Tualeron setup. I oc'ed it to 2.1ghz and it felt the same more or less with a 2ghz Northwood system.

They really are faster than they appear in benchmarks. That (for the time) really high FSB helps with a good GPU quite a bit. I would guess you get some of the benefit of that even with just plain SDRAM.

If it's true they could have shipped with 512kb of cache though, that would have made a difference, as it would have further complimented the P4's high memory bandwidth, which was it's strong suit.

I think swaaye is correct in assuming the cache was halved to save on manufacturing costs. Remember that the CPU cache is a quite large die area.
I don't know if a 1.8Ghz Willy is faster then any Coppermine/Tualatin, but it sure eats more power. Personally I think I'd prefer Athlon XP over Netburst, but perhaps that's also because I also have more experience with Socket A...and they kinda resemble Socket 370.

Willamette and Northwood may be able to hold their own, but Prescott...any point to it?

swaaye wrote:

How about Nintendo 64? 😁

I'd like to know how they could use RDRAM in the PS2 and N64 and still keep the prices reasonable. They must have taken a huge hit on every unit sold with the prices of RDRAM back then.

Tetrium wrote:

I think swaaye is correct in assuming the cache was halved to save on manufacturing costs. Remember that the CPU cache is a quite large die area.
I don't know if a 1.8Ghz Willy is faster then any Coppermine/Tualatin, but it sure eats more power. Personally I think I'd prefer Athlon XP over Netburst, but perhaps that's also because I also have more experience with Socket A...and they kinda resemble Socket 370.

Willamette and Northwood may be able to hold their own, but Prescott...any point to it?

Smaller die so they could fit 1-2MB of cache on chip. Higher clock speeds (as high as 3.8ghz), and x86_64 on the nicer LGA775 variants. Ran hot (like 110-130W TDP). The prescott had the misfortune of being released around the same time as the Athlon 64, which took away the P4's memory bandwidth advantage.

The prescott had it's uses though. The A64 chips cost more than the prescott chips, and they had around 10-20 percent more performance attached for the premium price.

I'd like to know how they could use RDRAM in the PS2 and N64 and still keep the prices reasonable.

Probably because they didn't actually use that much of it, compared to the desktop computers of the same time. The PS2 has 32MB RAM, and I think the N64 had 4MB. While I'm sure it was still absurdly expensive when compared to similar amounts of SDRAM, the total cost probably wasn't as high as you think. Plus, I'd imagine the narrow bus-width of RAMBUS allowed the board design to be a bit cheaper...

Sony did lose money on the PS2 hardware, even so. I've seen all sorts of figures and speculation about it, but it was generally figured that Sony was taking a loss of at least $100 on every console for the first year or so. On the other hand, I'm pretty sure the Gamecube was the only Nintendo console ever to lose money at launch... the N64 was always profitable AFAIK.

N64's memory bus is a whole 9bits wide so that must have saved some money indeed. SDRAM would have been bleeding edge at the time too. N64 was designed from 93-96.

The other consoles of the time had various separate banks of FP DRAM. N64 was the first with a fast unified bank. The console had only 4-5 ICs
inside. Very high integration. And of course no expensive optical drive. The carts were very expensive however and were probably what made most 3rd parties leave.

Apparently the memory controller was very poor though and the RDRAM latency combined with this created a very difficult machine to get performance out of. And also the so called texture cache forced extreme restrictions on texture size. Lots of issues with the hardware. Still it was the most impressive console for a few years.

swaaye wrote:

N64's memory bus is a whole 9bits wide so that must have saved some money indeed. SDRAM would have been bleeding edge at the tim […]
Show full quote

N64's memory bus is a whole 9bits wide so that must have saved some money indeed. SDRAM would have been bleeding edge at the time too. N64 was designed from 93-96.

The other consoles of the time had various separate banks of FP DRAM. N64 was the first with a fast unified bank. The console had only 4-5 ICs
inside. Very high integration. And of course no expensive optical drive. The carts were very expensive however and were probably what made most 3rd parties leave.

Apparently the memory controller was very poor though and the RDRAM latency combined with this created a very difficult machine to get performance out of. And also the so called texture cache forced extreme restrictions on texture size. Lots of issues with the hardware. Still it was the most impressive console for a few years.

Yeah, it was an interesting platform for sure.

They would have done better going with SDRAM, and more of it, or even just plain EDO. EDO at the time would have been within striking distance of SDRAM. Shipping the N64 with 8 or 12mb of EDO would have probably been the same amount of money as 4MB of RDRAM, and would have given the console serious a performance boost (and it was already far ahead of anything SEGA or Sony could deliver if one ignored the small storage capacity of the cartridges).

Case in point, the SGI Indy with a similar (albeit faster and more feature rich) cpu used EDO. RDRAM was overkill and had it's own share of problems.

All that being said, the N64 may not really have benefited from too much more texture memory as the cartridges couldn't store larger textures 😁. Expansion pack supported games look better for certain, but not so much better. [/i]

Altough not in use i still have RIMMS and a motherboard for them.

I have RDRAM in a video card too.
It's a 1997/98 Mpact 2 chipset based videocard with ram @ 600MHz! Wicked speed! 😵

SavantStrike wrote:

All that being said, the N64 may not really have benefited from too much more texture memory as the cartridges couldn't store larger textures 😁. Expansion pack supported games look better for certain, but not so much better. [/i]

Yeah the cartridge space was an issue but the texture cache was very very limiting. It could only load very tiny textures. Something like 32x64 pixels max! Smaller textures were more common though because they also had to use mip mapping and mip maps are included with each texture. 16x16 pixels isn't a lot of detail! 😉

Some of the better developers figured out ways to fake larger textures though.

sprcorreia wrote:

I have RDRAM in a video card too.
It's a 1997/98 Mpact 2 chipset based videocard with ram @ 600MHz! Wicked speed! 😵

Those are somewhat interesting. But they are really awful for 3D. 😀 They are neat in that they can function as a modem, DVD decoder, 3D, 2D, and sound card if the card is designed with the outputs for everything. MPACT is really a custom CPU designed around those functions. Sort of a middle of the road design between a general purpose CPU and an ASIC.

swaaye wrote:

Yeah the cartridge space was an issue but the texture cache was very very limiting. It could only load very tiny textures. Somet […]
Show full quote

SavantStrike wrote:

All that being said, the N64 may not really have benefited from too much more texture memory as the cartridges couldn't store larger textures 😁. Expansion pack supported games look better for certain, but not so much better. [/i]

Yeah the cartridge space was an issue but the texture cache was very very limiting. It could only load very tiny textures. Something like 32x64 pixels max! Smaller textures were more common though because they also had to use mip mapping and mip maps are included with each texture. 16x16 pixels isn't a lot of detail! 😉

Some of the better developers figured out ways to fake larger textures though.

sprcorreia wrote:

I have RDRAM in a video card too.
It's a 1997/98 Mpact 2 chipset based videocard with ram @ 600MHz! Wicked speed! 😵

Those are somewhat interesting. But they are really awful for 3D. 😀 They are neat in that they can function as a modem, DVD decoder, 3D, 2D, and sound card if the card is designed with the outputs for everything. MPACT is really a custom CPU designed around those functions. Sort of a middle of the road design between a general purpose CPU and an ASIC.

Maybe they should have used S3TC texture compression. 😁

swaaye wrote:

Yeah the cartridge space was an issue but the texture cache was very very limiting. It could only load very tiny textures. Somet […]
Show full quote

SavantStrike wrote:

All that being said, the N64 may not really have benefited from too much more texture memory as the cartridges couldn't store larger textures 😁. Expansion pack supported games look better for certain, but not so much better. [/i]

Yeah the cartridge space was an issue but the texture cache was very very limiting. It could only load very tiny textures. Something like 32x64 pixels max! Smaller textures were more common though because they also had to use mip mapping and mip maps are included with each texture. 16x16 pixels isn't a lot of detail! 😉

Some of the better developers figured out ways to fake larger textures though.

sprcorreia wrote:

I have RDRAM in a video card too.
It's a 1997/98 Mpact 2 chipset based videocard with ram @ 600MHz! Wicked speed! 😵

Those are somewhat interesting. But they are really awful for 3D. 😀 They are neat in that they can function as a modem, DVD decoder, 3D, 2D, and sound card if the card is designed with the outputs for everything. MPACT is really a custom CPU designed around those functions. Sort of a middle of the road design between a general purpose CPU and an ASIC.

So awful, one cannot even find benchmarks of them 🤣.

4 or 8mb variants it looks like. Judging from my P4 with Rambus, I can see why 16MB wasn't on the table. I got twin 128mb sticks and it was pricey. It took several years until I stumbled across a discarded PIII 1ghz machine with 2x256mb sticks in it. I don't even want to think about what that cost new...

Just how bad are these cards? NV1 bad, or even worse?

swaaye wrote:

Yeah the cartridge space was an issue but the texture cache was very very limiting. It could only load very tiny textures. Somet […]
Show full quote

SavantStrike wrote:

All that being said, the N64 may not really have benefited from too much more texture memory as the cartridges couldn't store larger textures 😁. Expansion pack supported games look better for certain, but not so much better. [/i]

Yeah the cartridge space was an issue but the texture cache was very very limiting. It could only load very tiny textures. Something like 32x64 pixels max! Smaller textures were more common though because they also had to use mip mapping and mip maps are included with each texture. 16x16 pixels isn't a lot of detail! 😉

Some of the better developers figured out ways to fake larger textures though.

sprcorreia wrote:

I have RDRAM in a video card too.
It's a 1997/98 Mpact 2 chipset based videocard with ram @ 600MHz! Wicked speed! 😵

Those are somewhat interesting. But they are really awful for 3D. 😀 They are neat in that they can function as a modem, DVD decoder, 3D, 2D, and sound card if the card is designed with the outputs for everything. MPACT is really a custom CPU designed around those functions. Sort of a middle of the road design between a general purpose CPU and an ASIC.

Here's a brief review of an STB board using the chip. VGA Out only, though.

http://www.pcworld.com/article/23322/stb_nitro_dvd.html

Horrible gaming card. Slow with lots of missing textures and other graphical glitches.

sliderider wrote:

Here's a brief review of an STB board using the chip. VGA Out only, though.

http://www.pcworld.com/article/23322/stb_nitro_dvd.html

Horrible gaming card. Slow with lots of missing textures and other graphical glitches.

Yup. I ran into somebody with one once and I ran 3DMark99 on it. It didn't render it even close to correctly and it was very slow. Chromatic Research was just another company that got erased by NVIDIA, 3DFX, and ATI.

SavantStrike wrote:

Case in point, the SGI Indy with a similar (albeit faster and more feature rich) cpu used EDO. RDRAM was overkill and had it's own share of problems.

Does the Indy use EDO? I thought it was FPM, same as the Indigo2 - which even with the much, much faster R10000 didn't have much of a problem with memory bandwidth. Although, that being said, I believe the design uses an interleaved access across each bank of 4 modules (the R10K being 64bit of course).

The N64 should definitely have had more memory though.... I could never stand watching any games running on it - it always seemed like a big blurry mush on the screen.

The N64 expansion pack bumped it up to 8MB. This mostly allowed for larger, more complex game worlds instead of more graphics quality. It didn't help with fillrate limits or solve the inflexible GPU texture cache that could only practically handle around 16x16 pixel textures.

Just think about that texture size for a moment. A 32x32 texture is about a quarter of the area of my avatar 🤣 If you want mip mapping, then it has to be around 16x16 because the mip maps take up space. Then stretch that out on a nice big low poly model and bilinear filter it! 😁

swaaye wrote:

The N64 expansion pack bumped it up to 8MB. This mostly allowed for larger, more complex game worlds instead of more graphics quality. It didn't help with fillrate limits or solve the inflexible GPU texture cache that could only practically handle around 16x16 pixel textures.

Just think about that texture size for a moment. A 32x32 texture is about a quarter of the area of my avatar 🤣 If you want mip mapping, then it has to be around 16x16 because the mip maps take up space. Then stretch that out on a nice big low poly model and bilinear filter it! 😁

Yep. That's the trademark N64 big-blurry-mush right there! 😁

megatron-uk wrote:

SavantStrike wrote:

Case in point, the SGI Indy with a similar (albeit faster and more feature rich) cpu used EDO. RDRAM was overkill and had it's own share of problems.

Does the Indy use EDO? I thought it was FPM, same as the Indigo2 - which even with the much, much faster R10000 didn't have much of a problem with memory bandwidth. Although, that being said, I believe the design uses an interleaved access across each bank of 4 modules (the R10K being 64bit of course).

The N64 should definitely have had more memory though.... I could never stand watching any games running on it - it always seemed like a big blurry mush on the screen.

My bad! It's FPM.

Case in point, the N64 didn't need RDRAM.

swaaye wrote:

The N64 expansion pack bumped it up to 8MB. This mostly allowed for larger, more complex game worlds instead of more graphics quality. It didn't help with fillrate limits or solve the inflexible GPU texture cache that could only practically handle around 16x16 pixel textures.

Just think about that texture size for a moment. A 32x32 texture is about a quarter of the area of my avatar 🤣 If you want mip mapping, then it has to be around 16x16 because the mip maps take up space. Then stretch that out on a nice big low poly model and bilinear filter it! 😁

The solution was to just use a bunch of flat colors and textures that sucked 😜. The poly count is all relative though. It's a lot higher than it was for the Saturn or the PS1.