Utilities v1.5 progress – March update

Here’s a new video showing another set of features of the upcoming v1.5 of my Utilities add-in, for the Casio Prizm. Note that this is only an early preview and some things may change until the final release. Meanwhile, feel free to comment.

How Android’s “won’t fix” problem is the result of poor standardization

During the past year, the WebView vulnerability(ies) in Android have been making the rounds in various technology-focused websites. More recently, another WebView vulnerability was discovered, affecting versions 4.3 and below of the popular mobile OS (or roughly 60% of the users). Three days ago, HotHardware released a piece on why Google will not patch this vulnerability on 4.3, let alone older versions.

As a quick reminder, Android 4.3, the last version of the Jelly Bean series of releases was launched on July 24th 2013 and its last point release (4.3.1) on October that year. That was 15 months ago. A device that shipped with this Android version was the second-generation Nexus 7, which is still under warranty on places where two-year warranty is mandatory, like in the EU. The Nexus 7, being a flagship Android device from Google, received updates to more recent Android versions; the same can’t be said about most other devices released with 4.3 or earlier.

Market Share of Different Android versions

Those 60% sure would like to be in the 39%.

 

Most of the discussion so far has been centered around whether the responsibility to patch older Android versions and/or push new ones to phones is on Google’s side or on the manufacturers’ side, or if the problem really is with the carriers, which won’t update their customized builds of the OS. There’s also the line of discussion that says such responsibility does not exist, because the problem is fixed in the latest Android version, and anyway, For God’s sake, are you still using a phone that came out six months ago? So vintage. Oh wait, how are you not using a high-end phone from <insert major brand>? (and even high-end phones sometimes don’t get updates past the next major release)

I would like to shine light on another side of the problem: the fact that smartphones, tablets and devices alike can’t be updated by the user software-wise. In fact, it’s not just the user who can’t update or choose to run a different operating system: I’m convinced that for the most part, if the manufacturers wanted to update their Android systems to a more recent OS version, or switch to, say, Windows Phone or Firefox OS, they would have much trouble themselves. And I pinpoint this down to two different but related issues, the lack of a proper drivers system on Android (possibly involving Linux) and the multitude of ways these devices boot their OS, expect updates and do basic hardware communication. Both issues are related to a bigger problem: the lack of standards in the world of embedded consumer electronics.

In this text I’m letting aside all the arguments regarding “open source vs. closed source”, “walled garden vs. open garden”, “but but binary blobs!”, etc. Both theory and practice have evidence that these debacles and inconveniences don’t matter, or there are ways to work around them that are successfully used in practice. The only “inconvenience” that might remain, is the hardware manufacturers’ wish for people to replace their “old” devices every six months or so. This turns out to be a game of extortion made for those who worry about their security: “if you want a OS patched against this horrible vulnerability, just buy a new device that won’t do much more than your current one, but will have that single line of code changed”.

In a perfect world though, manufacturers which wanted to play that game would have to do it in the clear, by explicitly locking their devices (as most already do) and announcing on the box that there will be no updates, fixes or warranties software-wise. (Curiously, the texts that say such things are usually free-as-in-beer software licenses, not software you pay for in the form of hardware). But letting aside the utopia and focusing on the two standards-related issues I mentioned before.

I said Android doesn’t have a proper drivers system. This statement can be taken as incorrect, because, after all, Linux is the part of the stack responsible for driving the hardware. But while Linux is not Android, Android definitely includes Linux, and their creators and maintainers make a deliberate choice to use this kernel. I’m not saying it’s a bad choice, well on the contrary – only Linux and a few other Unix-like kernels could scale down and adapt to the hardware and ARM architecture used in most handheld consumer devices.

Using Linux is taking a giant shortcut (again, that isn’t bad – reusing is good). Microsoft, for things like the (abandoned) Windows RT and Windows Phone, besides porting some of the upper layers of the Windows stack and developing new ones, also had to do additional work to get the NT kernel to run on such hardware. It’s worth mentioning that despite that effort, Windows Phone 8+ has hardware requirements higher than those of Android (comparing versions released in the same time span, please correct me if I’m wrong).

Going back to the drivers, many people say the big roadblock to making new Android releases run on (relatively) old hardware is the binary blobs, the closed-source drivers that control much of the hardware in those embedded systems. Now, a bit of anecdotal evidence: I use proprietary drivers from at least Nvidia and Broadcom on the Linux install on my laptop, and these have survived fine upgrades from Linux Mint 15 to 17, and multiple Linux kernel updates from at least 3.8.8 to 3.14.27. This is because the proprietary part is well separated from the things that can possibly change between kernel versions, and there are clear update paths defined.

Of course it helps if the maker of the proprietary drivers is interested in having their drivers run in newer operating system versions, but if all drivers were properly developed and not added into the system as ugly kernel patches (or should I say, “hacks”?) for which nobody has the source, as I’ve seen System-on-Chip manufacturers do (looking at you, Mediatek, Realtek, …), the problems would be mostly gone. The practice of doing such ugly source editing is one of the reasons I say that even if manufacturers wanted to, they couldn’t switch to another OS or update to more recent Android versions. I suspect that at some companies, just a few months after devices ship, even high-end ones, entire source trees, complete git repos, are rm -r-ed out of every system. Nowhere does the GNU GPL say that it’s not a violation of the license if you get rid of the source, does it? As if such license was ever read by said people…

There is another “entertainment” awaiting those who take the updating matter into their own hands and attempt to port the OS of their liking to their device, which is understanding how the device expects to be updated and how it starts its OS. While this is sometimes just a case of watching updater software do its job (that is, when an update is even available), often additional steps are needed, and this is where one finds out that most devices use U-Boot, but often it’s even more patched than the Linux kernel, and again, source code is nowhere to be seen.  There is then a myriad of ways to boot the kernel and from there to starting userspace, and fortunately this is more or less constant between Android devices. Still, undocumented quirks are everywhere, and one basically has to work with each device on an individual basis. The same model has various versions? Great, expect to repeat that work for each version.

G1,_Nexus_One,_Nexus_S,_Galaxy_Nexus

These all have a color screen, a speaker, a microphone, some buttons, and can make calls. It’s 2015, standards exist, they must be really similar, right? Yes, as long as you don’t attempt to change their OS…

 

And finally, we get to what I personally think is the core of the issue: each device is too much of an individual situation, and work must be done for each device. It’s been like this since, well, ever – for well more than a decade, since what can be called the first smartphone was launched (HTC Wallaby). In the beginning, I think this was justified – the hardware was not very powerful to be able to handle complex software abstractions and advanced boot methods, nor did software advance at today’s pace. Consumer handhelds were also not as ubiquitous as today. We can compare this to the evolution of the Personal Computer, where in the end everyone settled around the IBM PC standard. A corresponding standard for the smartphones and tablets everyone has is yet to be found – such a standard is what enables one to buy almost any computer off the shelf and install a different OS in it, or a different version of the same OS. It would also allow for buying devices without OS preloaded. This means the user would be able to control its user experience and security. I would no longer have to buy a new phone to stay safe, just because (and this would happen inevitably – no software is bug-free) a vulnerability was found in Android 4.2.

Sure, despite the PC standards, there are computers in the market which come as locked down as today’s tablets and smartphones. And there is no problem with that, as long as such locked-down things are not the only option. When locked-down is the only option, or unlocked options are prohibitively expensive, there is little room for innovation, consumers end up not having much to choose from, and eventually, no way to have durable hardware, if all the available alternatives support the “update the hardware to update the software” scheme.

Even in today’s context, there are better ways to ensure operating systems keep up-to-date in terms of security, without exactly requiring a change to another version. Google should look a bit more into Microsoft, which got one thing right on Windows for over ten years: Windows Update. Microsoft ensures support for a specified number of years for its OS, independently of the hardware it runs on; this is something consumers like and enterprises love. Google seems to have learned, so much that it is moving a lot of things that were previously built into Android to Google Play Services, a component that can be updated through the Play Store like other apps. Unfortunately, this means making more and more of the OS closed-source, but that’s another subject. Personally, I would rather pay, say, 10 to 20% of the original price of my phone with each update, than having to buy a new phone when I definitely don’t need one except for the bits executing in its CPU which all of a sudden are “old” and insecure.

I believe an update scheme a-la-Microsoft would be profitable for Google and let them have a bigger market share in the enterprise. (Actually, if Google is taking any of that market share, is because of the “cloud! factor” and because enterprises are moving to Google’s systems as “it’s what everyone uses”, and not because it fits their needs better). It could be perceived as terrible for hardware manufacturers, because there would be one less reason to buy new devices, and let’s not forget Google also sells hardware. Apple sells hardware too, and people happily run Windows, Linux or whatever on their Macs and MacBooks, and I doubt Apple has lost any business because of that: well on the contrary. It shows the two things don’t need to be exclusive. Apple still manages to sell a lot of Macs and people who want to stay with an older machine still enjoy updates for much longer. In their line of consumer handhelds, while it is perceived as being even more locked down than the competition, each model tends to get at least two major OS updates (for free!), making people who aren’t in an “upgrade cycle” happier.

I am actually surprised and annoyed that consumer rights associations don’t complain more about the situation. It seems that certain companies were successful in sinking into people’s minds the idea that in the case of phones, tablets, smart watches, etc. the software can’t be decoupled from the hardware. In fact, in its current state, it’s really hard to decouple it, but it’s because that’s what manufacturers want, not because of technical obstacles. Perhaps this thinking comes from the fact that, after all, the introduction of smartphones and tablets to the general public was done by Apple, which presented their vertically-integrated walled-garden first and foremost, and giving everyone else the idea that was the only way these devices would ever be successful.

To finish, another anecdote. I have bought a cheap unknown-brand tablet with a x86-64 Intel CPU. It runs full Windows 8.1 and is fully up-to-date thanks to Windows Update; I’m very happy with it. When Windows 10 comes out I plan to install it; either the upgrade is as easy as from 8 to 8.1, or I’ll install it manually by connecting a USB stick and using the UEFI. As we know, Windows is closed-source, and drivers are nothing more than closed-source “binary blobs”. Still, I know I’ll be able to install most if not all of these drivers in Windows 10, to a point where I can use that version of Windows on the hardware I have now. Perhaps I’ll need to throw some money at Microsoft to have Windows 10, if that idea of giving it for free to users of 8.1 and 7 turns out to not apply to me. Had I bought an Android tablet, I could throw money at Google and at the manufacturer, and I’m sure that after a year or so, neither would put a single update out for the hardware. The money would have rendered a new piece of hardware, yes… but of how much use is another piece of plastic and silicon, when the previous one works perfectly? They sure like to contribute to e-waste.

Related question: are there any phones running full x86 Windows? Perhaps once Windows 10 comes out?

The situation of the Casio Prizm

Note: this was originally published as part of a post on Cemetech.

The status of 3rd-party development (and general user interest) on what is currently Casio’s flagship non-CAS calculator, is disappointing and inglorious, but the user community is not the only guilty of the situation. I would say there is a marketing problem on Casio’s side: the Prizm is only appealing to students and teachers that are already used to Casio calculators. Personally, I know that if it weren’t for the recommendations of my maths teacher (who is a big proponent of these calculators for their ease of use and similar UX across graphic models), I would have bought a non-CAS Nspire instead, or eventually a black-and-white Casio model.

Despite great initial success (first on Omnimaga and then on Cemetech), the Prizm never really caught on with the developers community and I feel it really never caught on with general students, either. While it is true that the Nspire, and more recently the HP Prime, have more powerful hardware, the first also has a more complex system that actively tries to block 3rd-party binary software, and the second does not have the same target market (the HP Prime doesn’t have a non-CAS version). Cemetech seems to have turned more to the TI-84 Plus CSE, but while it doesn’t have the software constraints of the Nspire, it has inferior hardware specs that put it on another league (I guess it had some success on this community because it was similar to “what people were used to”, i.e. the old TI calculators, unlike the Prizm and the Nspires).
Still, and somehow, the Prizm seems to have a notable market share in Asia, but due to different character sets and more, the western and oriental communities don’t communicate much. From what I understand the Prizm seems to be used in China at a higher education level than in the rest of the world.

From my point of view, the marketing done by Casio for the Prizm, was as simple as saying “we were the first to release a full-color graphic calculator, here it is” and running a few contests while the model was new, but without any effort to distinguish themselves from the competition that would come later (and made a much bigger advertising effort in many markets). Even though they were the first to show a calculator with a full-color, high-resolution screen, while simultaneously being allowed on most official exams, I feel they did not fully explore the possibilities of the screen or the OS and hardware behind it, let alone explain them to users.

On the technical side, many aspects of the OS on the Prizm could have been polished (certain things as the Program editor feel really slow at the default clock speed, as do the constant picture decode and redraws when a g3p is shown on the screen, for example in eActivity). Things such as the separation between a “Main Memory” and “Storage Memory”, while familiar to existing users of Casio systems, are metaphors unused on other computer systems and while technically sound (and allowing for backwards compatibility), are inadequate for a great user experience – I know of people who don’t quite understand why they get memory errors on lists, matrices and Basic programs, even though they have plenty of storage memory, and I also know the problem in understanding different memory sections is common to TI calculators. OS updates never (are yet to?) addressed this, but it’s unlikely they’ll ever address it because it would require major technical changes, perhaps even hardware changes (more RAM or dynamic RAM allocation, anyone?) and the development of a platform that’s not akin to anything built by Casio in terms of calculators, which means users would need to relearn it again – if Casio builds something too much different from previous generations, the results might not be positive (look at how the Nspire went on the TI side).

Then Casio moved on to the new Classpad models (which not everyone can buy, because they are not allowed on all the exams, and not everyone needs a CAS calculator on university), and the Prizm was more or less forgotten. While Casio’s offering has some points that stand out from the competition, it has outdated hardware specs when compared to the other CAS calculators.

Casio calculators become “forgotten” not because the manufacturer stops providing support for them (the Prizm just received the 2.00 OS update, and a new official add-in – so things are well on the contrary), but because there is little effort to publicize these updates to their older models. I guess if they don’t move more, it’s because they are selling and working “good enough” for them. Which isn’t a synonym of things being “good enough” for the power user community.

In my opinion, the Casio calculator development community is too spread among many small communities, which have low levels of activity (especially when it comes to the Prizm) and in some ways even alienate from each other, instead of uniting to get things forward. Note that I’m not suggesting the creation of a new community to hold all the 3rd-party Casio development (see xkcd 927), but instead more communication and joint ventures between existing ones, for example in the form of contests. Unfortunately, different ideas and culture seem to make this difficult most of the time, but it would be great if people managed to overcome that in favor of higher goals.

Nokia OS history, fragmentation and other stuff

Every news piece I see about Microsoft buying Nokia, seems to focus on the business side of the things – “was this a good move for Microsoft?”, “was this a good deal for Nokia?”; on the future of Windows (Phone), and on the patent portfolio Microsoft just licensed for 10 years (to me, in practical terms this equates to buying…). But I think everyone is forgetting what Nokia did before the Microsoft partnership involving Windows Phone, more precisely the software that runs on their older phones. What will happen to these pieces of software, some abandoned and others not?

I am not a Nokia user and I haven’t had extensive contact with their hardware or software. I do have some friends with modern Nokia feature-phones and non-WP smartphones, and I know a bit about their experience with them. I have also tested some of Nokia’s experimental/in-development Linux based systems on emulators (yes, Nokia wasn’t just Symbian and WP). That said, I apologize for any wrong facts on this post. I will be using Wikipedia as a (improper) “source” for some things.

Nokia developed, or supported the development, of several embedded operating systems. These ran and run mostly on feature-phones, despite some of them supporting third-party software and having other features that make me label them as a “smartphone with alphanumerical keyboard”. S40 is an example of this, having debuted in 1999 and being used until 2012 (it powers the recent Nokia Asha phones). (source)

Recently, Nokia has also developed Symbian-based systems that run on touchscreen smartphones.

The Nokia 7110 (1999) and the 6300 (2007) are both powered by S40

Then there’s Symbian, which was born not just as a Nokia venture. Symbian, a proper smartphone OS, was born as “a partnership between Ericsson, Nokia, Motorola, and Psion” (source). Nokia used Symbian on most of their earlier smartphones, being the responsible for Symbian’s really high market share, which lasted until the end of 2010.

Nokia N80 (2010), running S60

The S60 platform, first released in 2002, was based on Symbian and during the course of its life, it powered phones with and without touch screens (yet again, cases of smartphones with alphanumerical keyboards). Later in 2010, Symbian^3 was released, to power the Nokia N8. More or less by the same time, Symbian, once made open-source, turned into a licensing-model only.

In February 2011, Nokia announced they were dropping Symbian-based systems in favor of Windows Phone. Later that month, the Nokia 808 PureView, with a 41 (forty one) megapixel camera (just like this newer one), was announced, to officially become the last Symbian smartphone.

Nokia Anna and Symbian/Nokia Belle were released later in 2011 as updates to Symbian^3. Some time between Anna and Belle, Nokia outsourced Symbian support and software development to Accenture, a situation that will stay until 2016. The second feature pack of the Belle update is the latest version of Symbian as of now. Will it be the last? I would say so.

Screenshot of Nokia Belle

Nokia also developed apps and internet services for the later Symbian updates (these included an app store, the Ovi Store). Ovi was the brand for many of these apps and services. Among the Ovi apps, there was Ovi Maps, later renamed to Nokia Maps in 2011 and now called HereHere runs on many mobile operating systems, not limited to those developed by Nokia, and provides map and traffic services to Windows Phone 8. (source)

From Belle on, it’s what you probably already know – more and more Lumia smartphones powered by Windows Phone. For feature-phones like the 2012 Asha models, Nokia seems to have reverted to S40, not Symbian-based.

And this is the story of Nokia’s moderately successful operating systems more or less known by the common user. But Nokia invested in other projects not so widely known to the general public, but which developers know well. It is the case of the Qt framework, which was developed by Nokia after they bought Trolltech, the original developer. Qt was used in Symbian; a bit after Nokia dropped Symbian, they sold the licensing stuff to Digia, that now owns the Qt trademark and the Qt Project.

Nokia also invested in other OS projects besides S40 and Symbian-based systems. Maemo, an open source software platform intended for smartphones and tablets, was based on Debian Linux. It made its first big appearance in 2009, with version 5, as it powered the Nokia N900. From my point of view, this device had some flaws and ended up being only loved by Linux geeks. But this is my personal opinion, of course. I know I would have liked to own one of these 🙂

Nokia N900 (2009) running Maemo 5 / Fremantle

By February 2010, it was announced Maemo would merge with Moblin, to create MeeGo. Finding the story complicated already? The best (or worst) is yet to come… In September 2011, roughly a year and a half after that merge, the Linux Foundation, which hosted MeeGo at the time, announced it would be terminated in favor of yet another project, Tizen. By the same time, Mer appeared as a fork of MeeGo. A company called Jolla, from Finland, then started cooperating with the Mer project to create the Sailfish OS. Confusing enough?

Basically, from the initial two development efforts (Maemo by Nokia and Moblin by Intel) we walked towards six (and counting) different mobile-oriented Linux-based operating systems, some dead, some dying and others just starting. There doesn’t seem to be much app compatibility between these – other than good old Linux binaries (but that applies to Android too and I’m not talking about that kind of apps), and maybe some HTML5 apps (and of course, all the web pages).

In case you didn’t notice, Nokia (now Microsoft) is obviously not involved in any of the current projects (Tizen, Mer or Sailfish) – it’s just not part of their new strategy (and if for some reason anything Linux was involved in the current strategy, I’m sure Microsoft would dump it ASAP, or at least hide it from the public).

Obviously, as of now, one can’t even speak about the market share of these six mobile OS, without having to use scientific notation with negative exponents and a big amount of small-number guessing. To my eyes, Maemo, despite being old and officially unsupported, seems to have a bigger community (and, I guess, a bigger market share) than any of the other small projects that were born from it and forcibly declared as its successors. Or perhaps, I should say that a big part of the community is still centered around Maemo – even though most of the development actually occurs on the new projects.

Add the six I mentioned, to the count of other newborn mobile OS (Firefox OS, Ubuntu for phones…) and make your bets on which one (or whether any of them) will get a market share we can measure, with a percentage above 1%. Maybe if they all got together and united their efforts… oh wait, refer to “MeeGo” for the expected result. But, I’m getting off-topic…

…or perhaps not so off-topic. Nokia, before Microsoft, and during the course of its handset making history, also developed a bunch of different platforms – S40, Symbian and everything that ran on top of it: S60, Symbian^3, Belle and I may be forgetting some. Not all of these were compatible with one another and they had different user experiences. Now compare this to Apple’s iOS since the first iPhone, or Android since the first phones that ran it. Sure, there were lots of updates to each of these systems, and sometimes the user experience changed a lot, but they never changed names and there was always some kind of data and app compatibility.

Applications one developed for Android 1.6 most likely still work fine in 4.3, even if sporting an outdated user experience. The user experience has changed but progressively, and much of the practice an user gets from using earlier versions is still valid on the latest. On the Nokia side, from S60 onwards, there was some app compatibility (but from what I see, not as good as Android’s or iOS’s), but the constantly changing names and looks confuse consumers.

MeeGo also ran on netbooks, in-vehicle infotainment devices and other embedded systems.

Since the Linux-based Maemo and successors had nothing to do with Symbian, Symbian-based and Linux-based systems always lived in different universes, despite being both made by Nokia for similar devices. And now Windows Phone has nothing to do with either Symbian or Maemo/MeeGo – it’s yet another “ecosystem”. Talk about fragmentation in Android, and I’ll show you all the systems created by Nokia.

Nokia managed to start more mobile OS projects than companies like Microsoft, Apple or Google, and yet didn’t manage to stick with any of them, except maybe Symbian… but even on the Symbian land, there were lots of changes to user experience over the time, and to the end user it definitely didn’t feel like it was the same OS when they bought a new phone.

And now that Nokia is basically Microsoft, users of the multiple platforms that reached the mainstream consumer before Nokia made Windows Phones, are pretty much screwed. Nokia/Microsoft no longer cares about their non-WP phones except for what I call “traditional support” (phone breaks, gets replaced or repaired; security bug is found, gets fixed) – but users expect other types of support for smartphone OS, namely updates (to fix non-critical bugs, for example). And maybe even the traditional support is compromised.

I see a lot of wasted work and money on the Nokia side, investing on things that eventually never went forward because at some point they lost support from Nokia. I even think much of the recent waste over the past two/three years was purposeful (*cough* Stephen Elop *cough*). At the same time, I can see the old Nokia strategy as “not putting all the eggs in the same basket” – they weren’t just committed to Symbian, but also S40 and Maemo/MeeGo, and later Windows Phone. Then they decided to drop all the eggs but S40 and Windows Phone. And now that Microsoft bought Nokia, I believe they are going to drop the S40 egg too.

Ultimately, I believe this isn’t good for the consumer. It loses yet some more mobile OS choice, even if these choices weren’t so popular – at least, they were something different. The choice is more and more between Android, iOS and Windows Phone, and if the currently in-development projects don’t hurry to get on the market to earn some users, they may suffer the same fate as all the other ones that got killed or merged, eventually turning them into abandonware.

Hardware-software compatibility on handhelds

It would be good if one could go to a store, buy any smartphone or a tablet, and later choose what OS to run on it. Like what happens with desktop and laptop computers, you buy any one of any brand (even Apple!) and you can almost certainly run a OS other than the default on it – some things are taken for granted on a PC, which allows for this kind of freedom of choice.

Sure, you can install custom ROMs on smartphones… now go ahead and buy any one that isn’t popular and see what happens. If there is not a big enough user base most likely there isn’t anyone to develop custom ROMs. And unlike what happens with PCs, there doesn’t seem to be some list of assured features and standards. On personal computers, even on the ones built from OEM parts and no recognizable brand, it’s as simple as setting a boot device that is an OS installation disk. Sure, you need drivers to get the full potential of the hardware. Still, some things Just Work(tm), like PS/2 keyboard and mouse, serial ports, VGA video out (and I don’t mean graphics acceleration) and disk I/O.

Isn’t it about time some sort of standardization starts happening for mobile devices too, both at the hardware (charging connector/method) and software (system booting, basic elements)? The idea would be that simple things like storage I/O, screen (without GPU), touchscreen input (even in single-touch mode) and hardware keys Just Work(tm) because they are really easy to drive by the OS?

Look at something like KolibriOS. It is pretty limited on what it can do on a PC, because of a limited amount of drivers are included, and anyway everything is very simple. But as things are now, there’s no way one could write a KolibriOS that would run on all the phones and tablets the same way Kolibri runs on almost every PC, even with limited functionality.

It’s certainly a distant dream, seeing that even charging connectors are something we are yet to get quite right… all to make big brands happier at the cost of unhappier customers – even if they never noticed they were less happy because of that. </rant>

Casio Prizm software

Own a Casio Prizm? Please take five minutes (probably less) to fill my survey on product IDs. It’s as easy as looking at the back of your calculator and typing 15 characters. No personal information is collected. Thank you!

I developed some add-ins for the Casio Prizm series of graphic calculators (fx-CG10 and fx-CG20). The software is available for download directly from a server of mine, sometimes from Cemetech and sometimes from Casiopeia.

Utilities

clockeditor

The Utilities add-in is exactly what its name says: an add-in full of utilities not originally found on the Casio Prizm calculators. This includes:

  • Clock, with time and date and the tools for adjusting them;
  • 20 chronometers (can go up or down) with accuracy as good as the 128 Hz tick allows (it’s better than 1/100 of a second);
  • Tool to fine-adjust the backlight level (from 0 to 244, versus the 1 to 5 provided by the OS);
  • Tools to adjust the poweroff and backlight timeout to values not possible through the OS default tools;
  • Power information (read battery voltage level, power source, battery setting and more);
  • Many lantern types (make an expensive and inefficient lantern out of your Prizm);
  • Calendar with agenda (add, edit, view and delete events on days, search events, week and month views, and much more);
  • Task list (add, edit, view and delete tasks, which are basically calendar events without dates);
  • File manager (rename, move and copy files and folders, with long-file-name support and non-capital letters support). Also allows for opening text files, compressing and decompressing files in a special format, and searching for files;
  • Text editor (create and edit text files);
  • Balance manager (manage your pocket money);
  • Password generator;
  • TOTP authenticator (like Google Authenticator and compatible with it, but on a calculator);
  • Graphical memory usage viewing tool (check how much Main and Storage Memory is used with nice progress bars);
  • Add-in manager (choose which add-ins are available for launching in the Main Menu without having to delete them);
  • Function key color selection (select the color of the function key labels throughout the OS; I recommend blue if you’re tired of black);
  • System information viewer – view the OS and bootloader version and timestamps, calculator model information, Renesas CPU version registers and the unique device ID.
  • Calculator lock with numeric code (like CGlock but more advanced);
  • A way to save the current time as a decimal number to the OS alpha variable T (you can use this on Run-Mat and almost everywhere by pressing ALPHA and then the division key).
  • Lots of settings to make the add-in behave the way you like.

All this in a binary file under 185 KiB!

Version 2.1 of this add-in was released on June 21, 2016, with this most likely being the last release; at this point Utilities is stable and full-featured, as you see in the above list. New releases will only happen to fix bugs, without increasing the feature list. I have tried very hard to make sure this add-in provides something useful for everyone who owns a Prizm.

Download g3a

Download ZIP of edition with support for running PicoC scripts – More information about PicoC

Thread at Cemetech

GitHub repo

Image viewer

View JPEG and PNG images on your Prizm. Progressive or lossless JPEG and interlaced PNG not supported. Has strip functionality for linking (not embedding) images on eActivites. Stable version 1.0 is out! More information on the Thread at Cemetech, or download the g3a – just copy to your calculator (out of any folder!) to install.

Eigenmath port

Screenshot of my Eigenmath port

Screenshot of my Eigenmath port

I ported the Eigenmath symbolic math engine, by George Weigt, to the fx-CG 10/20 calculators. Version 1.0, stable, is available for download, with all the results matching the ones given by the PC version. Updating is heavily recommended, because there are lots of new features in comparison to the first release, not to mention more ability, stability, and many bug fixes.

This port includes a function catalog, ability to create and execute scripts, draw graphs, and much more. All 100+ Eigenmath commands work. Output is pretty-printed whenever possible, and 200 lines of output are stored for scrolling at any time. Command execution can be stopped. The state of the add-in is optionally automatically saved when exiting. This add-in can also act as a eActivity strip.

Download or find more, updated information on the thread at Cemetech. GitHub repo.

Discontinued software:

CGlock

An add-in that lets you protect your calculator with a 4-digit code. It can be set up to automatically turn off the calculator when it is locked, to not show the Casio logo (and consequently the owner information) at turn off, and to open Run-Matrix after the correct unlock code is entered. If the Prizm is rebooted or the batteries are taken off, the calculator goes unlocked – so this program only provides mild security for your calculator (you can always epoxy the reboot hole and the batteries compartment, but do so at your own risk).

It saves the code and the settings in the main memory. I have some ideas for new features, such as hashing the code for extra safety and implementing CGlock’s own owner information display, since the Casio one is easily crackable, which I’ll implement when I have time and feel in mood.

Download from Cemetech

OverClui

OverClui is a tool for overclocking the Prizm’s CPU based on the work of Ashbad and brijohn at Cemetech. The difference between this and their own tool, Pover, is that this one has a nicer GUI, and is more noob-friendly. It doesn’t let users overclock to 101.5 MHz but only to 94.3 MHz to avoid problems, even though recently I found out some calculators don’t handle the 94.3 MhZ speed and thus can only to 87 MHz safely.

Use at your own risk, no warranty provided. If the calculator shows a “SYSTEM ERROR” message when overclocking to 94.3 MHz, please press EXIT to reboot, don’t overclock to that speed again (which also means you won’t be able to run the latest version of the game Gravity Duck on your calculator) and let me know in the comments.

Download from Cemetech

My cheap Android tablet is fixed!

Some time ago, I posted here in the blog that the cheap Android tablet I had bought four days before, broke. Turns out the problem indeed was the corruption of the internal microSD card, which acts as the main memory of the thing.

The tablet in question is a “Flytouch 3″, P041 model with silver back. The processor is an Infotmic one, as usual with these cheap tablets (fortunately,  Chinese makers are now moving to better dual-core Cortex processors). The original internal microSD had 16GB, no brand and said it was a class 4 card. Finally, after disassembling the tablet and taking the card into a reader on the PC (to try and format the card, since the tablet wouldn’t want to write to it and would fail every system update attempt), the microSD finally broke and now it’s not recognized on any reader – a low-quality card, now dead.

I ordered from Amazon another 16GB card, this time a class 10. I put it on the tablet, assembled it back, and the bootloader could flash a new update to it fine. Android is now blazing fast, either because the card is a class 10 or because the old one was very damaged.

So far, everything’s working except the hardware wifi switch I accidentally broke when the tablet was open. Again, I had some luck, as the switch was left on the ON position – and curiously, the wifi connection seems stable than before.

Let’s wish this thing keeps working as it has until now… it’s been almost 24 hours since I put the new microSD in.

Merry Christmas!

I know it’s a bit too late already, but since what matters is the Christmas spirit and not the timings, here are my wishes for a great Christmas and a happy new year 2012. Let the happiness and healthiness be with you this Christmas and new year eve, as well as throughout 2012 and, well, your whole life. I hope all your good wishes come true! 😀

Now, my turn on Christmas wishes: let’s hope my new shiny, cheap Android tablet I bought (Flytouch 3, P041 model, not a Christmas gift!) gets fixed – its internal memory (a microSD card) is corrupt. Now I need to fix the microSD card in a Linux computer. Linux computer? Check. SD card reader? Check. microSD reader? Missing. Trying alternatives… microSD-to-SD adapter? Missing… Santa, all there is on my gifts list is a way to fix that tablet’s microSD, I want a microSD-to-SD adapter or a USB microSD reader (costs $1)!

I’ll let you know if/when I fix the device and get rid of that damn error the Flytouch returns when trying to burn the Linux kernel to said microSD!

Merry Christmas!

gbl08ma / Gabriel Maia

The Raspberry Pi: What it is and why it will make a difference

I’ve met the Raspberry Pi project around three months ago, and immediately fell in love for its concept and idea: to build a extremely cheap Linux box that could be used to teach children the world of programming, Linux and even open source in general. But when I first knew about this project (it was on Slashdot if I remember correctly), me and lots of other people were skeptical about it, specially because of the aim price (USD $25/18,5€), because of the size of the prototype board (the first one presented was no big than a USB flash drive, and in fact, was smaller than many of them), and because their website consisted of a single page with an image of that prototype board and a few technical details; it also said the Raspberry Pi Foundation was a charity (non-profit).

I forgot about the project for a few weeks: like many other people, I thought this was no more than vaporware. Later, when I visited their website again, I found it to be much more complete, and it already had some more information and more facts had been confirmed. From then on, I began to check the website much more frequently and, currently, the Raspberry Pi doesn’t look like vaporware anymore: there are alpha boards built that have been distributed to various people doing software work on them, and the project staff has ran demos of the Alpha boards at many meetings. The Raspberry Pi was and continues to be responsible by news articles, sometimes front-page articles, on many technology sites. They also shown on UK television and radio. All this, and they haven’t released a final product to the market yet!

So what is the Raspberry Pi, in conclusion? It’s a extremely cheap, cheaper than many books, embedded Linux board. At launch, there will be two models: A and B. The model B has better features than the A, they will cost $35 and $25 respectively. Behind the project there’s a charity with the same name, the UK-based Raspberry Pi Foundation.

Both models feature an ARM11 Broadcom CPU clocked at 700MHz and a GPU capable of drawing Full HD H.264 videos at 30fps, and supporting OpenGL ES 2.0; a SD/MMC/SDIO card slot from which the OS will boot. For video output, the Pi has both an HDMI connector and a good old composite video connector, which means the Pi will be able to display not only on a modern LCD with HDMI connectors, but also on older TV sets and displays that feature composite video input(s). The RAM varies according to each model, and is presented stacked on top of the CPU (PoP configuration). Both models have some GPIO (General Purpose Input/Output) pins, although nowhere as many as things like the Arduino.

As for power supply, the Raspberry Pi will ask for a 5V input, and it should run off 4 AA cells. It will use a micro-USB connector for power supply, but note that it doesn’t act as a USB client device (it only draws power from micro-USB, no data). The energy consumption of the board is also incredibly low, and I believe it is lower than the consumption of many devices in standby mode.

The publicly shown Raspberry Pi Alpha board

The publicly shown Raspberry Pi Alpha board

Model A will only have 1 USB port, no ethernet and 128MB of RAM, whereas the model B will feature 2 USB ports, an ethernet jack and 256MB RAM. The final PCB design has been released, after lots of work doing the routing of the tracks of the PCB to ensure the maximum efficiency of the Raspberry Pi; the board will have the same area as a credit card (it’s amazing how could they fit all the connectors in such a small size board).

Oh, and I forgot to say: the Pi also has a 3.5 mm jack audio output; combine this with the small form factor of the board, some portable power supply and buttons connected to the GPIO, and there you have a very powerful MP3 player that also turns into a full-featured PC when you connect a display, keyboard and mice to its USB port(s). Or you could bring a touchscreen and make your very own Android/Ubuntu/whatever Linux tablet!

The circuit scheme of the final boardThe circuit scheme of the final board

As for the software, the board is designed to run ARM Linux distros, but people are already planning on porting other lightweight OS – don’t expect Windows in any way though as a) this device is simply too open-source for Microsoft’s mind and b) There’s not enough RAM to run Windows 8 in any way. Plus, WINE and other Windows abstraction layer software will not work, as these are not designed for ARM. Apart from these limitations (that most certainly don’t affect you unless you were expecting to make a hardcore gaming machine out of it), the Pi will do, better or worse, practically everything you do with a PC: web browsing, email, word processing, spreadsheet, instant messaging… for more advanced users, this is also a perfect server, either for serving files on USB drives, or hosting websites. For those (of any age!) willing to learn (embedded) software development, this is also the perfect device – specially because it’s cheap as hell, when compared to things like the successful Beagleboard.

I guess that we only need to allow time for humans to develop uses for the Raspberry Pi, and some of them will drive our minds crazy I’m sure. Enough presenting the Pi, if you want to know more you can do research…

Why I think the Pi will make a difference

You already saw what the Pi is from my quite long introduction above. I won’t say this is a revolutionary device, that will change the way we see technology. I won’t say that this is going to cause an impact as big as the iPhone caused on mobile phones or as the iPod on digital music, either, specially because a) the Pi doesn’t have an Apple on the back, b) the iPhone/iPod weren’t news either, since things like them already existed before; that fruit company only made them friendly to the masses (and credit to them for that).

Other thing that makes me think the Pi won’t reach the intended audience so fast as some expect is it’s appearance. I don’t want to make more analogies with Apple’s devices, but please allow for just another one: smartphones existed well before the iPhone, and I have an HTC phone from 2005 that did more (has 3G connectivity, for example) than the first iPhone, that was launched much later. Then why didn’t the older smartphones make much success? I don’t think expensive is the problem, but their look: most of them look ugly, to the masses at least, something the iPhone did better (just like with most recent Apple products).

Stopping with Apple analogies (I promise!)… the Pi is an innovative product by its size, its price and its main objective. If enough people know about it, it will suppress many markets, such as the thin clients one. From my point of view, this is the most cheap and minimal mini-ITX you can get, with the detail it doesn’t run Windows, but that is a matter of getting the world used to Linux. Due to its small power supply requirements and the cheap price, it will also bring computing where it is very rare nowadays, enabling people in development countries to have their first PC (or PED – personal embedded device 🙂 ). If we find a way to cheaply connect the Pi to the internet no matter where one is, it is even better, because people that have gain access to the ‘net and to who we teach how to use it, will eventually become better informed people.

In other words, this is a bit like the OLPC project, except that, at least in my honest opinion, and based on what I know from the OLPC project (which might not be accurate), it is being done with much more responsibility and a true knowledge of the requirements of the target audience. It also uses emerging technologies such as Linux for the ARM architecture, contributing to the evolution of the open source universe. But still, I don’t want to say the Pi is the perfect device: the Universe doesn’t allow perfect things to be made, duh. So, not being the perfect device, there’s always space for improvement, specially because one size doesn’t always fit all, and people will always one to thinker with a Pi to make them more like their own definition of “perfect”.

Other important difference in comparison with the OLPC project is that it isn’t just for children: indeed, the first batch of 10000 Raspberry Pies will be more targeted at developers and hackers (that doesn’t mean some “hackers” aren’t as young as me…), however and unlike was wrongly stated in many news, any person can buy it. Detail: I’m not yet sure if the first batch will be sold as a buy-one-donate-another project, making you pay for two Pis whereas you’ll only receive one, having the other going to charity. Please enlighten me on this subject!

The defects of the Raspberry Pi

As I said, this isn’t the perfect thing, and I think it’s important to point out its defects and limitations, because only this way we can improve on them. So, here are the things that according to my thoughts are yet to be solved or better discussed:

  • Peripherals: the Pi can be considered nothing more than a PC’s motherboard; it still needs you to have all the peripherals, from keyboards, mice, SD cards, and specially, a screen where to show things. The screen is the most expensive part, if you assume people can’t use an existing screen because of e.g. the lack of one.
  • Power supply: well, this is a “defect” that comes with every device, so I’m not considering it as a defect, but more of a “thing to discuss” – and many people are already discussing it, fortunately. Even if the Pi consumes such little power that it can run of standard AA cells, the things you’re going to connect to it won’t. And being the Pi basically just what a motherboard is to the PC, it’s pretty useless without some input/output devices – and these will consume much more power than the Pi. Well, we can assume you only connect a four-line character cell display to it, and a USB keyboard for input, and then use the display to show four lines of Linux shell – not very practical, obviously.
  • Memory/CPU specifications: As I said above, it’s not going to run the traditional Windows, nor a recent Firefox on Linux, at least until they stop making memory-hungry Firefoxes. It’s all a matter of studying the capabilities of the device and see if it applies for your project. I think the low specifications of the board also have a positive point: It will teach the young developers how to make apps that don’t use 1GB of RAM after half an hour of use, thus teaching these developers how to manage the system resources.
  • The case: it’s known that the Pi will ship without case. There will be cases available on the online store of Raspberry Pi, but of course these cost some money, increasing the price of the device if you must have a case. Of course, we can’t see just the negative part of this: the lack of a case opens people’s mind to creativity and curiosity, making them poke inside the Pi. If it breaks… well, if you have enough money to buy another, that’s not a problem. However, if we want to incentive children to learn programming with the Pi, it must be made somewhat attractive.

Finished! This is my long essay on the Raspberry Pi… please correct me if you find any errors on the facts presented here, and take the opportunity to express your own opinion by dropping a line on the comments. Oh, and of course don’t forget to visit the official Raspberry Pi website for more amusement! 😉