Nice straight forward architecture. High speed processors, for the time. Decent amount of memory, for the time. Cartridge instead of CD (access time, transfer rates).
Well laid out motherboard (nice curvey lines to reduce signal reflections).
Unified memory, decent MIPS core. Decent graphics performance and a *lot* could be done with the RSP if you could get the microcode source from Nintendo.
Libraries were great. Minimal in footprint, Nintendo gave debug (anally retentive) libraries as well optimized release builds. Helped find bugs easily.
Debugging was decent, once we got off the SGI machines.
PS1 was, well, a PS1. Pretty crap really. GFX performance was reasonable, though. Audio was 'free' but crap.
Saturn was a mess. 2nd CPU slapped on at the last minute and some engineer in Japan made a serious mistake in the glue logic that caused it to be slower than molases. There was something odd about the polys on that machine (or was is PS1?) they were quads instead of tris, but with only top-left, bottom-right UVs.
Dreamcast was nice enough. Just a shame Microsoft used Sega for their first implementation of wince and fucked them over in the process, as well as offending pretty much any developer by insisting they used that nonsense.
Of course, I also had access to the full source code, symbol tables and a debug kit. So, that made it pretty easy to find the buffer overrun. It was actually in a wide string copy. Src, Dst and data were all on the stack.
Well, those pro's need to get with the times. Analog had its place and time and is no longer needed (I'm sure I'll get flamed for that).
Yes, apparently, analog sounds better but who cares? I mean, you lose quality on every analog duplication pass. Every duplication of a digital produces, surprise surprise, a 100% identical duplicate of the original.
Now that most professional audio is sampled and 192K plus, what's the deal? What's so good about analog? Does it sound "smoother"? If so, why? Is it because of higher harmonics or is it because the technology introduces a "smoother", "softer" sound due to it's flaws?
Hanging on to this technology is very nostalgic, I'm sure. But even the horse drawn carriage got replaced by better technology.
Can anyone explain why Intel do not produce 90nm versions of those chips? I would expect that the change in production method would further improve the power dissipation of these chips.
Like said in the article, most of these chips are used for embedded systems and, as such, would benefit from reduced power consumption.
BTW, the shuttle still uses a 386 processor. From what I understand, from a very helpful guide at JSC visitor center, is that the shuttle uses less than 50% of the CPU time of the 386 and it has about 256K (yes, K) of memory.
Americans have always been particularly atrocious at picking correct case.
Maybe it should be
iNteRnEt.
I suppose, we should just make everything uppercase and be done with it. It would save 26 characters out of the ASCII set we could use for emoticons!
However, Windows is typically accessing more than one file. Part of the slow down in boot times, I suspect, is due to the thrashing caused on the disk array. It's most certainly not CPU bound. If there are multiple seeks outstanding (versus linear reads) then there will be a significant performance benefit from doing independant seeks.
Now, I don't have any figures to show what this would do. Then again, I don't have any figures to the contrary.
Whether or not a raid array has it's own independant processor is irrelevant in my opinion. The amount of overhead *SHOULD* be tiny when dealing with a mirrored, or striped, array. I mean, how much processing does it take to figure out which block is going to be read?
Raid-5 will always benefit from a seperate processor. Mind you, the parity calculation is so trival, even a 486 can do it at a fair clip (check the Linux bootlogs for an old system to see the speed).
All the experiences I have had with hardware based raid controllers have been less than satisfactory. Dell shipped a PERC-3 controller card that could barely sustain 15MB/sec off a 10K drive array! That was RAID-5 but come on folks! Raid-5 isn't that hard to calculate.
Does the raid driver typically allow two independent seeks on the seperate drives with mirroring enabled? I would expect this to significantly improve things like boot times as most of the time is spent seeking for new data. I would have expected a 50% drop in seek.
If they don't do independent seeks, why the hell not?
I think you're reading *WAY* more in to this than required. I worked at DMA and they were never very tight on keeping track of resume's received and demo disks.
In the early years, there was talk of a game that goes along the lines of somehow hurting sheep. This was a David 'Oz' Osbourne idea. This is what, I understand, eventually morphed in to GTA.
I have a DVR box here in Austin and they are the absolute worst in performance and ease of use. They are very unstable, crashing a lot. They forget to record programs, they don't start recording, sometimes, until 1 minute in to a show.
Channel switching is SO PAINFULLY SLOW. Sometimes I can press channel up 5 times, then down 3 times wait about 5 seconds then it will do them all in one go.
Just absolutely, unbelievably terribly slow programming. I would be embarrassed to work on such a project.
I don't know what sort of excuses Scientific Atlanta could bring for such a painfully slow product. I would love to hear why they are so slow. That should be good for a laugh.
The user interface is just frustrating. Having to press 'SELECT' instead of 'PLAY' when you're over a program you want to watch is just unforgivable.
You may be able to tell I'm slightly pissed. I tried to watch the Watergate Scandal thing on PBS last night but it forgot to start recording.
Forget tape. Even high cost tape units fail frequently. Just buy external USB drives and back up to that. If you recycle the drive 3 or 4 times, it covers the cost of a 50G tape (about $40). Faster and more reliable.
I was talking about our situation here.
How many of your tape drives jammed during that period? 1? 2?
A silo based of HD units instead of tapes would consume about the same amount of power as the tape unit. Yes, it wouldn't have as online random access as having 576 drives all going at once but it would still be faster than using tape.
Just replace tapes with drives and be done with it
Tape is on it's way out. For the following reasons:
(1) Storage capacity is not keeping up with drives,
(2) Tapes are not cheap and if you end up re-using it more than 3x, then a drive is cheaper
(3) Tape back up software is expensive, clunky, unreliable, slow
(4) Recovering from tape has always been a VERY painful experience,
(5) Tape units have more moving parts than a hard drive and, in my experience with an ATL unit, fail more frequently
(6) When was the last time you heard of a home user backing their stuff up to tape?
Next he'll be telling us the x86 instruction set is elegant!
Ha ha ha ha! Risc has more advantages than just being closer to the 'hardware' it's also generally a more elegant instruction set.
The x86 instruction set has barely any consistency (other than being crap). It is NOT elegant. It does not allow compilers to do much code optimization to utilize registers better (since it barely has any).
For a good instruction set, check out the ARM.
We have, unfortunately, been stuck with this dog of an instruction set due to intel. It's hideous.
Next he'll be telling us that the ISA bus is the best thing since sliced cheese (or is it fondue), and that we never had any need for PCI etc etc etc.
I read the script off the net some time ago. I recall, as I was reading it, cringing in agony at some of the bad, bad, bad, bad, puns and jokes. I was relieved when I finished reading it.
The ONLY reason I went to see it was to find out how truely bad it was. And it was. Truely bad.
It's just like watching Jerry Springer, you know it's bad but you've just got to hold on to see how bad it can be.
The theater was full of moans, groans and towards the end, sighs in sheer exasperation and, dare I say it, wails of pain.
It followed NONE of the star trek story standards. E.g.
1. Somehow Data is able to 'back himself up' to another android that magically got found. Somehow they were never able to do that in TNG.
2. Extreme violation of the prime directive,
3. Dune buggies (WTF were they thinking?)
4. A Picard clone?
5. A Data clone?
6. Yet another Enterprise gets destroyed. What are we on to now? Enterprise-Q?
7. The Romulans and Federation working together?
The only saving grace was that they took out the line "Is that your final question?".
8. Transferring Data's 'catra' to B4? WTF?
The actors knew how to play their parts, it just seemed that they didn't want to. After reading the script, I'm not surprised. There's only so much you can do with special effects (did ANYONE like Star Wars: AOTC?).
I hear the director didn't even read any of the tech bibles.
Well, I've been working on an online game for the last year or so and we're definitely using UDP. Mainly because we can decide on re-transmission on dataloss in a deterministic manner. One of the other disadvantages of TCP (correct me if I'm wrong) is that packet sizes are non-deterministic. Sometimes you can receive all the data sent, but essentially it's just a stream with you getting as much data has been acquired at that time. This results in having to do some local buffering to get all of the packet that was sent! Didn't have to do that with UDP.
I got a chance to see the version floating around the net. The quality of the image ain't that good but it matches the movie.
It's terrible. One of the worst movies I've seen this year. Forget going to see it, wait for it to be on HBO and go see spider man again. It deserves your money much more than this pile of drivvel.
Do you have any performance measurements? I did a simple file copy and timing, got around 990K/sec over USB1 so I'd like to know what improvement there actually is with USB2 before I go out an buy a card.
I don't know if you've noticed but there IS something called USB 2.0. It's as fast as firewire. I have yet to confirm this though.
Since USB is more available on real computers than firewire, it seems the most flexible approach.
Slashdot Mirror
I was in Croydon once for a few weeks. Oh man it was awful.
N64 hands down.
Nice straight forward architecture. High speed processors, for the time. Decent amount of memory, for the time. Cartridge instead of CD (access time, transfer rates).
Well laid out motherboard (nice curvey lines to reduce signal reflections).
Unified memory, decent MIPS core. Decent graphics performance and a *lot* could be done with the RSP if you could get the microcode source from Nintendo.
Libraries were great. Minimal in footprint, Nintendo gave debug (anally retentive) libraries as well optimized release builds. Helped find bugs easily.
Debugging was decent, once we got off the SGI machines.
PS1 was, well, a PS1. Pretty crap really. GFX performance was reasonable, though. Audio was 'free' but crap.
Saturn was a mess. 2nd CPU slapped on at the last minute and some engineer in Japan made a serious mistake in the glue logic that caused it to be slower than molases. There was something odd about the polys on that machine (or was is PS1?) they were quads instead of tris, but with only top-left, bottom-right UVs.
Dreamcast was nice enough. Just a shame Microsoft used Sega for their first implementation of wince and fucked them over in the process, as well as offending pretty much any developer by insisting they used that nonsense.
Of course, I also had access to the full source code, symbol tables and a debug kit. So, that made it pretty easy to find the buffer overrun. It was actually in a wide string copy. Src, Dst and data were all on the stack.
I once used a buffer overrun in a ps2 game I was working on to allow me to download a patch when no patching mechanism was in place.
This was very handy for creating some small additions to the game.
Never patched the hole. But then again, the game didn't sell that well.
Well, those pro's need to get with the times. Analog had its place and time and is no longer needed (I'm sure I'll get flamed for that).
Yes, apparently, analog sounds better but who cares? I mean, you lose quality on every analog duplication pass. Every duplication of a digital produces, surprise surprise, a 100% identical duplicate of the original.
Now that most professional audio is sampled and 192K plus, what's the deal? What's so good about analog? Does it sound "smoother"? If so, why? Is it because of higher harmonics or is it because the technology introduces a "smoother", "softer" sound due to it's flaws?
Hanging on to this technology is very nostalgic, I'm sure. But even the horse drawn carriage got replaced by better technology.
Can anyone explain why Intel do not produce 90nm versions of those chips? I would expect that the change in production method would further improve the power dissipation of these chips. Like said in the article, most of these chips are used for embedded systems and, as such, would benefit from reduced power consumption. BTW, the shuttle still uses a 386 processor. From what I understand, from a very helpful guide at JSC visitor center, is that the shuttle uses less than 50% of the CPU time of the 386 and it has about 256K (yes, K) of memory.
Yeah, I had that happen to me once. Then I just picked up the cell phone.
Americans have always been particularly atrocious at picking correct case. Maybe it should be iNteRnEt. I suppose, we should just make everything uppercase and be done with it. It would save 26 characters out of the ASCII set we could use for emoticons!
However, Windows is typically accessing more than one file. Part of the slow down in boot times, I suspect, is due to the thrashing caused on the disk array. It's most certainly not CPU bound. If there are multiple seeks outstanding (versus linear reads) then there will be a significant performance benefit from doing independant seeks. Now, I don't have any figures to show what this would do. Then again, I don't have any figures to the contrary. Whether or not a raid array has it's own independant processor is irrelevant in my opinion. The amount of overhead *SHOULD* be tiny when dealing with a mirrored, or striped, array. I mean, how much processing does it take to figure out which block is going to be read? Raid-5 will always benefit from a seperate processor. Mind you, the parity calculation is so trival, even a 486 can do it at a fair clip (check the Linux bootlogs for an old system to see the speed). All the experiences I have had with hardware based raid controllers have been less than satisfactory. Dell shipped a PERC-3 controller card that could barely sustain 15MB/sec off a 10K drive array! That was RAID-5 but come on folks! Raid-5 isn't that hard to calculate.
Does the raid driver typically allow two independent seeks on the seperate drives with mirroring enabled? I would expect this to significantly improve things like boot times as most of the time is spent seeking for new data. I would have expected a 50% drop in seek. If they don't do independent seeks, why the hell not?
I hear, with baited breath, all this stuff about OLEDS and how they'll have us get awesome huge displays on our livingroom walls.
I WANT IT RIGHT NOW! GET YOUR ARSES IN GEAR AND GET IT IN MY LIVINGROOM!
I just bought a 37" LCD panel for 4k but I *REALLY* want an 80" panel for the same price.
HURRY UP! PLEASE!
Ewh! Yuckky. Teach them a *REAL* assembly language like MIPS or ARM.
x86 is just an abortion that got to full term.
I think you're reading *WAY* more in to this than required. I worked at DMA and they were never very tight on keeping track of resume's received and demo disks. In the early years, there was talk of a game that goes along the lines of somehow hurting sheep. This was a David 'Oz' Osbourne idea. This is what, I understand, eventually morphed in to GTA.
Channel switching is SO PAINFULLY SLOW. Sometimes I can press channel up 5 times, then down 3 times wait about 5 seconds then it will do them all in one go.
Just absolutely, unbelievably terribly slow programming. I would be embarrassed to work on such a project.
I don't know what sort of excuses Scientific Atlanta could bring for such a painfully slow product. I would love to hear why they are so slow. That should be good for a laugh.
The user interface is just frustrating. Having to press 'SELECT' instead of 'PLAY' when you're over a program you want to watch is just unforgivable.
You may be able to tell I'm slightly pissed. I tried to watch the Watergate Scandal thing on PBS last night but it forgot to start recording.
Forget tape. Even high cost tape units fail frequently. Just buy external USB drives and back up to that. If you recycle the drive 3 or 4 times, it covers the cost of a 50G tape (about $40). Faster and more reliable.
I was talking about our situation here. How many of your tape drives jammed during that period? 1? 2? A silo based of HD units instead of tapes would consume about the same amount of power as the tape unit. Yes, it wouldn't have as online random access as having 576 drives all going at once but it would still be faster than using tape. Just replace tapes with drives and be done with it
Tape is on it's way out. For the following reasons: (1) Storage capacity is not keeping up with drives, (2) Tapes are not cheap and if you end up re-using it more than 3x, then a drive is cheaper (3) Tape back up software is expensive, clunky, unreliable, slow (4) Recovering from tape has always been a VERY painful experience, (5) Tape units have more moving parts than a hard drive and, in my experience with an ATL unit, fail more frequently (6) When was the last time you heard of a home user backing their stuff up to tape?
Next he'll be telling us the x86 instruction set is elegant! Ha ha ha ha! Risc has more advantages than just being closer to the 'hardware' it's also generally a more elegant instruction set. The x86 instruction set has barely any consistency (other than being crap). It is NOT elegant. It does not allow compilers to do much code optimization to utilize registers better (since it barely has any). For a good instruction set, check out the ARM. We have, unfortunately, been stuck with this dog of an instruction set due to intel. It's hideous. Next he'll be telling us that the ISA bus is the best thing since sliced cheese (or is it fondue), and that we never had any need for PCI etc etc etc.
I read the script off the net some time ago. I recall, as I was reading it, cringing in agony at some of the bad, bad, bad, bad, puns and jokes. I was relieved when I finished reading it. The ONLY reason I went to see it was to find out how truely bad it was. And it was. Truely bad. It's just like watching Jerry Springer, you know it's bad but you've just got to hold on to see how bad it can be. The theater was full of moans, groans and towards the end, sighs in sheer exasperation and, dare I say it, wails of pain. It followed NONE of the star trek story standards. E.g. 1. Somehow Data is able to 'back himself up' to another android that magically got found. Somehow they were never able to do that in TNG. 2. Extreme violation of the prime directive, 3. Dune buggies (WTF were they thinking?) 4. A Picard clone? 5. A Data clone? 6. Yet another Enterprise gets destroyed. What are we on to now? Enterprise-Q? 7. The Romulans and Federation working together? The only saving grace was that they took out the line "Is that your final question?". 8. Transferring Data's 'catra' to B4? WTF? The actors knew how to play their parts, it just seemed that they didn't want to. After reading the script, I'm not surprised. There's only so much you can do with special effects (did ANYONE like Star Wars: AOTC?). I hear the director didn't even read any of the tech bibles.
Try this site. It has at least some information.
http://www.old-computers.com/
Well, I've been working on an online game for the last year or so and we're definitely using UDP. Mainly because we can decide on re-transmission on dataloss in a deterministic manner. One of the other disadvantages of TCP (correct me if I'm wrong) is that packet sizes are non-deterministic. Sometimes you can receive all the data sent, but essentially it's just a stream with you getting as much data has been acquired at that time. This results in having to do some local buffering to get all of the packet that was sent! Didn't have to do that with UDP.
AOTC is like a subway sandwich: Cheesy Dialog, Hammed up acting and a total turkey. Don't waste your money or 2 1/2 hours of your life on this one.
I got a chance to see the version floating around the net. The quality of the image ain't that good but it matches the movie. It's terrible. One of the worst movies I've seen this year. Forget going to see it, wait for it to be on HBO and go see spider man again. It deserves your money much more than this pile of drivvel.
Do you have any performance measurements? I did a simple file copy and timing, got around 990K/sec over USB1 so I'd like to know what improvement there actually is with USB2 before I go out an buy a card.
I don't know if you've noticed but there IS something called USB 2.0. It's as fast as firewire. I have yet to confirm this though. Since USB is more available on real computers than firewire, it seems the most flexible approach.