Note: I came from doing C and Java (not C++) before getting a job using Obj-C. And I have no C# experience.
Here's what designing in Obj-C looks like compared to Java and C: 1) Obj-C is not typesafe in the way java is. Instead, the compiler will try it's hardest to warn you if it looks inconsistent, kinda like C with tons of void*.
Why this is good: This means that when you make a framework, you are expected to either 1) declare a type of object you want to accept so others can import its header OR 2) make code that is designed to detect if the object you're going to call methods on supports the method you're about to call because you just said you'll take anything that comes in.
Why this is bad: It's as typesafe as C. Take this as a plus and a minus. People gung-ho about Java are all about type-safety, so this may scare them.
2) Delegation. Because of the "id" type (like classtype java.lang.Object), you're expected to accept objects that need to be directly notified about what's going on in your object instead of subclassing whenever possible. Say I have a Table View UI widget. There are two delegates: one named "delegate" and one named "datasource".
In the API it's declared that whenever it needs to know how many rows, it'll call numberOfRows against "datasource." It'll also call "tableView:objectValueForTableColumn:row:" against the datasource. These two are required in order for the table view to work. Datasource can be any object. There is no type, you simply plug it in and it works.
At the same time, when people do stuff with the tableview, it'll check that the delegate can accept messages and send them. So if I need to know that a tablecolumn moved, I'll simply add a method tableViewColumnDidMove: to the delegate and the tableview will notify me. Less subclassing. More plugging stuff together.
Note that it makes it easy to see that the delegate will handle most UI events, while the datasource mentioned strictly handles getting data to the tableview widget.
Why this is good: The creator of the framework can setup the division between types of events in a way that makes sense.
In addition, there is less subclassing, so that you're spending more time putting methods together that make your implementation special rather than making different subclasses of TableView that differ only in what section of the type heirarchy they can send to.
Finally, this also cleans up your code a little more in that the alternative, which would have been explicitly registering with observers tends to happen less. Instead of making the method in your delegate and then doing add/remove Observer for each event you want to subscribe to. You simply set the delegate and write all the methods you care about.
Why this is bad: Sometimes you can't tell why you're not receiving the events as a delegate, only to find out that you mispelled "tableView:didClickTableColumn:" as "tableView:didClickTableColunm:".
3) Key-Value Coding It's a interesting concept in that it basically says there's a convention which you can write code in that the method setValue:forKey: will allow you to access your object's instance/state variables as if it were a dictionary/hashtable, where the key is a string.
Why this is good: You can programmatically access an object's data without hardcoding in everything. In addition, it enables Key-Value Observation to build a system of bindings that minimizes the amount of code you need to set up connections for UI elements.
Why this is bad: No reason I can see.
There's more, but I'm tired and my writing ability is starting to go south:P
Okay, go into the bios, and disable all the devices you're not using. Like serial, parallel, sound, usb (if you don't need it). You want to free up as many IRQs as possible, and have each SATA card on it's own PCI interrupt line.
And then try booting with the SATA card in different slots. I had this problem with trying to put 2 SCSI cards on my old board which had too much stuff on it to begin with.
Note, while you can easily get 1TB drives, they max out at around 85MB/sec for data transfer. Older drives still have a fair amount of speed based off what I remember from my past drives. 20GB can maybe 15MB/sec. 40GB gets around 30MB/sec. 80GB gets probably 45MB/sec.
If you take 10 of these drives and stripe 5 of them together, and then mirror them across the other 5, you're bound to be able to build a file server which can now serve much more data to multiple machines.
If you take 100 of these and use ZFS, which should more reasonably mirror and strip, you're able to build a file server which will be much more expensive to power and set up, but more reliable because each drive that dies is a smaller percentage of the total, and accessing all these drives in parallel will be magnitudes faster than a small set of 1TB drives.
That's the advantage point of the massive array of crappy drives.
Wait increasingl common for people to bump up against the 4GB boundary? Really?
How many people have 4GB ram these days? Not that many. I mean, I work daily as a mac developer and most of our dev machines even are 2GB ram. There's one guy who has 7GB in his Mac Pro, but that's an outlier.
And, most importantly, 32-bit apps get 4GB per process right now. I repeat, it's 4GB per process, not for the whole machine. How many apps do you run daily use up 4GB on their own?
I'm sorry, how is screwing recent customers by not supporting a 2 year old machine, and screwing current customers (because 64-bit wastes cache space in the general case) a good idea?
ARM competes with Intel in the embedded market by: 1) Licensing the core design to be manufactured by the company using the core in their designs. 2) Making core designs that have 1 or 2 magnitudes less power consumption.
I believe ARM, MIPS, and PPC are the major players in the embedded market for the same reason.
Essentially, Intel has no stake in the high end embedded CPU market except as a manufacturer of ARM-based Xscale chips when they still made those.
You're right, I threw 50 out there as a guess since I didn't have a datasheet at hand and it had been a while since I read any datasheets regarding memory.
Now that I looked up a datasheet for the Samsung K9LAG08U0M (the NAND chip in the 8gb iPod and iPhone), and Toshiba's NAND flash interface design guide (kinda old though), I found some additional interesting things.
1) Assuming we're using NAND flash, many large NAND Flash chips are actually 4GB NAND Flash chips stacked internally, with multiple chip enable lines. This means that we're kinda forced into not doing simultaneous access for high density chips past 4GB. The 8GB one is 2 4GB chips stacked in the same package. The 16GB one is 4 chips stacked.
2) There appears to be a standard interface for NAND Flash across manufacturers where 528 bytes are written out at a time in small block mode and 2112 in large block mode. And it has a small block and large block mode. It seems to max out at 4GB.
3) To access a single 4GB chip, you definetely need unique IO0-7 and CE. 9 lines. You may be able to share CLE, ALE, Ready, WE, RE if you're always writing to blocks at the same time. This isn't true when a block fails writing. So you shouldn't share these either. Makes for a total of 14 unshared lines. Obviously shared lines are Power, Ground, Write Protect.
So, you're right, for a bus to NAND connection, it wouldn't be too bad to have a controller that provides 14*N lines, where N is the number of chips to access simultaneously. The board layout difficulty would still grow significantly as you add more chips though.
Adding a DRAM cache to help reordering, buffering, and deferring block checks would also be painful. Micron says for a 64MB SDRAM chip, you'll need 12 address lines, up to 16 Data lines, and about 8 more control lines. Pretty darn ugly. That's probably what made me incorrectly assume 50 lines.
There is actually no guarentee that they're all being accessed in parallel. The reason for this is because the block size for each chip is larger than the normal LBA block size. Which means that either you cache this for a while in DRAM (less likely), or you write back a merged block (more likely).
Normally, when you access a memory chip, you typically have all the lines(wires) tied together except for a chip select, which tells the chip, you're the one being accessed. This is to reduce the number of lines coming from a controller because IO lines are expensive to make. Hence why USB drives that are dual-channel are much more expensive and rare.
So, an example would be, for single channel it takes 50 lines total to connect to a single NAND chip. 51 lines to connect to 2 NAND chips. 52 lines to connect to 3 NAND chips.
What you're asking for, simultanious access to all NAND chips would be.... 50 lines to connect to a single NAND chip. 100 lines to connect to 2 NAND chips. 150 lines to connect to 3 NAND chips. Pretty crazy huh?
Adding in the lines to support DRAM would increase the cost even more.
Aside from increasing chip costs, adding in lines would make the board harder to layout to prevent crosstalk and corruption. It's the same reason why it's rare to find motherboards with more than 4 DIMM slots. It's hard to layout that many lines.
Overall, it'd be nice if we could cache and package each block in DRAM and write/read them from NAND in parallel. But it increases development costs significantly. Probably by whole number factors.
There's nothing in ATA that is really specific to mechanical drives since LBA basically addresses it as an array anyways.
Additionally, typical NAND chips are 20MB/sec. While NAND is solid state, it compares unfavorably to, say DRAM. There are a few chips on the market that go as high as 50MB/sec, but they're rare. And even then, ATA66 would still be enough to connect to it.
Yup, you're clueless. In terms of SDK, the iPhone is about the worst there is among modern phone platforms. Actually, no matter how much you don't like the iPhone's SDK restrictions, Verizon/Qualcomm's restrictions are far worse.
BREW (Qualcomm's phone platform) requires all apps to be signed. A developer cert is only given by Qualcomm. And requires the actual dev phones be sent in to be tweaked by Qualcomm so you can download to them for testing. This is, of course, after you've applied and been certified by Qualcomm to be allowed to develop.
Finally, once you've developed your program. You'll need to submit it for certification.
And once it's been certified, you need to convince Verizon to actually post it on the store.
There's fees at every level, of course.
And there's so many more of these phones than there are Symbian, iPhone, Windows Mobile, combined.
So, I can pick turing machines that require more space than you can offer. I probably just suck at proofs or don't remember correctly what defines a turing machine, but doesn't your statement also mean some processors/languages normally assumed to be turing machines are not because there exist bigger ones with more ram?
The way I'm seeing it is that given an infinite amount of RAM, and then either a FPGA configured to be a CPU through Verilog or any other CPU (say a R3000), they're either both turing machines or not.
Without a RAM limitation, any given set of gates and interconnections can be put onto a FPGA either directly, or emulated through a simpler set of gates and interconnects on the FPGA assisted by a freakin' huge chunk of software dumped into "infinite RAM".
Actually, we don't even need to be looking back. Considering the Asus EEE is a "current" computer using what amounts to a 650 Mhz P3, it's fairly clear that most people are buying machine that are far overspeced for their needs.
Qualcomm didn't have to patent anything specific in order to impede WCDMA. They had the patents from the beginning because of how much WCDMA borrows from IS-95 (the original cdmaOne). Fundamentally, the radio design will be similar despite the number of years between when IS-95 was developed and when FOMA/WCDAM was developed.
Verizon and Sprint would both be stupid to not use EVDO since, as the first letter suggests, it's simply an evolution from IS-95. From what I read, EVDO was literally a software upgrade to their base stations.
Qualcomm would of course push EVDO considering they already had a working product AND had existing deployments in Australia (telestra) and the US (verizon/sprint). It's hard to resist the fact that when you're Qualcomm and can advertise that "hey, check it out, 3G works now" and point at the failure that was NTT's initial WCDMA deployment.
I acknowledge that UMTS is faster than EVDO Rev0. I acknowledge that both Verizon and Qualcomm have been evil in their business tactics (witness the Motorola v710 bluetooth fiasco, and the general CDMA patent lawsuits respectively).
But as a technology, it's hard to find fault with EVDO, especially given the circumstances. While it'd be nice to have one phone technology world-wide, as a consumer the benefit of EVDO over UMTS is too big: * An EVDO based phone will always have better battery life compared to a UMTS/GSM phone given the same battery technology and chipset design generation. This is because EVDO based phones are simpler to make and have less electronics to power since the radio for EVDO is the same as the radio for IS-95, so you can switch down to lower speeds to save power when you don't need data. A UMTS/GSM phone requires currently, a chipset to handle GSM, and then a secondary coprocessor to handle WCDMA. * An EVDO based phone will also have better reception and voice quality overall until a equally sized UMTS network is in place. This is because until AT&T can build up an entirely new network from scratch, you'll be using GSM whenever possible to keep the load to a minimum until they can debug it all. I don't expect this to finish for at least another 5 years. Look at how long it took for them to turn off their TDMA network. * The majority of phones will not require speeds faster than EVDO provides. In fact, most phones right now probably can't even use the speed available. Those of my friends who have UMTS phones on AT&T must tether to actually make full use of the speed since the onboard CPU just can't do anything with data coming in that fast. It's like watching a guy with a 486 try to run bittorrent with his personal OC-42. A waste.
Given the facts, I'm still a Verizon subscriber (although my phone is hacked so much it's pretty amusing), and my iPhone is being used as a slightly thick iPod Touch.
However, while 3G UMTS uses W-CDMA rather that GSM's TDMA, it is not supported by Qualcomm.
WTF? Uh no.
Qualcomm might be crazy about locking people in, but there is no incompatible WCDMA from Qualcomm. Their WCDMA implementation is just another implementation of the standard.
And you got it sorta backwards when you say "For the 3G of mobile networks, 2G GSM and 2G CDMA2000 carriers were supposed to unify the world under one new standard: W-CDMA UMTS." While GSM networks will move to UMTS/HSDPA, and IS-95/CDMA2000/EVDO will progress to EVDO Rev A, there exists a chipset from Qualcomm that provide access to UMTS/WCDMA and EVDO/CDMA2000 in one phone. There is no reason EVDO networks would be moving to UMTS, as CDMA2000 have an easy upgrade to EVDO which is 3G and available widely as of like 3 years ago.
I believe that in addition to AFLT, the Qualcomm chipset used in the Kindle has GPSOne/AGPS built in. AGPS uses the AFLT to ask the towers to download almanac data to fast-start an actual GPS satellite receiver, or process the fragments received by the satelite to narrow down the location to the same resolution as a standalone GPS, without the startup time and delays.
This means that within a 3 seconds, you'd have a general idea which 1 mile block you're on, within a 7 more seconds, you should have an actual GPS fix. (instead of downloading the ephemeris for 30 seconds and then calculating, which is what a standalone unit would do.)
Yeah, my thought was more along the lines of "if we were to build a pda phone, what do we need?". Therefore having both EVDO data and voice were considered important.
Slashdot Mirror
I graduated as a CS major several years ago and recall being the only one of my friends, who were primarily EE, who could solder. It's sad really.
Most of them struggled to get two wires connected, while I could have done something like this:
http://www.mod-chip.bz/PS2/images/duochip/duo_gh006.jpg
Note: I came from doing C and Java (not C++) before getting a job using Obj-C. And I have no C# experience.
:P
Here's what designing in Obj-C looks like compared to Java and C:
1) Obj-C is not typesafe in the way java is. Instead, the compiler will try it's hardest to warn you if it looks inconsistent, kinda like C with tons of void*.
Why this is good: This means that when you make a framework, you are expected to either
1) declare a type of object you want to accept so others can import its header
OR
2) make code that is designed to detect if the object you're going to call methods on supports the method you're about to call because you just said you'll take anything that comes in.
Why this is bad: It's as typesafe as C. Take this as a plus and a minus. People gung-ho about Java are all about type-safety, so this may scare them.
2) Delegation. Because of the "id" type (like classtype java.lang.Object), you're expected to accept objects that need to be directly notified about what's going on in your object instead of subclassing whenever possible.
Say I have a Table View UI widget. There are two delegates: one named "delegate" and one named "datasource".
In the API it's declared that whenever it needs to know how many rows, it'll call numberOfRows against "datasource."
It'll also call "tableView:objectValueForTableColumn:row:" against the datasource. These two are required in order for the table view to work. Datasource can be any object. There is no type, you simply plug it in and it works.
At the same time, when people do stuff with the tableview, it'll check that the delegate can accept messages and send them. So if I need to know that a tablecolumn moved, I'll simply add a method tableViewColumnDidMove: to the delegate and the tableview will notify me. Less subclassing. More plugging stuff together.
Note that it makes it easy to see that the delegate will handle most UI events, while the datasource mentioned strictly handles getting data to the tableview widget.
Why this is good:
The creator of the framework can setup the division between types of events in a way that makes sense.
In addition, there is less subclassing, so that you're spending more time putting methods together that make your implementation special rather than making different subclasses of TableView that differ only in what section of the type heirarchy they can send to.
Finally, this also cleans up your code a little more in that the alternative, which would have been explicitly registering with observers tends to happen less. Instead of making the method in your delegate and then doing add/remove Observer for each event you want to subscribe to. You simply set the delegate and write all the methods you care about.
Why this is bad: Sometimes you can't tell why you're not receiving the events as a delegate, only to find out that you mispelled "tableView:didClickTableColumn:" as "tableView:didClickTableColunm:".
3) Key-Value Coding
It's a interesting concept in that it basically says there's a convention which you can write code in that the method
setValue:forKey: will allow you to access your object's instance/state variables as if it were a dictionary/hashtable, where the key is a string.
Why this is good:
You can programmatically access an object's data without hardcoding in everything.
In addition, it enables Key-Value Observation to build a system of bindings that minimizes the amount of code you need to set up connections for UI elements.
Why this is bad:
No reason I can see.
There's more, but I'm tired and my writing ability is starting to go south
Okay, go into the bios, and disable all the devices you're not using. Like serial, parallel, sound, usb (if you don't need it). You want to free up as many IRQs as possible, and have each SATA card on it's own PCI interrupt line.
And then try booting with the SATA card in different slots. I had this problem with trying to put 2 SCSI cards on my old board which had too much stuff on it to begin with.
Note, while you can easily get 1TB drives, they max out at around 85MB/sec for data transfer.
Older drives still have a fair amount of speed based off what I remember from my past drives. 20GB can maybe 15MB/sec. 40GB gets around 30MB/sec. 80GB gets probably 45MB/sec.
If you take 10 of these drives and stripe 5 of them together, and then mirror them across the other 5, you're bound to be able to build a file server which can now serve much more data to multiple machines.
If you take 100 of these and use ZFS, which should more reasonably mirror and strip, you're able to build a file server which will be much more expensive to power and set up, but more reliable because each drive that dies is a smaller percentage of the total, and accessing all these drives in parallel will be magnitudes faster than a small set of 1TB drives.
That's the advantage point of the massive array of crappy drives.
Try using just one card, and don't boot off it.
Then, get yourself SATA Port Multipliers.
Since that means you can chain 5 drives per sata port on your host adapter, you can easily get 20 off a 4 port adapter using 5 multiplers.
http://www.addonics.com/products/host_controller/ad5sahpm-e.asp
He said opting.... which means the users chose to use Mac. Doesn't mean Linux wasn't an option.
Wait increasingl common for people to bump up against the 4GB boundary? Really?
How many people have 4GB ram these days? Not that many.
I mean, I work daily as a mac developer and most of our dev machines even are 2GB ram. There's one guy who has 7GB in his Mac Pro, but that's an outlier.
And, most importantly, 32-bit apps get 4GB per process right now. I repeat, it's 4GB per process, not for the whole machine. How many apps do you run daily use up 4GB on their own?
I'm sorry, how is screwing recent customers by not supporting a 2 year old machine, and screwing current customers (because 64-bit wastes cache space in the general case) a good idea?
Expansion pack?? Doesn't this make it like 10.5.4 instead of 10.6?
Uh... because the first Intel iMac and MacBook Pro are 32-bit only?
ARM competes with Intel in the embedded market by:
1) Licensing the core design to be manufactured by the company using the core in their designs.
2) Making core designs that have 1 or 2 magnitudes less power consumption.
I believe ARM, MIPS, and PPC are the major players in the embedded market for the same reason.
Essentially, Intel has no stake in the high end embedded CPU market except as a manufacturer of ARM-based Xscale chips when they still made those.
Wait what? Wolverine is played by Duke Nukem?
You're right, I threw 50 out there as a guess since I didn't have a datasheet at hand and it had been a while since I read any datasheets regarding memory.
Now that I looked up a datasheet for the Samsung K9LAG08U0M (the NAND chip in the 8gb iPod and iPhone), and Toshiba's NAND flash interface design guide (kinda old though), I found some additional interesting things.
1) Assuming we're using NAND flash, many large NAND Flash chips are actually 4GB NAND Flash chips stacked internally, with multiple chip enable lines. This means that we're kinda forced into not doing simultaneous access for high density chips past 4GB.
The 8GB one is 2 4GB chips stacked in the same package. The 16GB one is 4 chips stacked.
2) There appears to be a standard interface for NAND Flash across manufacturers where 528 bytes are written out at a time in small block mode and 2112 in large block mode.
And it has a small block and large block mode. It seems to max out at 4GB.
3) To access a single 4GB chip, you definetely need unique IO0-7 and CE. 9 lines.
You may be able to share CLE, ALE, Ready, WE, RE if you're always writing to blocks at the same time. This isn't true when a block fails writing. So you shouldn't share these either. Makes for a total of 14 unshared lines.
Obviously shared lines are Power, Ground, Write Protect.
So, you're right, for a bus to NAND connection, it wouldn't be too bad to have a controller that provides 14*N lines, where N is the number of chips to access simultaneously. The board layout difficulty would still grow significantly as you add more chips though.
Adding a DRAM cache to help reordering, buffering, and deferring block checks would also be painful. Micron says for a 64MB SDRAM chip, you'll need 12 address lines, up to 16 Data lines, and about 8 more control lines. Pretty darn ugly. That's probably what made me incorrectly assume 50 lines.
The caption makes it sound to me like...well... a MOSFET. but that's just cuz the caption was written poorly.
The theory makes it sound to me like.... well... a Flash memory cell.
So what's the big deal?
There is actually no guarentee that they're all being accessed in parallel. The reason for this is because the block size for each chip is larger than the normal LBA block size. Which means that either you cache this for a while in DRAM (less likely), or you write back a merged block (more likely).
Normally, when you access a memory chip, you typically have all the lines(wires) tied together except for a chip select, which tells the chip, you're the one being accessed. This is to reduce the number of lines coming from a controller because IO lines are expensive to make. Hence why USB drives that are dual-channel are much more expensive and rare.
So, an example would be, for single channel it takes 50 lines total to connect to a single NAND chip.
51 lines to connect to 2 NAND chips.
52 lines to connect to 3 NAND chips.
What you're asking for, simultanious access to all NAND chips would be....
50 lines to connect to a single NAND chip.
100 lines to connect to 2 NAND chips.
150 lines to connect to 3 NAND chips. Pretty crazy huh?
Adding in the lines to support DRAM would increase the cost even more.
Aside from increasing chip costs, adding in lines would make the board harder to layout to prevent crosstalk and corruption. It's the same reason why it's rare to find motherboards with more than 4 DIMM slots. It's hard to layout that many lines.
Overall, it'd be nice if we could cache and package each block in DRAM and write/read them from NAND in parallel. But it increases development costs significantly. Probably by whole number factors.
There's nothing in ATA that is really specific to mechanical drives since LBA basically addresses it as an array anyways.
Additionally, typical NAND chips are 20MB/sec. While NAND is solid state, it compares unfavorably to, say DRAM.
There are a few chips on the market that go as high as 50MB/sec, but they're rare. And even then, ATA66 would still be enough to connect to it.
Telus and Bell are EVDO providers I think.
So, they're not getting it.
On the miniscule chance they do, I'm so hacking one to work on Verizon.
BREW (Qualcomm's phone platform) requires all apps to be signed.
A developer cert is only given by Qualcomm. And requires the actual dev phones be sent in to be tweaked by Qualcomm so you can download to them for testing. This is, of course, after you've applied and been certified by Qualcomm to be allowed to develop.
Finally, once you've developed your program. You'll need to submit it for certification.
And once it's been certified, you need to convince Verizon to actually post it on the store.
There's fees at every level, of course.
And there's so many more of these phones than there are Symbian, iPhone, Windows Mobile, combined.
Just wanted to reply that I thought that's a pretty nice and easy to understand explanation.
The way I'm seeing it is that given an infinite amount of RAM, and then either a FPGA configured to be a CPU through Verilog or any other CPU (say a R3000), they're either both turing machines or not.
Without a RAM limitation, any given set of gates and interconnections can be put onto a FPGA either directly, or emulated through a simpler set of gates and interconnects on the FPGA assisted by a freakin' huge chunk of software dumped into "infinite RAM".
Actually, we don't even need to be looking back. Considering the Asus EEE is a "current" computer using what amounts to a 650 Mhz P3, it's fairly clear that most people are buying machine that are far overspeced for their needs.
Qualcomm didn't have to patent anything specific in order to impede WCDMA. They had the patents from the beginning because of how much WCDMA borrows from IS-95 (the original cdmaOne). Fundamentally, the radio design will be similar despite the number of years between when IS-95 was developed and when FOMA/WCDAM was developed.
Verizon and Sprint would both be stupid to not use EVDO since, as the first letter suggests, it's simply an evolution from IS-95. From what I read, EVDO was literally a software upgrade to their base stations.
Qualcomm would of course push EVDO considering they already had a working product AND had existing deployments in Australia (telestra) and the US (verizon/sprint). It's hard to resist the fact that when you're Qualcomm and can advertise that "hey, check it out, 3G works now" and point at the failure that was NTT's initial WCDMA deployment.
I acknowledge that UMTS is faster than EVDO Rev0.
I acknowledge that both Verizon and Qualcomm have been evil in their business tactics (witness the Motorola v710 bluetooth fiasco, and the general CDMA patent lawsuits respectively).
But as a technology, it's hard to find fault with EVDO, especially given the circumstances. While it'd be nice to have one phone technology world-wide, as a consumer the benefit of EVDO over UMTS is too big:
* An EVDO based phone will always have better battery life compared to a UMTS/GSM phone given the same battery technology and chipset design generation. This is because EVDO based phones are simpler to make and have less electronics to power since the radio for EVDO is the same as the radio for IS-95, so you can switch down to lower speeds to save power when you don't need data. A UMTS/GSM phone requires currently, a chipset to handle GSM, and then a secondary coprocessor to handle WCDMA.
* An EVDO based phone will also have better reception and voice quality overall until a equally sized UMTS network is in place. This is because until AT&T can build up an entirely new network from scratch, you'll be using GSM whenever possible to keep the load to a minimum until they can debug it all. I don't expect this to finish for at least another 5 years. Look at how long it took for them to turn off their TDMA network.
* The majority of phones will not require speeds faster than EVDO provides. In fact, most phones right now probably can't even use the speed available. Those of my friends who have UMTS phones on AT&T must tether to actually make full use of the speed since the onboard CPU just can't do anything with data coming in that fast. It's like watching a guy with a 486 try to run bittorrent with his personal OC-42. A waste.
Given the facts, I'm still a Verizon subscriber (although my phone is hacked so much it's pretty amusing), and my iPhone is being used as a slightly thick iPod Touch.
However, while 3G UMTS uses W-CDMA rather that GSM's TDMA, it is not supported by Qualcomm.
WTF? Uh no.
Qualcomm might be crazy about locking people in, but there is no incompatible WCDMA from Qualcomm. Their WCDMA implementation is just another implementation of the standard.
And you got it sorta backwards when you say "For the 3G of mobile networks, 2G GSM and 2G CDMA2000 carriers were supposed to unify the world under one new standard: W-CDMA UMTS."
While GSM networks will move to UMTS/HSDPA, and IS-95/CDMA2000/EVDO will progress to EVDO Rev A, there exists a chipset from Qualcomm that provide access to UMTS/WCDMA and EVDO/CDMA2000 in one phone. There is no reason EVDO networks would be moving to UMTS, as CDMA2000 have an easy upgrade to EVDO which is 3G and available widely as of like 3 years ago.
I believe that in addition to AFLT, the Qualcomm chipset used in the Kindle has GPSOne/AGPS built in.
AGPS uses the AFLT to ask the towers to download almanac data to fast-start an actual GPS satellite receiver, or process the fragments received by the satelite to narrow down the location to the same resolution as a standalone GPS, without the startup time and delays.
This means that within a 3 seconds, you'd have a general idea which 1 mile block you're on, within a 7 more seconds, you should have an actual GPS fix. (instead of downloading the ephemeris for 30 seconds and then calculating, which is what a standalone unit would do.)
Those are pretty cool!
Yeah, my thought was more along the lines of "if we were to build a pda phone, what do we need?". Therefore having both EVDO data and voice were considered important.