The problem with VxWorks is that the scheduling accuracy is its only positive feature. Device drivers are rare and expensive, probably because it doesn't have a sensible hardware abstraction layer like Linux, Windows (NT family), and QNX. If you want to use the MMU on the processor you get charged again, and you get even more incompatibilities. The documentation doesn't go into much depth, and Google isn't very helpful, as hardly anybody talks about it on the Internet.
Have you tried QNX or RTEMS? I don't have any data on their scheduling accuracy, but they claim to support the same real-time features. I've also found the QNX documentation much easier to follow, and I managed to turn out a BSP and a custom device driver within a week of first receiving the software.
That may be true on your phone, but that's a pretty unusual configuration and I've never seen a phone do that. It's certainly not like that on the common S40 phones.
A WAP push arrives like any other SMS. The standby screen of the phone shows a message that a WAP push has arrived. The user presses a soft-key to open the message (button press 1). The phone then displays some of the message text, and as much of the URL as will fit. The user presses a soft-key (button press 2) and the phone starts the browser and goes to the URL via the WAP access point.
The user only knows that it is possible to change the gateway if they've been four menu levels deep into the phone settings.
We send a WAP push message to remote staff directing them to an in-house WAP site. That's just two button pushes from the standby screen of the phone. There's no chance we can train them to delve deep into their phone settings and change the default gateway that the phone uses when they accept a WAP push.
Once they reach the site we use WMLScript to ask a series of questions. We don't have a HTML version of the site. Vodafone's change stopped the WMLScript getting to the phone. Effectively Vodafone turned off old-school WAP without warning anyone.
It also hides the original Accept header, and presents a different list of MIME types. To make the problem even worse, it then refuses to pass across files that the phone would be perfectly capable of accepting. For an in-house site I work on, it broke our ability to deliver compiled WMLScript (application/vnd.wap.wmlscriptc) to phones that are perfectly capable of executing the scripts.
Then why can not say a groups of universities get together and develop their own international web journal of all sciences(TM). They've already started.
Sadly, I can only provide a few tantalising hints. Not because I'm sitting on the information, but because very few people have written about this, and I haven't yet tried it myself.
There's one important thing to remember about Compact Flash: it is not a raw flash device. There are robust filesystems to run on raw flash (YAFFS, JFFS2), but they only provide limited help when running on Compact Flash. A Compact Flash already contains a flash filesystem layer, which emulates an ATA disk on top of NAND flash. The manufacturer of this emulation layer does not publish documentation, and may change the implementation between production batches without changing the part number.
This is fine for a digital camera: it only writes a file when you press the shutter, and the user turns it off with a soft power button which will wait until the write is complete. The only way to turn off the power during a write cycle is to pull out the battery, and the manual tells you not to do that.
The question here is: what filesystem to run on top of this undocumented emulation layer, to provide reliability if the power is removed? I wish I had an answer to that. I feel your pain, as hardware designers always leave me stuck with this same unsolvable problem.
I'll pass on some advice I've received before: smartmedia and xD cards expose a raw NAND interface, allowing you to run JFFS2 or YAFFS directly on the flash. I've never managed to persuade a hardware designer to pursue this approach, but maybe one of you will succeed.
There's a lot of these chips selling, so somebody must be buying them. Have you tried putting your question to the local offices of the chip companies?
Even if they are done by the game engine, they aren't camera angles you actually use when playing the game. Take a look at the PGR shot, and ask yourself, "Could I really drive looking at my car from down there?"
I may be old-fashioned, but I prefer to play racing games with the camera looking forwards, and maybe with the speedo visible somewhere on the screen. Those wishing to take screen shots of racing games should read this useful guide.
OK, that's certainly a lot more original than most puzzle games. Pnickies never made much of an impact, possibly because the market was saturated with puzzle games, or possibly because it has an unsatisfying difficulty curve. Getting large combos at the beginning of the game doesn't seem to have much influence on your overall performance and score.
Your description for Drippy describes it as "Not just an old game with a different name and better graphics and enough little changes to evade copyright, but a whole new game concept." So why does the mechanic of merging blobs to get two stars remind me so much of Pnickies?
Also consider Box Backup. It encrypts the backups so that the server storing the backup doesn't have the necessary key to read the backed-up data. It's working well for me.
In particular, the failure of the x86 architecture to implement the
Popek-Goldberg requirements. VMWare and Plex86 have to do a lot of work to paper over the cracks. Xen uses a modified guest operating system to get around this.
Popek and Goldberg worked this out in 1974. It's taken Intel a little while to notice.
You forgot to mention how every BSP author gets the chance to implement PCI slightly differently, so a card vendor can't write a single VxWorks driver and expect it to compile for every board.
On Linux I can write driver source that works for everyone. On Windows and Solaris I can produce driver binaries that work for everyone. On VxWorks I have to produce a page of instructions so that an experienced VxWorks developer can edit the source to match.
UK analogue TV is now almost entirely broadcast in 14:9. Unfortunately older TV shows were made in 4:3, so they slice off the top and bottom of the image. This is probably an attempt to make us buy digital receivers.
Also, most BGA sockets are prone to contact corrosion and just don't last very long.
Even if you can't purchase Apple-brand daughtercards, you can purchase 3rd-party upgrade daughter cards. The problem is that these are quite expensive.
As the referenced article said, it reduces battery life by 15-30 minutes. This should leave you with a realistic battery life of about 3.5 to 4 hours. My own experience is that an unmodified iBook is good for over 4 hours of editing text.
The change to battery life isn't large for two reasons. Firstly the PowerPC has dynamic power management, which makes idle time cheap. Secondly, a lot of the power consumption comes from the disk and display, which are unchanged by this mod.
The market for it on PowerPC may not be games, but embedded development. That wouldn't be quite such a difficult cultural gap for you to cross as business high performance computing.
Currently people are doing Altivec development with tools that require explicit specification of vector operations. It's painfully close to assembly programming. And if they aren't using GCC then they are probably paying around $3000 per development seat for this. If they are using GCC the optimiser isn't doing a great job on their code.
Your main problem is that there is no single company here to help fund development or provide publicity. The embedded hardware is often developed in house for a particular project, or bought from one of several small hardware vendors. Motorola already own a compiler company, so may not be keen to help out the competition.
Motorola Semiconductor makes PowerPC processors. Motorola Computer makes boards using PowerPC processors (from both Motorola Semiconductor and IBM) and Intel processors.
Do not confuse the two Motorola companies. Don't even assume that there is any communication between them.
Motorola Computer is supporting Linux. And despite all these Caldera announcements, they're using Debian on PowerPC internally.
Slashdot Mirror
The problem with VxWorks is that the scheduling accuracy is its only positive feature. Device drivers are rare and expensive, probably because it doesn't have a sensible hardware abstraction layer like Linux, Windows (NT family), and QNX. If you want to use the MMU on the processor you get charged again, and you get even more incompatibilities. The documentation doesn't go into much depth, and Google isn't very helpful, as hardly anybody talks about it on the Internet.
Have you tried QNX or RTEMS? I don't have any data on their scheduling accuracy, but they claim to support the same real-time features. I've also found the QNX documentation much easier to follow, and I managed to turn out a BSP and a custom device driver within a week of first receiving the software.
But what about all the other ways that IP addresses are used and stored?
That may be true on your phone, but that's a pretty unusual configuration and I've never seen a phone do that. It's certainly not like that on the common S40 phones.
A WAP push arrives like any other SMS. The standby screen of the phone shows a message that a WAP push has arrived. The user presses a soft-key to open the message (button press 1). The phone then displays some of the message text, and as much of the URL as will fit. The user presses a soft-key (button press 2) and the phone starts the browser and goes to the URL via the WAP access point.
The user only knows that it is possible to change the gateway if they've been four menu levels deep into the phone settings.
We send a WAP push message to remote staff directing them to an in-house WAP site. That's just two button pushes from the standby screen of the phone. There's no chance we can train them to delve deep into their phone settings and change the default gateway that the phone uses when they accept a WAP push.
Once they reach the site we use WMLScript to ask a series of questions. We don't have a HTML version of the site. Vodafone's change stopped the WMLScript getting to the phone. Effectively Vodafone turned off old-school WAP without warning anyone.
It also hides the original Accept header, and presents a different list of MIME types. To make the problem even worse, it then refuses to pass across files that the phone would be perfectly capable of accepting. For an in-house site I work on, it broke our ability to deliver compiled WMLScript (application/vnd.wap.wmlscriptc) to phones that are perfectly capable of executing the scripts.
Sadly, I can only provide a few tantalising hints. Not because I'm sitting on the information, but because very few people have written about this, and I haven't yet tried it myself.
Wikipedia on xD cards
Instructions to fit an xD card to a Mattel Juicebox
A comment on LWN from Wookey, who knows a lot about flash
xD card pinout
My best advice is to ask people on the linux-mtd mailing list for specific details.
There's one important thing to remember about Compact Flash: it is not a raw flash device. There are robust filesystems to run on raw flash (YAFFS, JFFS2), but they only provide limited help when running on Compact Flash. A Compact Flash already contains a flash filesystem layer, which emulates an ATA disk on top of NAND flash. The manufacturer of this emulation layer does not publish documentation, and may change the implementation between production batches without changing the part number.
This is fine for a digital camera: it only writes a file when you press the shutter, and the user turns it off with a soft power button which will wait until the write is complete. The only way to turn off the power during a write cycle is to pull out the battery, and the manual tells you not to do that.
The question here is: what filesystem to run on top of this undocumented emulation layer, to provide reliability if the power is removed? I wish I had an answer to that. I feel your pain, as hardware designers always leave me stuck with this same unsolvable problem.
I'll pass on some advice I've received before: smartmedia and xD cards expose a raw NAND interface, allowing you to run JFFS2 or YAFFS directly on the flash. I've never managed to persuade a hardware designer to pursue this approach, but maybe one of you will succeed.
There's a lot of these chips selling, so somebody must be buying them. Have you tried putting your question to the local offices of the chip companies?
Even if they are done by the game engine, they aren't camera angles you actually use when playing the game. Take a look at the PGR shot, and ask yourself, "Could I really drive looking at my car from down there?"
I may be old-fashioned, but I prefer to play racing games with the camera looking forwards, and maybe with the speedo visible somewhere on the screen. Those wishing to take screen shots of racing games should read this useful guide.
OK, that's certainly a lot more original than most puzzle games. Pnickies never made much of an impact, possibly because the market was saturated with puzzle games, or possibly because it has an unsatisfying difficulty curve. Getting large combos at the beginning of the game doesn't seem to have much influence on your overall performance and score.
Your description for Drippy describes it as "Not just an old game with a different name and better graphics and enough little changes to evade copyright, but a whole new game concept." So why does the mechanic of merging blobs to get two stars remind me so much of Pnickies?
Also consider Box Backup. It encrypts the backups so that the server storing the backup doesn't have the necessary key to read the backed-up data. It's working well for me.
In particular, the failure of the x86 architecture to implement the Popek-Goldberg requirements. VMWare and Plex86 have to do a lot of work to paper over the cracks. Xen uses a modified guest operating system to get around this.
Popek and Goldberg worked this out in 1974. It's taken Intel a little while to notice.
You forgot to mention how every BSP author gets the chance to implement PCI slightly differently, so a card vendor can't write a single VxWorks driver and expect it to compile for every board.
On Linux I can write driver source that works for everyone. On Windows and Solaris I can produce driver binaries that work for everyone. On VxWorks I have to produce a page of instructions so that an experienced VxWorks developer can edit the source to match.
UK analogue TV is now almost entirely broadcast in 14:9. Unfortunately older TV shows were made in 4:3, so they slice off the top and bottom of the image. This is probably an attempt to make us buy digital receivers.
Also, most BGA sockets are prone to contact corrosion and just don't last very long.
Even if you can't purchase Apple-brand daughtercards, you can purchase 3rd-party upgrade daughter cards. The problem is that these are quite expensive.
As the referenced article said, it reduces battery life by 15-30 minutes. This should leave you with a realistic battery life of about 3.5 to 4 hours. My own experience is that an unmodified iBook is good for over 4 hours of editing text.
The change to battery life isn't large for two reasons. Firstly the PowerPC has dynamic power management, which makes idle time cheap. Secondly, a lot of the power consumption comes from the disk and display, which are unchanged by this mod.
The market for it on PowerPC may not be games, but embedded development. That wouldn't be quite such a difficult cultural gap for you to cross as business high performance computing.
Currently people are doing Altivec development with tools that require explicit specification of vector operations. It's painfully close to assembly programming. And if they aren't using GCC then they are probably paying around $3000 per development seat for this. If they are using GCC the optimiser isn't doing a great job on their code.
Your main problem is that there is no single company here to help fund development or provide publicity. The embedded hardware is often developed in house for a particular project, or bought from one of several small hardware vendors. Motorola already own a compiler company, so may not be keen to help out the competition.
Motorola Semiconductor makes PowerPC processors. Motorola Computer makes boards using PowerPC processors (from both Motorola Semiconductor and IBM) and Intel processors.
Do not confuse the two Motorola companies. Don't even assume that there is any communication between them.
Motorola Computer is supporting Linux. And despite all these Caldera announcements, they're using Debian on PowerPC internally.