Far better to develop their own game first, in the style of Kings Quest, than to actually use the Kings Quest IP.
If, down the line, they have a good project, they could have approached Activision to ask for offical Kings Quest branding (changing character names, and some graphics) in return for Activision putting it on WiiWare, etc.
Oh well, I think the developers were naive, but generally open and honest. That doesn't pay when you are dealing with businesses. Sad fact.
The sad thing is that such a game would be perfect for WiiWare or similar. Instead of taking a stance against the development, they should have seen how development was going and maybe offered support to get the game onto these console platforms.
It's very sad.
Personally I hope that they've responded with their contract with Activision, said that said contract is still in force, and that they will be doing no such thing as abiding by the request.
Give the games 0 star reviews on all websites that allow ratings to be provided - Amazon, Metacritic, etc. State why. I certainly know that I pay more heed to the user scores on Metacritic than the average-paid-for-magazine-review scores.
Complain to your local/national consumer protection agency about artificial disabling technology in products that you have purchased, and explain how this is different from the historical standard where games software would continue to run as long as you have the platform it ran on available. Explain how the company can disable the game by disabling the server that enables the game to run, or if the company goes bust, etc.
And don't buy any software from companies that use such restrictive DRM.
It's ridiculous, it shows that they haven't thought about this entire aspect.
Apps should tag to the operating system whether they need to run in the background (e.g., Spotify or other streaming music apps, or apps that are waiting on network data (e.g., IM)) or not. Backgroundable apps really should be two apps - a background "workhorse" console application that does the workload that needs to run in the background (maybe sending notifications to the OS), and a foreground "UI" application (+ widget) to control it and do all the controllery, UIey stuff.
Apps that need to perform periodic checks should be run via cron or at, in a smaller console app that doesn't need to set up a UI, etc. Literally it checks, puts the data in the application datastore, and sends a notification to the OS to display.
Apps that don't need to do checks can simply save their state to the application datastore and quit when closed (home button pressed, or maybe after a certain amount of time inactive, or only when the OS detects that the system is running out of memory).
If I know applications will be sleeping and/or out of memory, then I am not worrying.
However the Twitdroid application on Android sucks up battery life like a nymphomaniac in a vibrator factory. Sadly this is an exact case where Apple's notification's service wins.
Only the executable part of an Android application has to reside in the primary flash storage (still a ridiculous restriction to have designed in however).
A version of Android coming in the future will remove this restriction as well.
Doesn't negate the fact that comparing Android to iPhone OS 3.2 will be like night and day in terms of the software available and how it works in terms of ease of use. And I say that as an Android user. Multitasking is all very well, but having to open a task killer application to kill off background apps to free up memory is tiresome. All apps should quit when closed unless they need to run in the background, if they need to check periodically for tweets, email, etc, the underlying Linux has cron.
The iPad looks immensely compelling as a pick-up-and-use device that I don't have to think about, that does all of the things I want. There are even suggestions that it will support flash (farmville and mafia wars fans rejoice!), because the iPad videos contain web pages that have the flash operating (see 9to5 mac), but could be a fault with how the video was made (using desktop safari imagery).
Never mind that this guy isn't about to Osbourne Wii sales.
Until they want to show it off, it won't exist. Simple really.
You don't see Microsoft talking about the XBox1080, or Sony talking about the PS4 - that's because they don't want existing sales to tank as people wait for the new product. I don't see why Nintendo would be any different. The only guaranteed thing is that all three companies are more than likely well into the design process for their next generation consoles.
I meant that when you can get decent sized cache optimised for 3GHz+ CPUs (e.g., AMD's 64KB/64KB L1 I/D), optimising it for 1GHz CPUs and low power can mean you still have large L1 caches that are as fast as the CPU core requires to operate at its designated clock speed. I.e., you can still have large caches on ARM CPUs.
Also a slower CPU reduces latency as seen by the application running, when you have to go down the memory hierarchy - especially when the memories are fast or the memory controller is local.
Maybe you will be caching (e.g.,) 30% less instructions in ARM Thumb2 code than in x86 code in the same sized cache. But you have 32KB of cache available, so most loops will be happily accommodated. It's not like the ARM Thumb2 code is going to be massively larger than x86:
http://www.csl.cornell.edu/~vince/papers/iccd09/iccd09_density.pdf suggests Thumb1 code density is between slightly better than x86 through to twice the size. It also says that Thumb2 has better density because it fixes the deficiencies of Thumb1 in many areas, but I haven't read the referenced article that states that - but I've seen ARM's PR about it and am willing to believe that it has the overall performance of ARM code in the size of Thumb code.
It would also be interesting to see how L1 ICache size correlates with performance increase. I would imagine that going from 0 to 1KB would have a massive effect (indeed going to 256 bytes in the 68020 had a massive performance increase over disabling the cache), but going from 16KB to 32KB would have far less of an effect.
Anything over a $300 termination fee is excessive, especially since they are openly selling the unlocked version
Well buy the unlocked version then, and the Google part of the ETF won't apply.
"The Google Nexus One price is $530 unlocked or with a T-Mobile contract - $179."
If a phone costs $530, and you pay $180 up front for it, then don't be surprised when you cancel and you get asked for the rest of the retail price to be repaid. That's not double dipping, it's paying for the device that you bought.
Does it really matter if a large cache is running slower when it is attached to a ~1GHz dual-issue CPU? I'm sure ARM have already sacrificed performance however to reduce power consumption.
It would be interesting to see how cache use differs between a platform like Android, with its Dalvik VM and multitasking on ARM and Windows 7 and desktop applications on Atom.
Note that the amount of cache in an ARM SoC is configurable by the implementor. I believe most A8 designs are using 256KB L2. The L1s are 32KB/32KB I/D (in most implementations), which already compares well with Intel's desktop CPUs.
Putting Atom into 64-bit mode on the 45nm variants takes it from 2.5W to 4W per core. It might be more negligible on the 32nm version however. I don't know what ARM are doing about 64-bit support down the line, I presume they'll create a 64-bit capable core, and a new instruction decoder.
Marvell just announced a quad-core ARMv7 architecture (Cortex A9) system-on-chip that will have been an evolution of StrongARM / XScale.
Not In Here syndrome wins again, but I can see Intel's logic where they have an investment in x86 that they need to keep alive for a long time or they will become irrelevant, maybe in ten, maybe twenty years time.
Sure, Mooretown will integrate a CPU and GPU with 3D and video. It might support the AES instructions added to x86 recently by Intel too. But it doesn't have the baseband processor which would be separate in such a phone. It might also need a separate I/O chip. It won't run as cool as the A9 SoC either. And Intel won't want to sell such a chipset for such a low price.
The world has moved on since 1999. Seriously, are you really comparing x86 to ARM based around an eleven year old device's features and compatibility?
x86 JIT emulation on a 1GHz Cortex A8/A9 in the vein of the Alpha FX!32 emulation might equal a low-end Atom in performance. It does require someone to write it, and somehow integrate it into an ARM version of Wine though.
And a 2006 mobile phone running one of the more limited smartphone OSes. Brilliant. You do know that there is plenty of Office compatible software out there, like Documents2Go, that does all you need? Well, maybe you need VBA in Excel or something...
Hell, a 1GHz A9 could run OpenOffice. Not that it would be pretty on a 4" 800x480 display, but...
I thought Moorestown was 32nm, that was used in this LG demo phone-brick.
It takes time to get products made in foundries - signing something now might mean a product in a year's time. Moorestown will be out before then.
Of course the lack of integration in Moorestown means any implementation needs additional support chips to add other functionality, such as 3G chips, etc.
Marvell already announced a Quad-Core ARMv7 (Cortex A9 equivalent) SoC. ARM have announced 2GHz ARM Cortex A9 hard cores for TSMC.
I do think that if in ten years time everybody is using x86 still, that something is severely wrong in the world.
But not on IA32, which this Atom will be running (desktop Atoms support it, but it will be disabled here). In addition using AMD64 means longer instruction prefixes, negating your "really compact" argument. Of course when smartphones are coming with 512MB RAM (Nexus One), is code compactness really an issue any more?
Thumb2 negates the limitations of Thumb1, giving full access to registers and operations. And it has decent code compactness on top, although I don't know how it compares with x86 - maybe there are some comparisons out there? http://iccd.et.tudelft.nl/2009/proceedings/459Weaver.pdf has some interesting data but neglects to include Thumb.
In the end, ARM is dominant in the mobile and smartphone arena, and backwards compatibility with x86 isn't a concern. Looking at the size of this "phone" it'll require another generation of integration to get x86 competitive in terms of implementation area. In the meantime an 800MHz Atom is going to compare very badly with dual-core >1GHz A9s.
You make it seem so simple, and yes, it's a very low cost benefit for a business to operate that increases productivity, especially for night-owl IT workers who hate mornings.
On the other hand, if the company is willing for you to do your own "coffee club" in such a situation: Find 19 co-workers, you each put in $15 up front ($300), and you've got coffee for a month, and then $2 each every week from then on.
But if the company said that wasn't possible, and they wanted us to use the $1/cup coffee machine they want to install instead, I'll drink water instead, or bring coffee in a thermos. And I'll be less productive in the morning.
Fix your employment laws. Life isn't just for working, but when the law is not there to benefit employees, the employees will get stiffed, guaranteed. 12 days is pitiful. The lawful minimum in the UK is 20 days plus public holidays (8 days), and nobody in IT would accept less than 25 days after a couple of years working after university. Other EU countries have more, yet none of these countries has employee productivity problems.
Now what I don't mind is sacrificing salary to have unpaid leave, earning a week a year that you can use the next year or build it up over time - earning an unpaid sabbatical in effect, even if the time you can take it is quite restricted to less busy periods of the year.
Yeah, Jewels and Bonsai Blast are good time wasters when I'm travelling on public transport or sitting on the bog. The rolling-a-ball games like Teeter got old quickly though.
A 14MHz 68000 in the A600 would have been a good idea, it would have been that little extra power to make games like Epic, Frontier, etc, run acceptably. I guess it came down to cost - I have no idea what Motorola was charging for CPUs, and the Amiga was an affordable home computer.
The Amiga graphics idea of planar graphics was great for 1985, but became a crutch by the 90s - the A1200's 256 colour displays were unusable - many games used 128 colours to save on a bitplane and the resulting memory access. Adding a 256 colour bitmap mode should have been high on the agenda for the A600, or at least the A1200. The A1200's blitter was a complete failure, with no improvements, it should have been better, it would have made the computer compete better with the SNES.
Indeed the modern PC, at least a decent one, is very Amiga-like. Except that the OS properly supports the features via APIs like DirectX, OpenGL, OpenCL, and so on.
AmigaOS, even in the 90s, could have succeeded if refactored for mobile devices (cf. the original PalmOS with all its limitations). Hyperion have done a lot of good work to keep it alive and improve it, but architecturally it is behind in many areas.
Some things that required hardware back then, like the screen dragging, are trivial to do in software, or by using the hardware differently (using OpenGL/Compiz to do screen dragging shouldn't be a hard task).
Commodore did keep the platform back though by not improving it as expediently as possible. Not improving the chipset meant that other computers caught up, and overtook with fast 256 colour bitmap displays.
On the other hand, imagine the cruft of 25 years of bitmap graphics enhancements if we had AGA++AA++AA++++++ chipset now. Although the compatibility stuff would probably fit in a couple of square millimetres of silicon... Not that such an Amiga would be recognisable as one now.
Slashdot Mirror
Far better to develop their own game first, in the style of Kings Quest, than to actually use the Kings Quest IP.
If, down the line, they have a good project, they could have approached Activision to ask for offical Kings Quest branding (changing character names, and some graphics) in return for Activision putting it on WiiWare, etc.
Oh well, I think the developers were naive, but generally open and honest. That doesn't pay when you are dealing with businesses. Sad fact.
Never mind the existing (albeit quite old now) HeroQuest computer games!
I wouldn't mind an up to date remake of the Hero Quest computer games. Or Space Crusade. Good old isometric games.
The sad thing is that such a game would be perfect for WiiWare or similar. Instead of taking a stance against the development, they should have seen how development was going and maybe offered support to get the game onto these console platforms.
It's very sad.
Personally I hope that they've responded with their contract with Activision, said that said contract is still in force, and that they will be doing no such thing as abiding by the request.
In addition:
Give the games 0 star reviews on all websites that allow ratings to be provided - Amazon, Metacritic, etc. State why. I certainly know that I pay more heed to the user scores on Metacritic than the average-paid-for-magazine-review scores.
Complain to your local/national consumer protection agency about artificial disabling technology in products that you have purchased, and explain how this is different from the historical standard where games software would continue to run as long as you have the platform it ran on available. Explain how the company can disable the game by disabling the server that enables the game to run, or if the company goes bust, etc.
And don't buy any software from companies that use such restrictive DRM.
What? Doesn't "Bobby, milkman to the Emperor's pet cat OF DUNE" count?
What's a good alternative KDE music player that integrates well with KDE?
The ARM based SoCs that are used in Smartbooks all include video decode acceleration. NVIDIA's Tegra 2 can do 1080p.
This stuff all needs to be within the same hard drive.
Sell a 2TB 3.5" hard drive with a 64GB *fast* SSD cache on board (transparent to the OS), and then we will be talking.
It's ridiculous, it shows that they haven't thought about this entire aspect.
Apps should tag to the operating system whether they need to run in the background (e.g., Spotify or other streaming music apps, or apps that are waiting on network data (e.g., IM)) or not. Backgroundable apps really should be two apps - a background "workhorse" console application that does the workload that needs to run in the background (maybe sending notifications to the OS), and a foreground "UI" application (+ widget) to control it and do all the controllery, UIey stuff.
Apps that need to perform periodic checks should be run via cron or at, in a smaller console app that doesn't need to set up a UI, etc. Literally it checks, puts the data in the application datastore, and sends a notification to the OS to display.
Apps that don't need to do checks can simply save their state to the application datastore and quit when closed (home button pressed, or maybe after a certain amount of time inactive, or only when the OS detects that the system is running out of memory).
If I know applications will be sleeping and/or out of memory, then I am not worrying.
However the Twitdroid application on Android sucks up battery life like a nymphomaniac in a vibrator factory. Sadly this is an exact case where Apple's notification's service wins.
Only the executable part of an Android application has to reside in the primary flash storage (still a ridiculous restriction to have designed in however).
A version of Android coming in the future will remove this restriction as well.
Doesn't negate the fact that comparing Android to iPhone OS 3.2 will be like night and day in terms of the software available and how it works in terms of ease of use. And I say that as an Android user. Multitasking is all very well, but having to open a task killer application to kill off background apps to free up memory is tiresome. All apps should quit when closed unless they need to run in the background, if they need to check periodically for tweets, email, etc, the underlying Linux has cron.
The iPad looks immensely compelling as a pick-up-and-use device that I don't have to think about, that does all of the things I want. There are even suggestions that it will support flash (farmville and mafia wars fans rejoice!), because the iPad videos contain web pages that have the flash operating (see 9to5 mac), but could be a fault with how the video was made (using desktop safari imagery).
Apparently, 256-bit GDDR5 is enough.
(figures from http://www.anandtech.com/video/showdoc.aspx?i=3721&p=2)
GF100 has a 384-bit memory bus, likely with a 4000MHz+ data rate. HD5870 has a 4800MHz data rate, so let's assume the same.
The GTX285 had a 512-bit memory bus, with a 2484MHz data rate
So the bandwidth is (384/512) * 4800 / 2484 = 1.45x higher.
Never mind that this guy isn't about to Osbourne Wii sales.
Until they want to show it off, it won't exist. Simple really.
You don't see Microsoft talking about the XBox1080, or Sony talking about the PS4 - that's because they don't want existing sales to tank as people wait for the new product. I don't see why Nintendo would be any different. The only guaranteed thing is that all three companies are more than likely well into the design process for their next generation consoles.
I meant that when you can get decent sized cache optimised for 3GHz+ CPUs (e.g., AMD's 64KB/64KB L1 I/D), optimising it for 1GHz CPUs and low power can mean you still have large L1 caches that are as fast as the CPU core requires to operate at its designated clock speed. I.e., you can still have large caches on ARM CPUs.
Also a slower CPU reduces latency as seen by the application running, when you have to go down the memory hierarchy - especially when the memories are fast or the memory controller is local.
Maybe you will be caching (e.g.,) 30% less instructions in ARM Thumb2 code than in x86 code in the same sized cache. But you have 32KB of cache available, so most loops will be happily accommodated. It's not like the ARM Thumb2 code is going to be massively larger than x86:
http://www.csl.cornell.edu/~vince/papers/iccd09/iccd09_density.pdf suggests Thumb1 code density is between slightly better than x86 through to twice the size. It also says that Thumb2 has better density because it fixes the deficiencies of Thumb1 in many areas, but I haven't read the referenced article that states that - but I've seen ARM's PR about it and am willing to believe that it has the overall performance of ARM code in the size of Thumb code.
It would also be interesting to see how L1 ICache size correlates with performance increase. I would imagine that going from 0 to 1KB would have a massive effect (indeed going to 256 bytes in the 68020 had a massive performance increase over disabling the cache), but going from 16KB to 32KB would have far less of an effect.
Anything over a $300 termination fee is excessive, especially since they are openly selling the unlocked version
Well buy the unlocked version then, and the Google part of the ETF won't apply.
"The Google Nexus One price is $530 unlocked or with a T-Mobile contract - $179."
If a phone costs $530, and you pay $180 up front for it, then don't be surprised when you cancel and you get asked for the rest of the retail price to be repaid. That's not double dipping, it's paying for the device that you bought.
Does it really matter if a large cache is running slower when it is attached to a ~1GHz dual-issue CPU? I'm sure ARM have already sacrificed performance however to reduce power consumption.
It would be interesting to see how cache use differs between a platform like Android, with its Dalvik VM and multitasking on ARM and Windows 7 and desktop applications on Atom.
Note that the amount of cache in an ARM SoC is configurable by the implementor. I believe most A8 designs are using 256KB L2. The L1s are 32KB/32KB I/D (in most implementations), which already compares well with Intel's desktop CPUs.
Putting Atom into 64-bit mode on the 45nm variants takes it from 2.5W to 4W per core. It might be more negligible on the 32nm version however. I don't know what ARM are doing about 64-bit support down the line, I presume they'll create a 64-bit capable core, and a new instruction decoder.
They sold it to Marvell.
Marvell just announced a quad-core ARMv7 architecture (Cortex A9) system-on-chip that will have been an evolution of StrongARM / XScale.
Not In Here syndrome wins again, but I can see Intel's logic where they have an investment in x86 that they need to keep alive for a long time or they will become irrelevant, maybe in ten, maybe twenty years time.
Indeed. Check out the price of the 1GHz Snapdragon CPU, GPU, and Baseband (and video, 3D, security, I/O, etc) chip in the Nexus One:
http://www.isuppli.com/News/Pages/Google-Nexus-One-Carries-$17415-Materials-Cost-iSuppli-Teardown-Reveals.aspx
In short: $30.50.
Sure, Mooretown will integrate a CPU and GPU with 3D and video. It might support the AES instructions added to x86 recently by Intel too. But it doesn't have the baseband processor which would be separate in such a phone. It might also need a separate I/O chip. It won't run as cool as the A9 SoC either. And Intel won't want to sell such a chipset for such a low price.
The world has moved on since 1999. Seriously, are you really comparing x86 to ARM based around an eleven year old device's features and compatibility?
x86 JIT emulation on a 1GHz Cortex A8/A9 in the vein of the Alpha FX!32 emulation might equal a low-end Atom in performance. It does require someone to write it, and somehow integrate it into an ARM version of Wine though.
And a 2006 mobile phone running one of the more limited smartphone OSes. Brilliant. You do know that there is plenty of Office compatible software out there, like Documents2Go, that does all you need? Well, maybe you need VBA in Excel or something ...
Hell, a 1GHz A9 could run OpenOffice. Not that it would be pretty on a 4" 800x480 display, but ...
I thought Moorestown was 32nm, that was used in this LG demo phone-brick.
It takes time to get products made in foundries - signing something now might mean a product in a year's time. Moorestown will be out before then.
Of course the lack of integration in Moorestown means any implementation needs additional support chips to add other functionality, such as 3G chips, etc.
Marvell already announced a Quad-Core ARMv7 (Cortex A9 equivalent) SoC.
ARM have announced 2GHz ARM Cortex A9 hard cores for TSMC.
I do think that if in ten years time everybody is using x86 still, that something is severely wrong in the world.
Modern x86 gives you 16 integer registers
But not on IA32, which this Atom will be running (desktop Atoms support it, but it will be disabled here). In addition using AMD64 means longer instruction prefixes, negating your "really compact" argument. Of course when smartphones are coming with 512MB RAM (Nexus One), is code compactness really an issue any more?
Thumb2 negates the limitations of Thumb1, giving full access to registers and operations. And it has decent code compactness on top, although I don't know how it compares with x86 - maybe there are some comparisons out there? http://iccd.et.tudelft.nl/2009/proceedings/459Weaver.pdf has some interesting data but neglects to include Thumb.
In the end, ARM is dominant in the mobile and smartphone arena, and backwards compatibility with x86 isn't a concern. Looking at the size of this "phone" it'll require another generation of integration to get x86 competitive in terms of implementation area. In the meantime an 800MHz Atom is going to compare very badly with dual-core >1GHz A9s.
You make it seem so simple, and yes, it's a very low cost benefit for a business to operate that increases productivity, especially for night-owl IT workers who hate mornings.
On the other hand, if the company is willing for you to do your own "coffee club" in such a situation: Find 19 co-workers, you each put in $15 up front ($300), and you've got coffee for a month, and then $2 each every week from then on.
But if the company said that wasn't possible, and they wanted us to use the $1/cup coffee machine they want to install instead, I'll drink water instead, or bring coffee in a thermos. And I'll be less productive in the morning.
Fix your employment laws. Life isn't just for working, but when the law is not there to benefit employees, the employees will get stiffed, guaranteed. 12 days is pitiful. The lawful minimum in the UK is 20 days plus public holidays (8 days), and nobody in IT would accept less than 25 days after a couple of years working after university. Other EU countries have more, yet none of these countries has employee productivity problems.
Now what I don't mind is sacrificing salary to have unpaid leave, earning a week a year that you can use the next year or build it up over time - earning an unpaid sabbatical in effect, even if the time you can take it is quite restricted to less busy periods of the year.
Yeah, Jewels and Bonsai Blast are good time wasters when I'm travelling on public transport or sitting on the bog. The rolling-a-ball games like Teeter got old quickly though.
A 14MHz 68000 in the A600 would have been a good idea, it would have been that little extra power to make games like Epic, Frontier, etc, run acceptably. I guess it came down to cost - I have no idea what Motorola was charging for CPUs, and the Amiga was an affordable home computer.
The Amiga graphics idea of planar graphics was great for 1985, but became a crutch by the 90s - the A1200's 256 colour displays were unusable - many games used 128 colours to save on a bitplane and the resulting memory access. Adding a 256 colour bitmap mode should have been high on the agenda for the A600, or at least the A1200. The A1200's blitter was a complete failure, with no improvements, it should have been better, it would have made the computer compete better with the SNES.
Indeed the modern PC, at least a decent one, is very Amiga-like. Except that the OS properly supports the features via APIs like DirectX, OpenGL, OpenCL, and so on.
AmigaOS, even in the 90s, could have succeeded if refactored for mobile devices (cf. the original PalmOS with all its limitations). Hyperion have done a lot of good work to keep it alive and improve it, but architecturally it is behind in many areas.
Some things that required hardware back then, like the screen dragging, are trivial to do in software, or by using the hardware differently (using OpenGL/Compiz to do screen dragging shouldn't be a hard task).
Commodore did keep the platform back though by not improving it as expediently as possible. Not improving the chipset meant that other computers caught up, and overtook with fast 256 colour bitmap displays.
On the other hand, imagine the cruft of 25 years of bitmap graphics enhancements if we had AGA++AA++AA++++++ chipset now. Although the compatibility stuff would probably fit in a couple of square millimetres of silicon... Not that such an Amiga would be recognisable as one now.