The internals of AMD's and Intel's chips these days are far from being "old architecture". Rather, they are quite cutting edge. The only luggage in there that most people would like to see go away is the 80x86 instruction decoder which converts CISC instructions into the micro-op RISC like instructions that the CPU core really uses. These decoders take up a lot of space and a lot of power.
And we can remove those pesky 80x86 decoders in the CPU as soon as no one cares about any "installed software base". There isn't one company on the planet that could afford to change all its software from one CPU architecture to another overnight or for cheap. (And in some situations regarding legacy applications, porting the applications may damn near be impossible).
Transmeta had a neat idea about what to do with these pesky instruction decoders, but I haven't heard much from them in quite a while. Whatever happened to the Crusoe?
Not sure what card/platform you have, but I used to have tons of driver problems with 3D games with the RagePro line of cards, and after they ditched OS/2 support (along with about everyone else), I wasn't sure if my next card would be ATI or not.
But then I got the Radeon VIVO, and it was a completely different beast. I can't speak for all users, obviously, but I can say I've had zero issues with my ATI card (had for about 1.5 years now) under Windows98SE, Win2000 and XFree86 4.1/4.2. My dad has an All-In-Wonder Radeon which he uses under Win98SE with his DV camcorder. I've never had a driver issue with the Radeon line thus far.
Which begs the question: where are these driver problems? Are they specific to the WinME/XP drivers or what?
I don't see why there won't be. I play RtCW under Linux/XFree86 with my Radeon VIVO and it runs just fine at 1280x1024x32. The composite video in also works, as well as video capture. Give the GATOS people some credit, their Radeon drivers have performed better for me than any ATI Windows or OS/2 (back in the day) drivers ever did.
It really isn't a question of will _ATI_ release linux drivers, but will they release enough documentation so folks like GATOS can implement a driver in a reasonable amount of time.
Not entirely true. If you look into the active research in the area of fusion reactions, you'll find that there are what they call DT, DD, D3He and He3-He3 reactions. In that order, they contain about 75%, 35%, 5% and 0% total energy released in neutron form. The Holy Grail of nuclear energy is to make He3-He3 reactions economically viable. These reactions produce NO neutrons and He3 is actually very plentiful... on the lunar surface (verified by Apollo missions).
If you want more info, do a google search for "fusion he3 fti wisconsin". One article in particular: http://fti.neep.wisc.edu/FTI/pdf/fdm1131.pdf
There's one thing you will need to remember... Somebody called "Cyrix" used a comparative numbering scheme. I'd have more info, but it was so long ago
Well, that's an apples/oranges comment realy. Cyrix used such a numbering scheme to make their processors sound faster than they really were. AMD uses their numbering scheme to combat Intel's Marketing and FUD campaign to brainwash the majority of consumers into thinking that more MHz is faster, which sadly, works incredibly well.
In both cases, the informed buyer (or geek) wasn't fooled by either, and the real clockrate is easy to obtain anyway. I first thought it was a silly move for AMD, but after a few people telling me that the Pentium4 is better than the Athlon because it runs at 2.2GHz, I can see why AMD did what they did.
When the Hammer is released, the MHz metric will be even more flawed, and hopefully, so much so, that it will be obvious to all (but I doubt it).
AMD has to make a seriously brave (or rash) departure from Intel compatibility?
Are you serious? The Hammer chips are AMD's decision on how to extend and improve the x86 platform. They cleaned up the instruction set, extended the number of registers, and made the registers truly general purpose. The x86-64 instruction set may be so popular that Intel has already licensed the x86-64 set from AMD. Ever heard of Yamhill?
The way I see it is that many more companies are going to prefer the logical x86-64 route, rather than the very expensive IA64 route. There is just too much proprietary and legacy code out there to be able to just walk away from x86 altogether. Especially if AMD delivers on both speed and price as well (which they probably will).
Only problem with some of these new motherboards with 3rd and 4th IDE channels is that they are usually implemented with some off the wall chipset unrelated to the BIOS or the typical southbridge (being HPT or Promise or something).
What I've seen happen (on an ASUS A7V133 board) is that Linux and Windows 2000 fail to find the Hard Disk if it is plugged into the Promise chip IDE slot, instead of the basic IDE slot. Windows98 and WindowsXP worked fine. I could fdisk the drive, but the disk would not show up on a BIOS scan for the hard drives and probably required some stupid Promise driver to get it to work, which would just be a nightmare for Linux. I moved the HDD to the standard IDE channel 0, and put both CDROM/burner on channel 1, and left the Promise 3/4th channels unused, and all works perfectly.
The other disadvantage with 4 IDE channels is that one still needs a single IRQ _per channel_, whereas you need only one IRQ for all 31 SCSI devices you can put on a U160 SCSI controller. You can forget using all those IDE channels, serial, parallel, USB, ethernet and firewire all in one box, unless you want to try and use ACPI (and that's an entirely separate can of worms).
Ah yes, but SCSI drives are capable of queueing and reordering commands to optimize performance, which just might make a difference in long time head/actuator wear.
Imagine if an elevator serviced floor stops in the order in which the buttons were pushed (IDE) versus hitting all the floors with buttons pushed going up and then going down (SCSI). Unless I am mistaken, IDE devices must process requests in the order it receives them, and any other devices on the same channel have to shutup until that device is unbusy.
This difference between IDE/SCSI not only affects performance, but can affect how the drive will wear to some extent.
Forget lunar solar power, look at lunar nuclear
on
Lunar Power
·
· Score: 1
This always gets overlooked but is a very interesting branch of research these guys are doing at the University of Wisconsin at the Fusion Technology Institute. http://fti.neep.wisc.edu/pubs?which=posters
Basically, boils down to this: we need highly renewable clean nuclear fusion power. The solution? He3-He3 fusion reactors (probably another 30-50 years off, but the potential is HUGE). The lunar surface is FULL of He3 (confirmed by Apollo missions). He3-He3 reactions produce NO Class A or Class C nulcear waste. And 1 ton of He3 would be able to produce 10,000 MWe-years of electricity. All you need to make this work is to perfect the reactor technology and find a cheap way of mining He3 off the lunar surface.
Best part is: mining for He3 through the surface can be done with robots and put in canisters sent back to earth. This can be done for MUCH MUCH less $$ than a lunar solar panel. Plus the power output is magnitudes more per unit of lunar surface area.
The presentation I got this material from is listed here: http://fti.neep.wisc.edu/FTI/POSTERS/glk_amsterd am . df
I have one of those Gateway Anykey-124 Programmable keyboards and they rock. I wish I had this keyboard at work on my Sun. No one I've seen makes a keyboard like this anymore: Two complete sets of function keys, directional arrow keys with diagonals (in addition to numeric keypad), FULL sized enter key (the proper size), no windows keys (two-Alts and two-Ctrls, imagine that!), and can be fully remappable and macro programmable via EEPROM in the keyboard itself (and backed up to a file via a DOS program).
I like this keyboard so much that I bought a few extras on eBay to put in my closet as backup for when this one bites the dust.
I cannot stand any of the newer keyboards with windows keys and stupid internet/email keys that can only be programmed with Windows drivers to do nothing more fancy than open up IE or Outlook. I want a keyboard that I can program vim macros onto and those macros persist in Windows or Linux. It's also a Godsend to be able to put the left control key back where it is supposed to be, where the CAPS LOCK is. (Who actually uses CAPS LOCK anyway???)
I've been really interested in using a bluetooth enabled Palm m505/m515 with my cellphone, but unfortunately, I can't find a bluetooth enabled GSM phone! Does anyone know of ANY GSM bluetooth enabled phones available in the US?
Well, one difference I know of is that OS/2's HPFS did not have user permissions, which NTFS does have. I think there was an enhanced version of HPFS called HPFS-386 which did though. I vaguely remember my tape backup software being able to support something called HFPS-386.
MS also added stuff to FAT16 to create FAT32, which took years before OS/2 and Linux were able to mount FAT32 volumes read/write. I had lots of "shared" FAT16 partitions just for data interchange between OSes until a few years ago.
I never thought film quality was much of an issue in a theater, or projector condition for that matter, until I saw Lord of the Rings: Fellowship of the Ring on opening night. 1 hour into the movie, the film slipped its track, went out of focus, made some bad noises, then stuck to the hot lens and melted in front of all our eyes (yellow-orange-blach spots, then nothing but white screen). They spliced the movie back together and in 15 minutes we were watching it again.
Weeks later a friend of mine went to same theater, and noticed the 30 second gap in the movie from the splice. That was their only copy, forever ruined since opening night. Ugh. I'll stick with DVD on my own setup if that's what $8 a ticket gets me.
This always confuses people. There are three closely related companies in Iowa: Iowa Network Services, NetINS, and Iowa Wireless. NetINS is the ISP, Iowa Wireless is GSM cellphones, Iowa Network Services (INS) is everything else.
(Their webpage is www.iowanetworkservices.com,
the ISP is www.netins.net).
Also, this installation in Clear Lake is using VDSL (very high speed DSL) on the order of 25Mbps. It can handle three MPEG channels at once. Source: my dad (one of the high-ups at INS).
I am an electrical engineer who does ASIC/FPGA design and DFT, and if there is one thing I can't emphasize enough, is that when using HDLs, think about the hardware implications and don't just write straight code like you would in a functional program.
I have seen numerous designs done by primarily FPGA designers which use the languages (esp VHDL) very liberally, which usually works fine for programmable devices where the compilers can make your code work as long as it fits and meets timing, but when you want to put that code into an ASIC, it's a nightmare (non-synchronous design, no thought about DFT). Just like when doing OO programming, you need to THINK about your design or objects first, then code it up in C++ or VHDL _last_. It's a "description" language. HDLs should be used to describe designs that have already been designed in your head or on paper. The synthesis tools can do very funny things with code that is even functionally correct but just syntactically awkward. Sometimes, you just have to write the HDL in a manner that gets you what you want from the synthesis tools. Sometimes, good code in = garbage out! Writing code in high level languages puts another layer of complexity into the problem.
We are currently investigating some of the new tools that are starting to pop up out there for high level hardware design. It appears to me that using high level languages makes the most sense when you want to do functional type designs, for instance, DSP chips. There it makes PERFECT sense: you describe your DSP functions and algorithms in C just like you would if implementing it purely in a software application, and the tools can translate that into a decent HDL description for a signal processing core. Other things which are more structural than functional, are better done in one of the HDL languages. But we'll see. Doing circuit design in high level languages like C and Java is a New Thing(tm) and so the performance of these tools yet on really large and complicated designs isn't well known yet.
But if you want to learn HDLs, I would recommend starting with Verilog. It's based on C and is syntactically much less complicated than VHDL. Verilog is also faster than VHDL when doing large simulations. And remember that Verilog/VHDL code always executes in PARALLEL, since you're describing blocks of hardware.
Slashdot Mirror
The internals of AMD's and Intel's chips these days are far from being "old architecture". Rather, they are quite cutting edge. The only luggage in there that most people would like to see go away is the 80x86 instruction decoder which converts CISC instructions into the micro-op RISC like instructions that the CPU core really uses. These decoders take up a lot of space and a lot of power.
And we can remove those pesky 80x86 decoders in the CPU as soon as no one cares about any "installed software base". There isn't one company on the planet that could afford to change all its software from one CPU architecture to another overnight or for cheap. (And in some situations regarding legacy applications, porting the applications may damn near be impossible).
Transmeta had a neat idea about what to do with these pesky instruction decoders, but I haven't heard much from them in quite a while. Whatever happened to the Crusoe?
"ATI finally got the drivers right"
Not sure what card/platform you have, but I used to have tons of driver problems with 3D games with the RagePro line of cards, and after they ditched OS/2 support (along with about everyone else), I wasn't sure if my next card would be ATI or not.
But then I got the Radeon VIVO, and it was a completely different beast. I can't speak for all users, obviously, but I can say I've had zero issues with my ATI card (had for about 1.5 years now) under Windows98SE, Win2000 and XFree86 4.1/4.2. My dad has an All-In-Wonder Radeon which he uses under Win98SE with his DV camcorder. I've never had a driver issue with the Radeon line thus far.
Which begs the question: where are these driver problems? Are they specific to the WinME/XP drivers or what?
I don't see why there won't be. I play RtCW under Linux/XFree86 with my Radeon VIVO and it runs just fine at 1280x1024x32. The composite video in also works, as well as video capture. Give the GATOS people some credit, their Radeon drivers have performed better for me than any ATI Windows or OS/2 (back in the day) drivers ever did.
It really isn't a question of will _ATI_ release linux drivers, but will they release enough documentation so folks like GATOS can implement a driver in a reasonable amount of time.
Not entirely true. If you look into the active research in the area of fusion reactions, you'll find that there are what they call DT, DD, D3He and He3-He3 reactions. In that order, they contain about 75%, 35%, 5% and 0% total energy released in neutron form. The Holy Grail of nuclear energy is to make He3-He3 reactions economically viable. These reactions produce NO neutrons and He3 is actually very plentiful... on the lunar surface (verified by Apollo missions).
If you want more info, do a google search for "fusion he3 fti wisconsin". One article in particular:
http://fti.neep.wisc.edu/FTI/pdf/fdm1131.pdf
Ack. Sorry about the italics, should have hit preview first! =)
There's one thing you will need to remember... Somebody called "Cyrix" used a comparative numbering scheme. I'd have more info, but it was so long ago
Well, that's an apples/oranges comment realy. Cyrix used such a numbering scheme to make their processors sound faster than they really were. AMD uses their numbering scheme to combat Intel's Marketing and FUD campaign to brainwash the majority of consumers into thinking that more MHz is faster, which sadly, works incredibly well.
In both cases, the informed buyer (or geek) wasn't fooled by either, and the real clockrate is easy to obtain anyway. I first thought it was a silly move for AMD, but after a few people telling me that the Pentium4 is better than the Athlon because it runs at 2.2GHz, I can see why AMD did what they did.
When the Hammer is released, the MHz metric will be even more flawed, and hopefully, so much so, that it will be obvious to all (but I doubt it).
AMD has to make a seriously brave (or rash) departure from Intel compatibility?
Are you serious? The Hammer chips are AMD's decision on how to extend and improve the x86 platform. They cleaned up the instruction set, extended the number of registers, and made the registers truly general purpose. The x86-64 instruction set may be so popular that Intel has already licensed the x86-64 set from AMD. Ever heard of Yamhill?
The way I see it is that many more companies are going to prefer the logical x86-64 route, rather than the very expensive IA64 route. There is just too much proprietary and legacy code out there to be able to just walk away from x86 altogether. Especially if AMD delivers on both speed and price as well (which they probably will).
Only problem with some of these new motherboards with 3rd and 4th IDE channels is that they are usually implemented with some off the wall chipset unrelated to the BIOS or the typical southbridge (being HPT or Promise or something).
What I've seen happen (on an ASUS A7V133 board) is that Linux and Windows 2000 fail to find the Hard Disk if it is plugged into the Promise chip IDE slot, instead of the basic IDE slot. Windows98 and WindowsXP worked fine. I could fdisk the drive, but the disk would not show up on a BIOS scan for the hard drives and probably required some stupid Promise driver to get it to work, which would just be a nightmare for Linux. I moved the HDD to the standard IDE channel 0, and put both CDROM/burner on channel 1, and left the Promise 3/4th channels unused, and all works perfectly.
The other disadvantage with 4 IDE channels is that one still needs a single IRQ _per channel_, whereas you need only one IRQ for all 31 SCSI devices you can put on a U160 SCSI controller. You can forget using all those IDE channels, serial, parallel, USB, ethernet and firewire all in one box, unless you want to try and use ACPI (and that's an entirely separate can of worms).
Ah yes, but SCSI drives are capable of queueing and reordering commands to optimize performance, which just might make a difference in long time head/actuator wear.
Imagine if an elevator serviced floor stops in the order in which the buttons were pushed (IDE) versus hitting all the floors with buttons pushed going up and then going down (SCSI). Unless I am mistaken, IDE devices must process requests in the order it receives them, and any other devices on the same channel have to shutup until that device is unbusy.
This difference between IDE/SCSI not only affects performance, but can affect how the drive will wear to some extent.
branch of research these guys are doing at the University of Wisconsin at the Fusion Technology Institute.
http://fti.neep.wisc.edu/pubs?which=posters
Basically, boils down to this: we need highly renewable clean nuclear fusion power. The solution? He3-He3 fusion reactors (probably another 30-50 years off, but the potential is HUGE). The lunar surface is FULL of He3 (confirmed by Apollo missions). He3-He3 reactions produce NO Class A or Class C nulcear waste. And 1 ton of He3 would be able to produce 10,000 MWe-years of electricity. All you need to make this work is to perfect the reactor technology and find a cheap way of mining He3 off the lunar surface.
Best part is: mining for He3 through the surface can be done with robots and put in canisters sent back to earth. This can be done for MUCH MUCH less $$ than a lunar solar panel. Plus the power output is magnitudes more per unit of lunar surface area.
The presentation I got this material from is listed here:
http://fti.neep.wisc.edu/FTI/POSTERS/glk_amster
I have one of those Gateway Anykey-124 Programmable keyboards and they rock. I wish I had this keyboard at work on my Sun.
No one I've seen makes a keyboard like this anymore:
Two complete sets of function keys, directional arrow keys
with diagonals (in addition to numeric keypad), FULL sized
enter key (the proper size), no windows keys (two-Alts and two-Ctrls, imagine that!), and can be fully remappable and macro programmable via EEPROM in the keyboard itself (and backed up to a file via a DOS program).
I like this keyboard so much that I bought a few extras on eBay to put in my closet as backup for when this one bites the dust.
I cannot stand any of the newer keyboards with windows keys and stupid internet/email keys that can only be programmed with Windows drivers to do nothing more fancy than open up IE or Outlook. I want a keyboard that I can program vim macros onto and those macros persist in Windows or Linux. It's also
a Godsend to be able to put the left control key back where it is supposed to be, where the CAPS LOCK is. (Who actually uses CAPS LOCK anyway???)
I've been really interested in using a bluetooth enabled Palm m505/m515 with my cellphone, but unfortunately, I can't find a bluetooth enabled GSM phone! Does anyone know of ANY GSM bluetooth enabled phones available in the US?
Well, one difference I know of is that OS/2's HPFS did not have user permissions, which NTFS does have. I think there was an enhanced version of HPFS called HPFS-386 which did though. I vaguely remember my tape backup software being
able to support something called HFPS-386.
MS also added stuff to FAT16 to create FAT32, which took years before OS/2 and Linux were able to mount FAT32 volumes read/write. I had lots of "shared" FAT16 partitions just for data interchange between OSes until a few years ago.
I never thought film quality was much of an issue in a theater, or projector condition for that matter, until I saw Lord of the Rings: Fellowship of the Ring on opening night. 1 hour into the movie, the film slipped its track, went out of focus, made some bad noises, then stuck to the hot lens and melted in front of all our eyes (yellow-orange-blach spots, then nothing but white screen). They spliced the movie back together and in 15 minutes we were watching it again.
Weeks later a friend of mine went to same theater, and noticed the 30 second gap in the movie from the splice. That was their only copy, forever ruined since opening night. Ugh. I'll stick with DVD on my own setup if that's what $8 a ticket gets me.
This always confuses people. There are three closely related companies in Iowa: Iowa Network Services, NetINS, and Iowa Wireless. NetINS is the ISP, Iowa Wireless is GSM cellphones, Iowa Network Services (INS) is everything else.
(Their webpage is www.iowanetworkservices.com,
the ISP is www.netins.net).
Also, this installation in Clear Lake is using VDSL (very high speed DSL) on the order of 25Mbps. It can handle three MPEG channels at once. Source: my dad (one of the high-ups at INS).
I am an electrical engineer who does ASIC/FPGA design and DFT, and if there is one thing I can't emphasize enough, is that when using HDLs, think about the hardware implications and don't just write straight code like you would in a functional program.
I have seen numerous designs done by primarily FPGA designers which use the languages (esp VHDL) very liberally, which usually works fine for programmable devices where the compilers can make your code work as long as it fits and meets timing, but when you want to put that code into an ASIC, it's a nightmare (non-synchronous design, no thought about DFT). Just like when doing OO programming, you need to THINK about your design or objects first, then code it up in C++ or VHDL _last_. It's a "description" language. HDLs should be used to describe designs that have already been designed in your head or on paper. The synthesis tools can do very funny things with code that is even functionally correct but just syntactically awkward. Sometimes, you just have to write the HDL in a manner that gets you what you want from the synthesis tools. Sometimes, good code in = garbage out! Writing code in high level languages puts another layer of complexity into the problem.
We are currently investigating some of the new tools that are starting to pop up out there for high level hardware design. It appears to me that using high level languages makes the most sense when you want to do functional type designs, for instance, DSP chips. There it makes PERFECT sense: you describe your DSP functions and algorithms in C just like you would if implementing it purely in a software application, and the tools can translate that into a decent HDL description for a signal processing core. Other things which are more structural than functional, are better done in one of the HDL languages. But we'll see. Doing circuit design in high level languages like C and Java is a New Thing(tm) and so the performance of these tools yet on really large and complicated designs isn't well known yet.
But if you want to learn HDLs, I would recommend starting with Verilog. It's based on C and is syntactically much less complicated than VHDL. Verilog is also faster than VHDL when doing large simulations. And remember that Verilog/VHDL code always executes in PARALLEL, since you're describing blocks of hardware.