View Full Version : Sharp and BSQUARE bring Windows CE .NET to new processors
Andy Sjostrom
02-07-2002, 08:50 AM
<a href="http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.020602/220370228&ticker=BSQR">http://www.businesswire.com/cgi-bin/f_headline.cgi?bw.020602/220370228&ticker=BSQR</a><br /><br />Current Pocket PC 2002s are all built around the Intel StrongARM processor. From what we know today, future Pocket PCs will continue to be built around ARM-based processors. They may use Intel's, and may use someone else's, and they will be even faster...<br /><br />This announcement talks about new multimedia devices and the partnership between Sharp and <a href="http://www.bsquare.com">BSQUARE</a>: "Through the partnership, Sharp customers can design for Windows CE 3.0 and Windows CE .NET, both robust operating systems for building the next generation of smart mobile and small footprint devices, and create products based on Win CE derivatives such as Pocket PC and Stinger."<br /><br />More chip makers are attracted to this growth market, and BSQUARE continues to excel!<br /><br />"Through the relationship, SMA will offer BSQUARE's custom, pre-configured and pre-tested board support package (BSP) for Win CE 3.0 and Win CE .NET. BSQUARE's BSP supports SMA's LH7A400. The LH7A400 is Sharp's first device in a family of highly integrated 32-bit SoCs based on the ARM9 core. Design engineers using Sharp's ARM9-based products will have access to production level source code for the drivers that take advantage of the wide range of LH7A400 on-chip peripherals. ... SMA's LH7A400 is an ARM-based, highly integrated chip that provides engineers with high performance while allowing them to reduce component count, save board space and reduce power requirements."
Gerard
02-07-2002, 06:51 PM
Yeah, right. BSQUARE, the company 'responsible' for the MIPS compiler, the company who released such glowingly successful (note: heavy sarcasm) gems as bInTouch, the bSquare Utilities Suite 2.0, and other fine software. The same bSquare who set new standards in customer support, staunchly ignoring requests for real assistance and instead delivering one after another corporate line of b.s. ...
Sorry, but I spent quite a little chunk of cash on bSquare garbage, and I continue to suffer daily under the burden of the MIPS chip, a chip which by all rights ought to blow the bloody doors off a 206MHz ARM, but thanks to bSquare Corporation's bungling lies there for precious seconds almost every time I tap the screen.
Thanks though for the heads-up; now I know in advance which devices to be avoiding in future purchase considerations. Just look for the bSquare link, turn around, and run away as fast as you can.
Jason Dunn
02-07-2002, 06:56 PM
Gerard...tell us what you really think. :lol:
Gerard
02-07-2002, 07:08 PM
Sorry if you got any on you. My 'spleen' needed venting. Just a wee bit bitter, yeah, but I did battle with so much of their buggy software it still hurts. The only good things they've made for the PPC are 'bFind' and 'bNotepad'. I do still use those, but will likely ditch the former soon, as Resco's global search works better. The Notepad opens most aything, including viruses, EXE files... nice tool for looking at what makes things tick. And it can handle huge HTML, something Tillanosoft's Notepad can't do. So my bitterness should be just that much qualified.
Jason Dunn
02-07-2002, 07:17 PM
I think you have some very valid points. bSqaure really angered a lot of people when they stopped selling so many of their applications, even if some of them were kinda' flaky. :roll:
Geoff
02-08-2002, 11:42 PM
I was wondering which MIPS cpu you refer to - There is only 1 that is CE certified MIPS cpu that can outpace the SA1100 and that core is made by Alchemy Semiconductor. http://www.alchemysemi.com
I've used several MIPS cpus and ARM cpus on various toolchains and it is the case that the StrongARM is faster than the NEC and Toshiba parts, but gets crushed by the Alchemy MIPS part.
However, I have to agree that the MIPS compiler that ships with MS product is a bit on the crap side.
What applications would you like to see?
Gerard
02-09-2002, 12:20 AM
Sorry, my ignorance of particulars is vast. I've read many posts regarding the bSquare 'crippling' of the PPC MIPS compiler, that's all. And a few others have insisted that, properly implemented, MIPS cpus are great.
As for what I'd like to see... how about WinRAR-like CAB file extraction for PPC? Having a CAB install rewrite my registry on ever software update is frustrating. Of course, I can just cut&paste the unpacked files into my preferred locations and then restore from a fresh registry backup... but it's so much neater to just do a component install manually.
And a utility for extracting files from any/all PC-based EXE installers, that'd be a big step in PPC independence. I just really hate having to sync. I do a lot of this already, opening many in Resco's Zipper, but many are resistant.
A hex editor? Maybe?
I don't know, just options. I want lots of tools for my Casio.
Aceze
02-16-2002, 12:35 AM
Well, I'm going to write this all over again, becuase this freaky phpBB just threw away my entire first post... Well, at least it gives me the opportunity to summarize a bit more.
Re: the bSquare/MIPS debacle:
I remember the issue quite clearly, as I was around when (and had many a discussion with) Larry Bank first made the discovery that the MIPS compiler that Microsoft was distributing in the eVC++ development package was severely broken (bugs that led to severe performance degradation). Microsoft, strangely enough, apparently outsourced compiler development to bSquare - who did quite a good job with the SA compiler - I think most people have been quite happy with the level of optimization in it. However, they made many mistakes in the MIPS compiler which led to dramatically poorer performance for the Casio units - performance which was definitely not warranted. In fact, while the SA chip is no slouch, it's main strength is in memory bandwidth, while the MIPS chips is quite good at keeping up in every other aspect, and even beats the SA chip in graphics performance. Also, the MIPS chip is capable of using 64bit instructions, but bSquare did not address this functionality in their compiler (which would have garnered even higher perforrmance for the MIPS chip).
Anyway, once the problem was detected, Larry and later on a few other developers made it an issue with Microsoft (and I remember, bSquare) about the problem. However as time passed by, it looked more and more that Microsoft/bSquare was not going to bother fixing the problem. In my (and a few other people's) opinion, Microsoft had made their decision on what chip was going to be used for future development and must have felt that the performance difference made grossly apparent by the inefficient compiler would be a good excuse to standardize to the SA platform (I wouldnt be surprised if Intel also had a say in this). Remember, this was quite early on (maybe about 4-5 months after the units launched!), so Microsoft knew their plans quite early. In essence, many of us felt that Microsoft and bSquare had hung the entire MIPS line out to dry because of Compaqs relative success at the beginning and the work necessary to bring the Casio compiler up to spec.
Either way, bSquare never fixed any of the problems in the compiler. According to Larry (whose opinion I do trust, as he's the first person to really do low level programming for the various PPCs due to his PacMan project in the Expansion packs), much of the performance gap in the SA vs MIPS programs stems from the inefficiencies in the bSquare compiler. With supported 64bit instructions, the MIPS platform might actually have been a faster chip than the SA - certainly at a similar clockspeed. Case in point, at 200mhz, the Japanese E750 running on the newer MIPS chip (VR4131) outperforms the SA line running at 206mhz (despite the bad compiler)!
Dont forget to blame Casio as well, as they're just as guilty of not pushing Microsoft/bSquare harder in handling this problem. Also, they're guilty of screwing around with their graphics drivers for the EM-500/E-125 - making it far less efficient at moving graphics around (splitting data writes to the graphic buffer into two separate 8bit writes, instead of a proper 16bit write).
All in all however, the whole incident left a very bitter taste in my mouth concerning support for the PocketPCs.
Aceze
vBulletin® v3.8.9, Copyright ©2000-2019, vBulletin Solutions, Inc.