So, based on discussions on IRC over the past few days, these are the current plans for OTARM's firmware (please correct me if I'm wrong):
OS: Most likely a Linux variant, unless we can write a complete OS from scratch quickly enough. Linux is our best bet, since it allows us to use existing libraries and programs, while giving us a stable base for our system. It also runs with minimal resources. Possible distros include Angstrom, Debian, or Arch.
Math software: XCAS is an fairly complete CAS which supports all of the features needed on a calculator. In addition, it has 3 syntax modes (Maple, XCAS, and TI-89), which helps ease the transition from existing platforms to OTARM. The interface and underlying math library (GIAC) are separate, which is good since the current interface has serious user-friendliness issues (for one thing, the English version is partially in French). We will probably be writing our own UI.
Programming language: XCAS is programmable, so that settles the math side of things. For application programming (games, etc.) we will probably write or port a BASIC compiler or interpreter. Either way, it is important that we have a built-in language easier to use than Python or C.
UI concerns: The terminal and root filesystem will be accessible, but hidden from the average user. We don't want to scare new users with the Linux command-line, or with cryptically named folders like /usr, /bin, and /dev.

Have we decided on a GUI toolkit yet? Also, what filesystem type (ext2, ext3, etc.) and GNU utilities (full or Busybox) are we going to be using?
I'll update this post with the latest decisions as time goes on.
It has been pointed out that ext* is not supported by Windows. With this in mind, FAT32 is probably the way to go.

If we use Linux, we should maybe include a software (or use a distro) that is kinda user-friendly, though. If everything working through command console with no menus to access your everyday feature is too hard for some people, they'll give a bad review of the product, saying it's not user-friendly like the 83+, for example. At the same time, too many menus and complex GUI can make things hard to use, too. I personally found the TI-89 Titanium and TI-Nspire a bit too hard to use, one of the reason why I hardly code on them.

I think that the firmware should boot straight into a menu that has math related links all over the place.  We don't want to dump them in a desktop, and have them freak out when they were expecting a calculator.  User friendly is the key, and calculators have lots of users.
And we should start from the kernel, in my opinion, not from an OS.  Computer OSes are not suitable for calculators, and we should not be porting one.  Calculator users don't need a desktop, or multiple, but should still be able to reach cool linux programs outside the realm of normal math usage.

Well, maybe a key combo to sleep it from anywhere?  Like KnightOS will probably have Alpha+ON to sleep and pick up where you were.

Well, maybe a key combo to sleep it from anywhere?  Like KnightOS will probably have Alpha+ON to sleep and pick up where you were.

nice idea as long as the calc won't mem clear if a battery is pulled in this mode and that battery energy isn't drained considerably faster in this mode than if it was turned off normally.

OTARM will also require a fail-safe bootloader for in case a user manages to break their calc, which is entirely possible with root privileges.
The main filesystem should be FAT, FAT32, or ext2, I believe. Assuming that we're going to use flash memory, ext3/ext4 will wear out the flash much faster because of the journaling. SD cards need to use FAT/FAT32 simply because of Windows.

The bootloader should be read-only, like the Nspire's boot1. This provably prevents a total bricking.

I think that the firmware should boot straight into a menu that has math related links all over the place.  We don't want to dump them in a desktop, and have them freak out when they were expecting a calculator.  User friendly is the key, and calculators have lots of users.
And we should start from the kernel, in my opinion, not from an OS.  Computer OSes are not suitable for calculators, and we should not be porting one.  Calculator users don't need a desktop, or multiple, but should still be able to reach cool linux programs outside the realm of normal math usage.

We can port a Linux distro like Debian without dragging in all of the desktop stuff; basically, a kernel + a package management system.

Wow, another exploding topic!

Anyway, let me address some of the things here.
OS: OS will be Linux, unless graphmastur (and any others) figure out how to write an ARM OS from scratch.

Math core: XCAS, might mix it with some other fun math cores like Scilab, Octane, etc. Of course, you won't see these in their pure form (even XCAS is mostly in French) - these will be hidden by a intuitive, useful, and pretty GUI.

Programming Language: XCAS as a math language, Python, Basic. We could write our own covering those if you want to.

GUI: Simple, something that both teachers and students can understand. We'll hide the terminal and the root filesystem, and only offer it with a special option change and/or dotfiles to activate them (the dotfiles names will be public, but only someone who really knows how to create them will know how to unlock the terminal/root filesystem access)

Toolkit: We're using something that can be easily used by all and/or customized. That said, we can use QT or GTK+.

Filesystem: ext3 or ext4, no exceptions. A Linux system does NOT run on FAT. I'm hesitant to use ext4, since it's kind of known to have data loss if you shut off the computer (in this case, calc) unexpectedly. All filesystems are like that, but ext4 has a very severe issue with it that's enough to prompt people to stay on ext3.

A separate partition will be with FAT32 though, and will hold any user data there. The only partition that will be exposed will be the FAT one. Remember, we do have control over what goes out and what goes in - this isn't a flash drive/SD card, where all the partitions are exposed.

GNU Utilities: Busybox or regular utilities? It all depends. Will we be using the full set of GNU's utilities, or just for simple stuff/normal terminal use? If we're not using it much, Busybox is a good idea for its minimal size. If we do use it a LOT, regular GNU utilities are better. However, certain tools (ps, top, etc.) could be from the full versions. (procps for ps and top)

With that said, let me go and reply to all the other people:
======================================================

If you want to be able to read/write to the OTARM filesystem, FAT32 is probably the best choice, unless you use some kind of client software to manage file transfer (not recommended).
Depending on the speed of the ARM processor and some other hardware choices, we can also use a custom build of Android (like what they've done for BeagleBoard). This would do two things:
1) Allow for the familiar Android interface with the ability to customize
2) Allow us to hopefully make apps compatible with Android, allowing us to sell it for project funding + compatibility with other Android apps

I probably missed something there, but who knows.

No Android. This is a calc, not a phone/MP3 player. Don't let yourself get too carried away.
Also, it's pretty limited on drawing (uses the framebuffer instead of X, no 2D/3D support).
And we're not looking for Android apps to put on this. (Google only allows an App Market for phones)
Besides, there's a nasty lawsuit going on with Oracle and Google with the Dalvik Java engine, and we don't want to be caught in the fray.

If we use Linux, we should maybe include a software (or use a distro) that is kinda user-friendly, though. If everything working through command console with no menus to access your everyday feature is too hard for some people, they'll give a bad review of the product, saying it's not user-friendly like the 83+, for example. At the same time, too many menus and complex GUI can make things hard to use, too. I personally found the TI-89 Titanium and TI-Nspire a bit too hard to use, one of the reason why I hardly code on them.

Definitely. I want the teachers, not just the students, to actually enjoy using OTARM. I've heard some people here say that their teachers HATE the Nspire. (And the only ones who like it.... well, they are defending a useless product which they bought into and now have to defend themselves)

OTARM will also require a fail-safe bootloader for in case a user manages to break their calc, which is entirely possible with root privileges.
The main filesystem should be FAT, FAT32, or ext2, I believe. Assuming that we're going to use flash memory, ext3/ext4 will wear out the flash much faster because of the journaling. SD cards need to use FAT/FAT32 simply because of Windows.

Bootloaders, eh? It depends on the manufacturer. Quick explanation here: ARM doesn't produce the CPUs, they sell the cores and designs, and then from there, the chip manufacturer who licensed the core design can look at the specs, blueprints, etc., then design, test, and build a ARM chip.

With that in mind, some manufacturers (like one company calc84 mentioned on IRC) do have a bootloader already inside the chip.... but without a "special" key. (I skimmed through the docs for that CPU, so I might be wrong.) My idea is to use GRUB, modified to have key combinations for recovery and to not overwrite the screen. Maybe we could use the hardware booter as well, if it's possible to modify it.

No FAT - it's impossible to run a Linux system with FAT. ext2? Maybe. And you can disable journaling on ext3/ext4.

I think that the firmware should boot straight into a menu that has math related links all over the place.  We don't want to dump them in a desktop, and have them freak out when they were expecting a calculator.  User friendly is the key, and calculators have lots of users.
And we should start from the kernel, in my opinion, not from an OS.  Computer OSes are not suitable for calculators, and we should not be porting one.  Calculator users don't need a desktop, or multiple, but should still be able to reach cool linux programs outside the realm of normal math usage.

Agreed - I actually had a mockup of that idea:



I'm also confused - are you saying we should write a new OS, or that we should start at the kernel config, build up all the core stuff, and then build up the GUI? If the former, you should team up with graphmastur for the ARM kernel writing... after you finish the [e]Z80 one, that is! If the latter, we will. And we aren't porting any OS in general - we're taking the basic, core part, and then building on top of it.

It would be nice if we gave the user the option to choose a program or application to run on startup. Example, someone who use his calc for regular math calculations a  lot may want the calc to turn ON directly on the home screen.

The TI-89 lets you do that and I myself always have it turn ON on the home screen instead of the desktop thing

Yes, that's a good idea. Probably a quick sleep/hibernation will do. Special key combos will help in this case.

Well, maybe a key combo to sleep it from anywhere?  Like KnightOS will probably have Alpha+ON to sleep and pick up where you were.

Something like that is planned, yes.

Quote from: wchill on August 19, 2010, 05:41:10 am

OTARM will also require a fail-safe bootloader for in case a user manages to break their calc, which is entirely possible with root privileges.
The main filesystem should be FAT, FAT32, or ext2, I believe. Assuming that we're going to use flash memory, ext3/ext4 will wear out the flash much faster because of the journaling. SD cards need to use FAT/FAT32 simply because of Windows.

Journaling can be disabled on ext3/ext4 iirc, also would be good to have the 'noatime' option when it's mounted so it doesn't constantly write access times to the metadata if you go with these filesystems.

Yes, that's definitely the options we need. It'll prevent the wearing out of the flash.

Quote from: SirCmpwn on August 21, 2010, 03:56:42 pm

Well, maybe a key combo to sleep it from anywhere?  Like KnightOS will probably have Alpha+ON to sleep and pick up where you were.

nice idea as long as the calc won't mem clear if a battery is pulled in this mode and that battery energy isn't drained considerably faster in this mode than if it was turned off normally.

Mem clear? Probably not. But it might take a little more energy to boot up.

Unfortunately, ext* will require the PC that you hook to to support ext* which is not an easy filesystem for windows. There is an ext2/3 reader for windows, but ext4 is incompatible

Fat32 would be much easier, as it has much broader support. Ext3/4 might work for a main File System, if we don't plan on doing direct linking (just through SD swapping instead)

I think, Desktop-wise, we should have the calculator by default run a math desktop (very simple, nothing fancy) and for users who want a real desktop, offer support and give an easy package to install, say, xfce or some other lightweight desktop. KDE and Gnome will probably be too much for the OTArm. We should still have terminal access, even if it is rather buried.

Don't give root access easily! make it so the average user can do what they want, while making the root password only really available to those who know what they are doing. People who don't know what root means shouldn't notice that it is required for anything either.

On a side note, OmniTech is a brand name for flash drives. I saw some at staples. Also, 3 other companies show up on google. Maybe we could change it to something more unique, or maybe leave it at omnimaga Calculators!

You've kinda got my idea - ext3/4 for main file system, FAT on another partition for access.
No crazy desktop - we'll design our own.
Terminal and root access IS buried, but can be activated via option/dotfile.

And for the brand.... I don't know. We can't really just change it to Omnimaga, since Cemetech is helping us with their expertise.

Quote from: wchill on August 19, 2010, 05:41:10 am

OTARM will also require a fail-safe bootloader for in case a user manages to break their calc, which is entirely possible with root privileges.
The main filesystem should be FAT, FAT32, or ext2, I believe. Assuming that we're going to use flash memory, ext3/ext4 will wear out the flash much faster because of the journaling. SD cards need to use FAT/FAT32 simply because of Windows.

The bootloader should be read-only, like the Nspire's boot1. This provably prevents a total bricking.

Quote from: SirCmpwn on August 19, 2010, 08:23:40 am

I think that the firmware should boot straight into a menu that has math related links all over the place.  We don't want to dump them in a desktop, and have them freak out when they were expecting a calculator.  User friendly is the key, and calculators have lots of users.
And we should start from the kernel, in my opinion, not from an OS.  Computer OSes are not suitable for calculators, and we should not be porting one.  Calculator users don't need a desktop, or multiple, but should still be able to reach cool linux programs outside the realm of normal math usage.

We can port a Linux distro like Debian without dragging in all of the desktop stuff; basically, a kernel + a package management system.

The hardware bootloader requires a special flash (UART, JTAG, or something of the sort), and the software bootloader will also be able to help too (GRUB2 modified)
And you're right with the minimal distro part. Angstrom Linux perhaps? (It's popular on mobile devices, I think)

If we use a read-only bootloader, then I think the prototype OTARM calculators should use EEPROM or some kind of rewritable memory. It would suck to have to create a new prototype for each revision of software.

I believe the point of making an OTcalc was to provide a competitive alternative to TI's calculators and to allow the user to tinker around (unlike the Nspire). Something like superuser privileges being disabled by default would work, and you would need to "root" the calculator in order to use root access (similar to Android, but less cumbersome).

The memory IS rewritable (unless we use a permanent bootloader), but it requires some special command/flashing to rewrite it.
It is available for development WITHOUT rooting and the such. Root and terminal access will have an option/dotfile to activate it.

alberthrocks,
When I meant "rooting", I didn't mean flashing a firmware or anything like that. Just setting some configuration file or something out of the way for normal users.

bwang,
Use FAT32 on the SD card/removable storage only.